Host tags

Letzte Aktualisierung: 17. Januar 2011

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 = [


  • 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 variableItem fieldService listMeaning
host_groupsallmissingMapping of hosts to Nagios host groups
host_contactgroupsallmissingMapping of hosts to Nagios contact groups
parentsallDefinition of hosts' parents for Nagios
service_groupsallservicegroups definitions for services
service_contactgroupsallAssigning services to contact groups
summary_host_groupsallmissingHost groups for summary hosts
summary_service_groupsallService groups for aggregated services
summary_service_contactgroupsallContact groups for aggregated services
service_aggregationsallDefinition of services to be aggregated
non_aggregated_hostsmissingmissingHosts that are generally excluded from service aggregation
service_dependenciesallDefinition of Service Dependencies
datasource_programsfirstmissingPrograms to call instead of TCP port 6556
snmp_hostsmissingmissingHost which can be contacted only via SNMP
bulkwalk_hostsmissingmissingHosts that support SNMP bulk walk
clustered_servicesmissingServices assumed to be only available on active cluster node
only_hostsmissingmissingLimit 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

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

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

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

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

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

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'