Outils pour utilisateurs

Outils du site


admin:monitoring:howto

Monitoring howto

Ou comment ajouter une sonde personnalisée au monitoring de Chapril.

Le vocable upstream est relativement brainfuck, du fait du long héritage des aventures des dérivés de Nagios. J'essaie de mentionner les objets en français pour moins de confusion.

Exécutable de test

Il vous faut un exécutable de test, nommé plugin dans la nomenclature icinga2. Cet exécutable devra renvoyer au choix :

  • 0 ⇒ OK
  • 1 ⇒ WARNING
  • 2 ⇒ CRITICAL
  • 3 ⇒ UNKNOWN

Cet exécutable devra être présent sur chaque machine où c'est nécessaire. Le master Icinga distribue leurs ordres et leurs configurations aux satellites, mais ne distribue pas les exécutables et dépendances.

De nombreux exécutables sont déjà fournis par les paquets monitoring-plugins. Pensez à les étudier avant de réécrire le votre.
Icinga fonctionne avec des permissions limitées. Si votre check a besoin de permission étendues il devra s'accompagner d'une configuration sudo. Exemple :
/etc/sudoers.d/icinga2-smart
nagios ALL=NOPASSWD: /usr/lib/nagios/plugins/check_ide_smart -d /dev/sd[ab]
Si votre exécutable doit être présent sur plus qu'une seule machine, vous devez l'intégrer au paquet monitoring-plugins-chapril.

Interface Icinga <=> exécutable

Icinga doit savoir comment appeler votre exécutable. Ça passe par un objet CheckCommand. Cette configuration est à faire sur le Icinga Master et sera déployée automatiquement sur tous les satellites qui recoivent la zone globale nommée global-templates. Pour cette raison la configuration doit se faire sous l'arborescence /etc/icinga2/zones.d/global-templates/.

Un cas très simple de CheckCommand :

object CheckCommand "backup" {
	command = [ PluginDir + "/check_backup" ]
}

Un cas moins simple :

object CheckCommand "smartsudo" {
	command = [ "sudo", PluginDir + "/check_ide_smart" ]
 
	arguments = {
		"-d" = {
			value = "$smart_device$"
			description = "Name of a local hard drive to monitor"
			required = true
		}
	}
}
Pour connaître les CheckCommand préconfigurées avec icinga, c'est ici : https://icinga.com/docs/icinga2/latest/doc/10-icinga-template-library/#check-commands

Pour connaître les CheckCommand spécifiques à Chapril, c'est grep 'object CheckCommand' /etc/icinga2/zones.d/global-templates/ -R sur le Icinga Master.

Configuration de la sonde

Icinga doit savoir comment affecter chaque sonde à chaque machine. Ça passe par les objets Service.

Cette configuration est à faire sur le Icinga Master et sera placée soit dans la zone global-templates, soit pour un hote spécifique dans la configuration de l'hote (sous l'arborescence /etc/icinga2/zones.d/master).

Un cas simple :

apply Service "Check Backup " {
  /* héritage de configuration de base ; cf global-templates/templates.conf */
  import "generic-service"
 
  /* le CheckCommand de ce service */
  check_command = "check_backup"
  /* le lieu d'exécution de la commande */
  command_endpoint = host.vars.client_endpoint
 
  /* la regle d'affectation de ce service */
  assign where host.name == "icinga2.cluster.chapril.org"
}

Lieu d'exécution

Pour par exemple tester un service depuis l'extérieur, on peut être intéressés par déporter le lieu d'exécution. Par exemple sur la VM dédiée à cela (et au backup) dans l'infra de l'April :

command_endpoint = "icinga2.cluster.chapril.org"

Variables de CheckCommand

Un cas peu moins simple :

apply Service "Smart " for (harddisk => config in host.vars.harddisks) {
  import "generic-service"
 
  check_command = "smartsudo"
  command_endpoint = host.vars.client_endpoint
 
  vars.smart_device = config.device
}

On remarque que la variable smart_device est utilisée dans la CheckCommand associée.

Le "apply ... for" expliqué

Considérons :

apply Service "Domaine " for (zone => config in host.vars.zones) {
  import "generic-service"
 
  check_command = "whois"
  command_endpoint = host.vars.client_endpoint
 
  vars.fqdn = config.fqdn
  assign where config.view == "external"
}

Le apply Service “Préfixe de nom” for applique le Service en déconstruisant les variables des hosts. Ainsi, si un hôte a une configuration Icinga de décrivant

object Host "dns.cluster.chapril.org" {
  ...
  /* Define zones and files for checks */
  vars.zones["Internal chapril.org"] = {
    fqdn = "chapril.org"
    file = "/etc/bind/zones/masters/chapril.org-int"
    view = "internal"
  }
  vars.zones["external chapril.org"] = {
    fqdn = "chapril.org"
    file = "/etc/bind/zones/masters/chapril.org"
    view = "external"
  }
  ...
}

Alors cet hôte va se voir affecté un qui pourrait être décrit (façon Nagios) par

/* Pour démonstration seulement. Ne pas instancier des services via la directive ''object Service''. */
object Service "Domaine chapril.org" {
  host_name = "bling.cluster.chapril.org"
  import "generic-service"
 
  check_command = "whois"
  command_endpoint = host.vars.client_endpoint
 
  vars.fqdn = "chapril.org"
}
Ne pas instancier des services via la directive object Service, qui est la façon Nagios (legacy) de faire. Toujours faire via un apply Service, plus simple à généraliser (peut s'appliquer sur 42 hotes en une fois) et donc à maintenir.
Pour connaître les Services tels que défini pour le cluster Chapril, c'est grep 'apply Service' /etc/icinga2/zones.d/ -R sur le Icinga Master.

Finalement

Vous pouvez vérifier que la configuration se charge bien dans Icinga :

icinga2 daemon -C

Vous aurez à reloader icinga. Éventuellement même sur le client.

systemctl reload icinga2

ServiceGroup

Icinga possède une notion (utile pour s'y retrouver) de groupes de services. Vous pouvez définir des nouveaux groupes de services et/ou ajouter vos sondes à un groupe de services dans zones.d/global-templates/groups.conf :

object ServiceGroup "backup" {
  display_name = "Backup Checks"
 
  assign where match("*backup*", service.check_command)
}
object ServiceGroup "disk" {
  display_name = "Disk Checks"
 
  assign where match("disk*", service.check_command)
  assign where match("drbd*", service.check_command) 
  assign where match("smart*", service.check_command) 
}

Filtrer sur les CheckCommand présente l'avantage de gérer toutes les variantes de services possibles. Et selon les conventions, on voit que ça peut être avantageux d'avoir des préfixes ou des suffixes communs pour les noms des CheckCommand.

admin/monitoring/howto.txt · Dernière modification: 2019/09/24 21:14 par cpm