1. How to tag your hosts
Host tags help you to keep your configuaration easy even with a large number of hosts. When defining all_hosts, you can tag each host with an arbitrary number of freely definable tags. Those tags can be used in many configuration variables and allows you to apply settings to arbitrary groups of hosts without having to specify explicit lists.
all_hosts = [ 'smucsrv05|muc', 'smucsrv06|muc', 'smucsrv08|muc|test', 'smucsrv11|muc|test', 'sparsrv04|par|sap', 'sparsrv06|par|test|sap|RX_04', 'smat01|ping', 'smat02|ping', ]
- Tags are separated by pipe symbols.
- Tags consist of letters, digits and underscores.
- Hosts can have as many tags as you want.
- It's allowed for hosts to not define any tags except:
- beginning with 1.1.9i2 there are the reserved tags ping, tcp and snmp which specify the type of agent to be queried.
2. Where to use tags
Tags are used in configuration variables and allow you to specify things for all hosts having one or more tags. Configuration variables are used in many situations. Most of them - but not all - deal with configuring checks and services, and creating Nagios configuration files.
Configuration variables always are lists of entries. Each entry is a tuple with up to four columns:
- Sometimes: Name of an item (host group, contact group, service group and so on...)
- Optional: list of tags the hosts must have
- Always: List of hosts matched by the entry
- Only for service specific things: List of service patterns (regular expressions) that must match the beginning of the service name in question.
Some variables - such as snmp_communities - use only the first matching entry. Others - like host_groups - creates a list of all matching entries. Yet others do not have an item at all but only decide whether a host or service is withing the list or not. An example is snmp_hosts, that specifies which hosts should be reached via SNMP.
The following table gives an overview over configuration variables, a more detailed list can be found here:
|Config variable||Item field||Service list||Meaning|
|host_groups||all||missing||Mapping of hosts to Nagios host groups|
|host_contactgroups||all||missing||Mapping of hosts to Nagios contact groups|
|parents||all||Definition of hosts' parents for Nagios|
|service_groups||all||servicegroups definitions for services|
|service_contactgroups||all||Assigning services to contact groups|
|summary_host_groups||all||missing||Host groups for summary hosts|
|summary_service_groups||all||Service groups for aggregated services|
|summary_service_contactgroups||all||Contact groups for aggregated services|
|service_aggregations||all||Definition of services to be aggregated|
|non_aggregated_hosts||missing||missing||Hosts that are generally excluded from service aggregation|
|service_dependencies||all||Definition of Service Dependencies|
|datasource_programs||first||missing||Programs to call instead of TCP port 6556|
|snmp_hosts||missing||missing||Host which can be contacted only via SNMP|
|bulkwalk_hosts||missing||missing||Hosts that support SNMP bulk walk|
|clustered_services||missing||Services assumed to be only available on active cluster node|
|only_hosts||missing||missing||Limit check_mk to certain hosts (useful for testing)|
The list of hosts can be replaced by the keyword ALL_HOSTS, meaning all hosts. The following example defines hostgroup definitions for Nagios by partially making use of host tags:
host_groups = [ ( 'munich', [ 'muc' ], ALL_HOSTS ), # all hosts with tag muc ( 'saptest',[ 'sap', 'test' ], ALL_HOSTS ), # hosts with tags muc and test ( 'mathias',[ 'smat01', 'smat02' ] ), # the hosts smat01 and smat02 ]
The first two lines make use of host tags. The group munich contains all hosts having the tag muc. If we stick to our example from above then these are smucsrv05, smucsrv06, smucsrv08 and smucsrv11. The group saptest will only contain the host sparsrv06 - it's the only one having both the tags sap and test.
The third line does not use tags but explicitely lists the two hosts smat01 and smat02 for the host group mathias. (Speaking of host groups: do not forget that check_mk does not create the actual host groups for you but assumes that they have already been befined in your Nagios configuration by you. It makes the tedious work of assigning the hosts to their groups, nevertheless. )
The next example shows you how to make use of a test tag to specify more lax notification periods for testing hosts:
extra_service_conf["notification_period"] = [ ( '9x5', [ 'test' ], ALL_HOSTS, ALL_SERVICES ), # all services on test hosts ( '24x7', ALL_HOSTS, ALL_SERVICES ), # all other services ]
With other configuration variables it's different: A host can be in more than one host groups. Let's assume you want to have two host groups for your SAP servers: one for production and one for testing. And let's assume you have tagged your hosts with sap and test accordingly. The following definition is not correct, since it would put all test hosts into sap_prod as well:
host_groups = [ ( 'sap_test', [ 'sap', 'test' ], ALL_HOSTS ), ( 'sap_prod', [ 'sap', ], ALL_HOSTS ), # also matches test! ]
This problem can be solved by a negated host tag. If you prefix test with an exclamation mark, then the entry will only select hosts without that tag. So the following will be a correct solution:
host_groups = [ ( 'sap_test', [ 'sap', 'test' ], ALL_HOSTS ), ( 'sap_prod', [ 'sap', '!test' ], ALL_HOSTS ), # exclude test hosts ]
3. Listing hosts having certain tags
Check_mk can help you to get an overview over your tags with the options --list-tag:
root@linux# check_mk --list-tag test smucsrv08 smucsrv11 sparsrv06
That command listed all hosts having the tag test. If you specify more tags, the hosts having all these tags will be displayed:
root@linux# check_mk --list-tag test muc smucsrv08 smucsrv11
Also using negation is possible. The exclamation mark must be quoted in order to save it from the shell:
root@linux# check_mk --list-tag test '!muc' sparsrv06