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 |
3 Code References¶
- The configured code can be found in both the public and private repo:
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 |
---|