Host tags

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 host 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',
]

Notes:

• 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.

Where to use tags

Tags allow you to specify things for all hosts having one or more certain tags. Tags can be used in many situations. Most of them - but not all - deal with the creating of Nagios configuration files.

These 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 wether 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 list variables:

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 (usefull 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:

service_extra_conf["notification_period"] = [
 ( '9x5',  [ 'test' ], ALL_HOSTS, ALL_SERVICES ), # all services on test hosts
 ( '24x7',             ALL_HOSTS, ALL_SERVICES ), # all other services
]

As you can guess, in this case the first match wins. A servive can only have one notification period.

Negation

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 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
]

The exclamation mark negates a tag and means: "The host in question must not have the tag."

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 listed all hosts having the tag test. If you specify more tags then you see the hosts having all those tags at once:

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