Setting up WATO
Dieser Artikel wird nicht mehr gepflegt und ist unter Umständen nicht mehr gültig!
1. Setting up WATO
1.1. Configuration files
Before you can use WATO, you have to setup some things in multisite.mk. WATO organises hosts into multiple configuration files. This allows you to give your users selective access permissions - each group in your organization can manage their hosts independent of the others. Those configuration files are ordinary *.mk files lying around in etc/check_mk/conf.d. So your first step is to configure this list of WATO-enabled files. The following example sets up two files - one meant to contain network components and the other for the datacenter:
config_files = [ ("network.mk", "Network, Infrastructure", [ "admin", "user" ] ), ("datacenter.mk", "Servers in Datacenter", [ "admin" ]), ]
Each entry in this list is a tuple with three components:
Usually you do not need to created the configuration files. WATO will create them for you as soon as the first host is created in there. Your web server needs write permissions on that file. If you cannot give it write permissions to conf.d an alternative is pre-creating the files empty with touch and giving write permissions directly on the file. The setup script of Check_MK, tries to setup everything properly, though.
1.2. Host tags
The role of host tags is a crucial one in WATO. Please remember: WATO assumes that the monitoring administrator - probably you - is setting everything up in the best way possible and the users just manage their hosts and services. This might be the most important aspect where WATO differs from other Nagios configuration GUIs.
Lets make an example and assume that you have productive servers and test servers. The productive systems should have the notification period 24x7 whereas the test servers only 5x9. Furthermore - test servers should be in the host group test and warn/crit levels for filesystem checks on test systems should be at 95% and 101% (never get critical).
Your first step is to decide to use the host tags test and prod for declaring the productivity of each host. In multisite.mk you make that tag editable for your users. This is done with the variable host_tags in multisite.mk. For each group of tags one dropdown will appear in the "Edit host" dialog. The following example defines just our productivity tag:
host_tags = [ # select productivity ( "Productivity", [ ( "prod", "Production System" ), ( "test", "Test System" ), ]), ]
That way the user will be forced to select either prod or test when editing a host. In main.mk you can then define rules making use of these tags (which is beyond the scope of this article).
It is also allowed to specify None instead of a tag. In that case - if the user selects that entry - no tag will be set. The following example will show a second decision for setting the tag bulk:
host_tags = [ # first selection: productivity ( "Productivity", [ ( "prod", "Production System" ), ( "test", "Test System" ), ]), # second selection: SNMP version ( "Bulkwalk (SNMP v2c)", [ ( None, "Simple walk (SNMP v1)"), ( "bulk", "Bulkwalk (SNMP v2c)" ), ]), ]
In some cases you want to add more than one tag to a host when the user selects an item from the dropdown. The following example lets the user select the operating system of the host to be monitored:
host_tags = [ # ... some other tags ... ( "Operating System", [ ( "lnx", "Linux", [ "tcp" ]), ( "win", "Windows", [ "tcp", "snmp" ]), ( "net", "Network device", [ "snmp" ]), ( "ping", "Only PING this host", ), ]), ]
When the user selects "Linux", the host will not only get the tag lnx, but also tcp. Windows hosts will get the three tags win, tcp and snmp.
The resulting host dialog with the three example tags looks like this:
Please note: The main tag (here lnx, win, net and ping) must be unique in host_tags. on both sides of the equation. So, the following will not work:
host_tags = [ # ... some other tags ... ( "Operating System", [ ( "lnx", "Linux", [ "tcp" ]), ( "ubuntu", "Ubuntu ", [ "lnx", "feature"]), # Breaks up things! ]) ]
This approach of WATO has two main advantages:
Please note, that this rule based concept is not only easier, but also much more powerful than template or even copy & paste based concepts. Based on the host tags you can configure almost every aspect of monitoring. You are not restricted to Nagios settings but also can influence check parameters and all other aspects of Check_MK such as ignored_services and only_hosts.