Objects are central to the Icinga configuration in terms of what will be monitored. We tell Icinga what servers and what services on each of these servers should be monitored, as well as the contact information and modes of alerting. All of these are primarily defined by Icinga objects.
It is very important to understand the objects and how to use them to build a proper monitoring configuration. This configuration is what we need to describe and configure our monitoring environment.
There are many types of objects, some of which include the following:
- Host, Hostgroup, Hostdependency, Hostescalation, Hostextinfo
- Service, Servicegroup, Servicedependency, Serviceescalation, Serviceextinfo
- Contact, Contactgroup
- Command
- Timeperiod
An object definition contains the object type and valid key-value pairs required to describe the particular object instance. The format of the object definition is as shown in the following code:
define <object-type> {
key1 value1
key2 value2
...
}An example of object definition is as follows:
define host {
hostname www.google.com
alias google-server
}Objects are defined in plain text files in a certain format. One file can contain one or more object definitions, and there can be any number of object configuration files with the extension .cfg, which are specified by the cfg_file and/or cfg_dir directives in the main configuration file.
The configuration of the basic monitoring setup involves the use of host, service, and command objects. We follow the step-by-step process to reach a final configuration which is as follows:
- We define servers that we want to monitor with host objects. The host objects take hostname, address, and so on, using which we specify the server's details.
- Then we define the services that will be monitored on each of the servers using service objects. The service objects take service name, hostname, check command, and so on to specify the server on which you want to run this service check, and the command name that specifies the command that will perform the check.
- The check command specified in the service definition corresponds to a command object. The command objects have a command name with the command-line string, which is specified to determine the exact command that should be run (as on the bash console) to execute the check. The criticality/state of the service check is determined by the exit code of the command:
0is for OK,1is for WARNING, and2is for CRITICAL. All other exit codes result in the UNKNOWN state.
There are other object types available for easy configuration of complex networks. For example, suppose we want to run a check for free disk space on all of the servers, and we don't want to specify all of them in the service definition. Instead, we can create a hostgroup (basically a group of several hosts) object with a name, say allservers. We can then specify this hostgroup name in all host definitions using the hostgroup directive, and give the same hostgroup name in the service definition using the hostgroup_name directive. Icinga will put the service check on all hosts that belong to the allservers hostgroup. Even better, we can create a host object template (same as a usual host definition) using Icinga's object inheritance, in which we specify the desired hostgroup name and then simply inherit the template object in all host definitions using the use directive.