====== Créer une sonde personnalisée ======

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

<note important>Ici on parle de créer des sondes spécifiques de monitoring. Pour l'ajout du monitoring sur une machine, consulter [[admin:monitoring:add-host|cette page]].</note>

<note tip>
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.
</note>
===== 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 dans le dossier **''/usr/local/lib/nagios/plugins/''**.
Le master Icinga distribue leurs ordres et leurs configurations aux satellites, mais ne distribue pas les exécutables et dépendances.

<note tip>
Le code de retour suit la bonne vieille logique de Nagios. Voir 
  * https://icinga.com/docs/icinga2/latest/doc/03-monitoring-basics/#check-result-state-mapping
  * https://icinga.com/docs/icinga2/latest/doc/05-service-monitoring/#create-a-new-plugin
</note>

<note tip>
De nombreux exécutables sont déjà fournis par les paquets monitoring-plugins. Pensez à les étudier avant de réécrire le votre.
</note>

<note important>
Icinga fonctionne avec des permissions limitées. Si votre check a besoin de permission étendues il devra s'accompagner d'une configuration sudo. Exemple :
<code sudo /etc/sudoers.d/icinga2-smart>
nagios ALL=NOPASSWD: /usr/lib/nagios/plugins/check_ide_smart -d /dev/sd[ab]
</code>
</note>

<note important>Si votre exécutable doit être présent sur plus qu'une seule machine, vous devez l'intégrer au paquet monitoring-plugins-chapril.</note>

===== Interface Icinga <=> exécutable =====

Icinga doit savoir comment appeler votre exécutable. Ça passe par un objet //CheckCommand//. Cette configuration est à faire sur le [[admin:machines_virtuelles:admin|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// :
<code C>
object CheckCommand "backup" {
	command = [ LocalPluginDir + "/check_backup" ]
}
</code>

Un cas moins simple :
<code C>
object CheckCommand "smartsudo" {
	command = [ "sudo", LocalPluginDir + "/check_ide_smart" ]

	arguments = {
		"-d" = {
			value = "$smart_device$"
			description = "Name of a local hard drive to monitor"
			required = true
		}
	}
}
</code>

<note tip>
La doc de référence : https://icinga.com/docs/icinga2/latest/doc/03-monitoring-basics/#check-commands
</note>

<note tip>
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 [[admin:machines_virtuelles:admin|Icinga Master]].
</note>

===== 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 [[admin:machines_virtuelles:admin|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 :
<code C>
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 == "felicette.cluster.chapril.org"
}
</code>

==== 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 [[admin:machines_virtuelles:felicette|VM dédiée à cela (et au backup)]] dans l'infra de l'April :
<code C>
command_endpoint = "felicette.cluster.chapril.org"
</code>

==== Variables de CheckCommand ====

Un cas peu moins simple :
<code C>
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
}
</code>

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

==== Le "apply ... for" expliqué ====

Considérons :
<code C>
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"
}
</code>

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
<code C>
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"
  }
  ...
}
</code>
Alors cet hôte va se voir affecté un qui pourrait être décrit (façon Nagios) par
<code C>
/* 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"
}
</code>

<note warning>
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.
</note>

<note tip>
La doc de référence :
  * https://icinga.com/docs/icinga2/latest/doc/09-object-types/#service
  * https://icinga.com/docs/icinga2/latest/doc/03-monitoring-basics/#apply-rules
  * https://icinga.com/docs/icinga2/latest/doc/17-language-reference/
</note>

<note tip>
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 [[admin:machines_virtuelles:admin|Icinga Master]].
</note>

===== Finalement =====

Vous pouvez vérifier que la configuration se charge bien dans Icinga :
<code bash>
icinga2 daemon -C
</code>

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

<code bash>
systemctl reload icinga2
</code>

==== 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'' :
<code C>
object ServiceGroup "backup" {
  display_name = "Backup Checks"

  assign where match("*backup*", service.check_command)
}
</code>
<code C>
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) 
}
</code>

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