News from check_multi

The incredibly simple plugin interface is a key to the mysteries of the success of Nagios. A return code of 0,1,2,3 and some explaining words, that's all.

Everybody was able to understand these two elements and started to write plugins. In all languages one can imagine and for all OS where Nagios is running on. Nagios got a famous reputation ('Yes we can plugin!'), and the only limitation was the skill of the plugin programmer.

As a side note: Some plugins actually are not of best quality, as we can see in the exchange repositories. But they cover the whole range of monitoring.

Plugin output limited

Let's talk about a small aspect of the plugin interface which is annoying and often frustrates especially Nagios beginners - the limited length of plugin output. It sounds pretty simple, but the devil is in the details.

→ Read more...

I confess - this release should have been launched much earlier. I know the OSS mantra: release early, release often. But there were so many enhancements, redesigns, fixes in a row that I really missed to shift the trunk version into a new stable release .

You can download it like always from here.

So these are the new features:

→ Read more...

Some day a customer complained that he could not access a local intranet server. But I was sure that the server is running, nagios showed green lights everywhere.
But when I remotely connected to the customers PC, I had to notice that he is right and there is no connection from his network to the intranet server due to routing problems. Whoops…

The afternoon I thought about ways to cover this situation in our Nagios monitoring. Nagios has no obvious resp. generic solution for this problem except setting up multiple checks from different hosts.

But wait a little bit - there is a conceptional problem with this. All these checks are associated to other hosts as they're really belonging to. This will confuse the whole process (and the administrator as well ). Notifications and escalations are based on the wrong host and the statistics / SLAs are also affected.

→ Read more...

For a individual interpretation of data in check_multi the builtin state evaluation is a good means. It internally works with perl eval and therefore is extremely flexible.

Look at the following SNMP example as a simple introduction:

→ Read more...

There is often the discussion, if monitoring checks should be run remotely or locally on the server, which has to be monitored. The decision is sometimes easy, when the ressource to be monitored is not available remotely, e.g. logfiles or disks.
But there are plenty of cases where you can do both, e.g. applications and services, which are accessed via network. Please don't think, that network services have to be monitored remotely, because otherwise there's no proof that it's working over the network. You can give exactly one proof with your nagios check, and that is for the nagios server. Where the servers users normally not reside
So why not executing all checks on the remote server?

→ Read more...

The Nagios world consists of hosts and services. But what to do if the hosts do not matter? This is the case with all devices which are not necessarily up all the time, but have services need to be monitored if they are.

E.g.

• Printers, which should be monitored for toner and paper
• Windows clients, which patch level should be supervised
• Salesmans notebooks, which are not connected most of the time.
  But if they are, we want to check all we can get of them.

→ Read more...