Using WATO

Authorization and Snapin

Before you can use WATO you need to make sure that your role has the following two permissions:

• Use WATO
• The WATO sidebar snapin

Also your role needs to be listed in at least one of the files configured in configuration_files in multisite.mk. If all that is that case, add the WATO snapin to your sidebar. This example provides access to the two configuration files Servers and Network.

Managing Hosts and Services

First step: basic data

Creating a new host takes two steps. In the first step you edit the basic data of the host:

The only mandatory field is the host name. The host name does not need to be resolvable via DNS or /etc/hosts. It is used as as Nagios host name. In Nagios host names are case sensitive, so for Nagios localhost and Localhost are two different hosts.

The Alias field is purely optional. If not empty it will be added to the Nagios host configuration by Check_MK (via an entry extra_host_conf['alias']).

If the host name can be looked up via DNS, then you rather leave the field IP-Address empty. In that case a DNS lookup takes place each time Nagios is restarted. No DNS lookups will be done during the actual monitoring. If you enter an IP-adresse or a FQHN here, WATO will create an entry in ipaddresses for that host and Check_MK will not try a DNS lookup.

The rest of the dialog shows selections of all host tags that the administrator has setup for WATO. Each selection is preset to its default value.

Second step: services

The second step configures the services to be monitored on that host. You enter that by saving the dialog with Save & go to Services. An alternative is to leave the dialog via Save & Finish. In that case no services will be added to the host and Check_MK will monitor it only with ping.

Before you go to the services dialog, make sure that the Check_MK agent is installed on the host or - if you want to use SNMP - everything in Check_MK is setup correctly (the SNMP community is configured and the host has the tag snmp).

The Services-dialog now does a dry-run inventory and looks for services not yet inventorized:

There are several categories of services. The most common case is Available (missing) services. Per default all those services are selected for inclusion. The best is to finish the dialog with Save manual check configuration.

The following categories of services exist:

• Available (missing) services - These services have been found on the host and are not yet monitored. Having available services on a host makes the inventory check unhappy.
• Already configured services - Services that are already executed by Check_MK and Nagios for that host.
• Obsolete services (being checked, but should be ignored) - If you see this, then the administrator has setup rules for excluding services from the inventory via ignored_services, ignored_checks or ignored_checktypes but such services are neverthelss being checked in this host.
• Ignored services (configured away by admin) - Services setup to be ignored, and that would be available for on this host. They are currently not checked (which is exactly what the admin wanted)
• Vanished services (checked, but no longer exist) - These checks will most probably show an UNKNOWN state in Nagios. This for example happens if a filesystem that is being monitored is not anymore present on that host.
• Manual services (defined in main.mk) - manually configured services via checks in main.mk. You cannot manage those services with WATO.
• Legacy services (defined in main.mk) - non-Check_MK services configured in main.mk via legacy_checks. You cannot manage those services with WATO, either.

Making changes active

All changes you make via WATO are immediately written into configuration files below etc/check_mk/conf.d. From Check_MK's point of view, they become immediately active. Your monitoring process - however - needs to have its configuration updated and must be restarted. This is what check_mk -R usually does.

WATO keeps a logfile of all changes made and also shows you which of those still haven't been activated. Click the context button ChangeLog in order to view those:

By pressing Activate Changes you make all changes active. This includes:

• letting Check_MK generate a new object configuration file for Nagios
• restarting Nagios

Note(1): Since Nagios cannot be restarted partially, if you activate the changes than all pending WATO changes are activated - also those kept in other WATO configuration files.

Note(2): A manual check_mk -R or check_mk -O on the commandline will activate all changes, as well.