ITTN-027: Monitoring over Icinga2

  • Heinrich Reinking

Latest Revision: 2020-08-12

1   Introduction

Puppet deployment consisting on monitoring system based on a master-client design, in which all puppet clients will automatically enroll to the icinga master, also being reflect in the Web Interface through IcingaWeb2, handled by Icinga Director and deploying graphs through PNP.

The taken approach allow us to have multiple master instances, and that every node response to their own master. For future developments, the idea is to join the masters into a replicate configuration to visualize all instances.

2   Requirements

In order to deploy Icinga2 and IcingaWeb2, there are several dependancies that have to be taken care off. The built code includes those references and is in a “ready to deploy” status

Package Repo Version
Remi https://github.com/hfm/puppet-remi v1.11.0
Icinga2 https://github.com/Icinga/puppet-icinga2 v2.3.2
IcingaWeb2 https://github.com/Icinga/puppet-icingaweb2 v2.3.1
Nginx https://github.com/voxpupuli/puppet-nginx v1.1.0
MySql Server https://github.com/puppetlabs/puppetlabs-mysql v10.4.0
IcingaWeb Director (part of icinga repo) v1.7.2
IcingaWeb PNP https://github.com/Icinga/icingaweb2-module-pnp.git v1.1.0
IcingaWeb Reactbundle https://github.com/Icinga/icingaweb2-module-reactbundle v0.7.0
IcingaWeb IPL https://github.com/Icinga/icingaweb2-module-ipl v0.3.0
IcingaWeb Incubator https://github.com/Icinga/icingaweb2-module-incubator v0.5.0

4   Services, Hosts and Templates

There are 4 things (or objects) to take in consideration: Host templates, Service templates, Hosts and Services. Host Templates are responsable of providing the final host object an inheritad default configuration, as well as a default configuration. Service templates are the ones that have the “check_command” on them, which means, is the one that defines which operation is going to be perform in the remote host (without defining yet the host). Services per se, links or vinculates a Host Template with a Service Template, so all hosts that use the defined Host Template, will automatically inherit the previously linked Service Template. Finally, when you define a Host, you simply use the defined Host Template, and the host will add itself with the Service Template (check_command, monitoring operation that will be perform) into the icinga master.

4.1   Host Templates

To create a Host Template, you must specify the following fields:
  • accept_config: Allow the host to receive instructions from the icinga master.
  • check_command: Default command to run to the hosts; preferably leave it in “hostalive”.
  • has_agent: Agent must have installed and be configured with icinga agent.
  • master_should_connect: Set to “yes”.
  • max_check_attempts: Number of attempts the master will try to check the host.
  • object_name: The name to which you will later reffer to this object.
  • object_type: Set to “template”.
{
 "accept_config": true,
 "check_command": "hostalive",
 "has_agent": true,
 "master_should_connect": true,
 "max_check_attempts": "5",
 "object_name": "${host_template_name}",
 "object_type": "template"
}

4.2   Service Templates

To create a Service Template, you must specify the following field:
  • check_command: The monitoring command you which to report, such us dhcp, dns, ldap.
  • object_name: The name to which you will later reffer to this object.
  • object_type: Set to “template”.
  • use_agent: Allow connection to the icinga agent installation in the host.
  • vars: Define additional variables, such as warning land critical level, ldap parameters, ping response time.
  • zone: Zone in which the icinga master is configured.
{
 "check_command": "ldap",
 "object_name": "${service_template_name}",
 "object_type": "template",
 "use_agent": true,
 "vars": {
   "ldap_address": "localhost",
   "ldap_base": "dc=lsst,dc=cloud"
 },
 "zone": "master"
}

4.3   Services

In order to create a Service, you must use the exact same object names that were used in the Host Template and the Service Template:
  • host: For a Service object, you must provide the host_template_name (same as the one used before).
  • imports: For a Service object, you must provide the service_template_name (same as the one used before).
  • object_name: The name to which you will later reffer to this object.
  • object_type: Set to “object”.
{
 "host": "${host_template}",
 "imports": [
 "${$service_template}"
 ],
 "object_name": "${service_name}",
 "object_type": "object"
}

4.4   Hosts

Finally to add the Host:
  • address: The IP address of the host.
  • display_name: For consistency, use the Fully Qualified Domain Name.
  • imports: For a Host object, you must provide the host_template_name that you wish this host is part of.
  • object_name”: For consistency, use the Fully Qualified Domain Name. This name will be use for future reference.
  • object_type”: Set to object.
  • vars: Define additional variables that are specific to this host.
{
 "address": "${host_ip}",
 "display_name": "$host_fqdn",
 "imports": [
   "${host_template}"
 ],
 "object_name":"${host_fqdn}",
 "object_type": "object",
 "vars": {
   "safed_profile": "3"
 }
}
tocdepth:1