Monitoring multi-address or multi-identifier devices

When managing monitoring systems it's common to find situations in which one device has more than one identifier, or number of network addresses or a combination of specific IP addresses and identifiers. Some cases may be:

• Servers with different management and production network interfaces. These include, for example, HP Proliant servers on which the ILO has a dedicated network interface and therefore a different network address to the address of the production network.
• Virtual Hosts with an IP address and an ID production system level. A common example are virtualized on VMWare ESX hosts, where the identifier system-level virtualization is completely disconnected from the IP address that is assigned to the device.

When the monitoring system is based on Nagios, where there is only one property that identifies the host address (property address in host object), the above situation becomes a problem.
The usual solution is keeping the second value stored in the property alias and change the definitions of the check command, replacing $HOSTADDRESS$ macro by $HOSTALIAS$ macro. However, this approach leads to more problems than solutions:

• The alias is very useful when correctly used in reports, identifying and providing valuable information about the host.
• Some third-party tools, usually topology tools, use this field as display name. 

User Macros

In addition to the standard macros, Nagios supports the so-called custom variable macros: identifier-value pairs defined in the host, service or contact objects. Macros of this type are distinguished from standard being necessarily prefixed by a "_" symbol.

define host {     
    host_name ProliantServer
    address 192.168.1.1 
    _ILOADDRESS 192.168.2.1
    ...
}
 
In the above example a macro called $_ILOADDRESS$ is defined, being 192.168.2.1 its value that identifies the IP address of the ILO management interface on a server called MyProliantServer. From all points of view this macro can be considered as an standard Nagios macro: It can be invoked from both the execution of host or service checks and therefore can be used in the in a command definition:
 

define command {
    command_name CheckILOFans
    command_line $USER1$/check_snmp -H $_HOSTILOADDRESS$ ...
    ...
}
 

define command {

    command_name CheckHTTPPort 

    command_line $USER1$/check_tcp -H $HOSTADDRESS$ ...

    ...

}
 

The above example first defines a command called CheckILOFans addressed to check the status of fans on a server with an ILO management interface. CheckHTTPPort also defines a command intended to establish the availability status of the HTTP port on a production interface.


In the first case the used host address is not $HOSTADDRESS$. Instead we use the address stored in our recently created macro, whose name must be prefixed by _HOST because it has been defined as part of a host object, so the macro must be referenced as $_HOSTILOADDRESS$. In the same way, if we define a custom macro in a service object definition, it should be referenced prefixing its id with _SERVICE and finally, if we define a custom macro in a contact object definition, it should be prefixed by _CONTACT.


By following this approach, now we can use both commands to define checks on the same host, even being based on information available through different network interfaces: 

define service {

    host_name ProliantServer

    service_description FanStatus 

    check_command CheckILOFans

    ...

}

define service {

    host_name ProliantServer

    service_description HTTPStatus 

    check_command CheckHTTPPort

    ...

}

 
Macros in Centreon
 
For those who prefer configuring Nagios using the Merethis tool, Centreon supports the management of variable custom macros from version 1.x: You can create, modify and delete them on the tab "Macros" in the definition of host and service objects configuration. Unfortunately, being version 2.2 recently released, the management of macros in contact objects is still not supported.

Tweet