Calling home – Making sure your free range servers are alive with Passive monitoring

Active vs Passive monitoring

When most monitoring systems are installed, checks are usually performed using polling. This has some drawbacks, namely that the central monitor node has to have the necessary plugins installed on it. It also has to have network access to the remote servers. But what if the server can’t or shouldn’t have direct access to those remote servers? Or if the central node is overloaded with other tasks? That’s where passive monitoring comes in. It takes away the need for the central monitoring node to do anything. It can instead just wait for the monitoring data to come in.

Hosts with dynamic IP addresses

Sometimes you need to monitor hosts that have dynamic IP addresses. This means these need to have a consistent DNS addresses and incoming traffic needs to be allowed by firewall(s). When these two requirements aren’t possible to meet, passive checks can be quite handy.

Hosts that are shutdown regularly

If you need to monitor hosts that are shutdown often, like workstations, you’ll get alarms whenever they are offline. If the hosts are monitored passively instead, no extra alarms will be sent out. You can also use service dependencies in Nagios, Naemon and Icinga, if you want an alternative to passive checks for this type of host.

But what if the data never comes in?

What if your remote servers never send in their monitoring results? What if they crash? Nagios has a solution for this, and it’s called freshness. Freshness means Nagios will check if the data has come in within a specified deadline. If this doesn’t happen, Nagios will generate an alarm.

How?

Passive monitoring comes built-in in Icinga, Nagios and Naemon (the open core of ITRS OP5 Monitor). But this only means they are passive-check ready. The data still has to be received. This can be done with APIs or using another tool.

Monitoring APIs

Passive checks can be submitted using APIs like those in ITRS Monitor, or Icinga. This means that a poller or satellite host needs to be exposed to the clients.

NSCA

Nagios Service Check Acceptor, or NSCA, is a tool that uses a custom protocol to receive information from clients and then submits this information to the monitoring system. There are several clients available: NSClient++, send_nsca

NRDP

Nagios Remote Data Processor uses HTTPS to receive status information and then submits that to Nagios/Naemon. As this is a common protocol, writing your own clients is quite straightforward. As this is the newest solution, this is the recommended way to use passive checks. Several ready-made clients are also available: NCPA, send_nrdp, and NSClient++.

The power of delegation

Passive checks can be a powerful way to delegate monitoring to other hosts. Should you need to deploy many passive checks with many remote servers, you will need to employ automation to help with configuration changes and deployments. We have a lot of experience with monitoring and automation. Don’t hesitate to contact us if you need help.

About the author