Supervision avec Icinga (2) – Peaufiner la configuration initiale

Dans notre précédent article sur Icinga, nous avons installé l’application de supervision ainsi que l’interface graphique Icinga Web sur un serveur dédié. Avant d’aller plus loin, nous allons jeter un œil à la configuration existante et tenter de la peaufiner, ce qui nous permettra en passant de « comprendre par la pratique » la logique des fichiers de configuration d’Icinga.

La configuration proposée par défaut permet au serveur Icinga de surveiller son propre état, ce qui se manifeste sous forme d’une série de tests comme disk, icinga, swap, users, ping4, ping6, procs, load ou ssh qui s’affichent sur le tableau de bord :

Avant d’aller plus loin et intégrer d’autres machines, je vais modifier cette configuration initiale pour deux raisons :

• corriger l’affichage d’une erreur
• rendre les tests plus lisibles

Pour commencer, je vais sauvegarder cette configuration existante pour pouvoir expérimenter plus sereinement et revenir en arrière si je me tire dans le pied :

# cd /etc/icinga2/
# cp -aR conf.d/ conf.d.orig

Adapter la configuration à l’IPv4

Comme nous l’avons vu à la fin de notre précédent article sur Icinga, le test ping6 échoue pour la simple et bonne raison que nous n’utilisons que l’IPv4 sur cette machine.

Ouvrez le fichier /etc/icinga2/conf.d/hosts.conf et repérez la stance suivante :

/* Specify the address attributes for checks e.g. `ssh` or `http`. */
address = "127.0.0.1"
address6 = "::1"

Supprimez la ligne qui commence par address6 et enregistrez les modifications. Testez la validité de la configuration et repérez l’avertissement relatif à ping6 :

# icinga2 daemon -C
... information/cli: Icinga application loader (version: 2.13.2-1)
... information/cli: Loading configuration file(s).
... information/ConfigItem: Committing config item(s).
... information/ApiListener: My API identity: sd-155842.dedibox.fr
... warning/ApplyRule: Apply rule 'ping6' (in /etc/icinga2/conf.d/services.conf: 
    34:1-34:21) for type 'Service' does not match anywhere!
... information/ConfigItem: Instantiated 1 NotificationComponent.

Ouvrez /etc/icinga2/conf.d/services.conf et repérez la stance qui définit le service ping6 :

apply Service "ping6" {
  import "generic-service"

  check_command = "ping6"

  assign where host.address6
}

Supprimez cette stance, enregistrez les modifications, quittez le fichier et relancez un test de la configuration :

# icinga2 daemon -C

Tous les tests s’affichent en vert, je vais donc prendre en compte cette nouvelle configuration :

# systemctl reload icinga2

Le tableau de bord n’affiche plus la moindre erreur :

Activer le test pour Icinga Web

Le fichier hosts.conf fournit une stance commentée qui permet de superviser l’application Icinga Web elle-même :

/* Uncomment if you've sucessfully installed Icinga Web 2. */
//vars.http_vhosts["Icinga Web 2"] = {
//  http_uri = "/icingaweb2"
//}

Je décommente cette stance en renommant le service Icinga Web :

/* Uncomment if you've sucessfully installed Icinga Web 2. */
vars.http_vhosts["Icinga Web"] = {
  http_uri = "/icingaweb2"
}

Là encore, je teste la validité de la syntaxe :

# icinga2 daemon -C

Je prends en compte la nouvelle configuration :

# systemctl reload icinga2

Vous aurez compris que d’une manière générale, c’est toujours une bonne idée de procéder par petites modifications incrémentales en testant à chaque fois la validité de la configuration.

Au bout de trente secondes, je vois apparaître le nouveau service Icinga Web dans la liste :

Améliorer la lisibilité des services de base

Le fichier conf.d/services.conf contient toute une panoplie de services prédéfinis. Je vais éditer ces définitions pour arranger la lisibilité de l’affichage.

Dans la stance qui définit le test ping4, je remplace le nom du service par Ping. En passant, je supprime les lignes vides pour rendre la configuration plus compacte :

apply Service "Ping" {
  import "generic-service"
  check_command = "ping4"
  assign where host.address
}

Cette modification devra également être renseignée dans le fichier groups.conf qui regroupe un certain nombre de services :

object ServiceGroup "Ping" {
  display_name = "Ping Checks"
  assign where match("Ping*", service.name)
}

Je retourne dans le fichier services.conf et j’identifie la stance qui définit le test relatif à la charge du système :

apply Service "load" {
  import "generic-service"

  check_command = "load"

  /* Used by the ScheduledDowntime apply rule in `downtimes.conf`. */
  vars.backup_downtime = "02:00-03:00"

  assign where host.name == NodeName
}

• Je renomme le service en System load.
• A priori je n’ai pas l’intention d’utiliser les plages de maintenance programmées. Je vais donc supprimer la ligne vars.backup_downtime.
• Le test de configuration m’affiche une règle backup_downtime non utilisée. La solution la plus simple consiste à supprimer le fichier de configuration correspondant.

# rm -f downtimes.conf

Voici la stance simplifiée :

apply Service "System load" {
  import "generic-service"
  check_command = "load"
  assign where host.name == NodeName
}

Toujours dans cette même logique, je remplace procs par Running processes, swap par Swap usage et users par Logged users:

apply Service "Running processes" {
  import "generic-service"
  check_command = "procs"
  assign where host.name == NodeName
}

apply Service "Swap usage" {
  import "generic-service"
  check_command = "swap"
  assign where host.name == NodeName
}

apply Service "Logged users" {
  import "generic-service"
  check_command = "users"
  assign where host.name == NodeName
}

Un peu plus haut dans le fichier, ssh deviendra SSH, avec une configuration adaptée à l’IPv4 :

apply Service "SSH" {
  import "generic-service"
  check_command = "ssh"
  assign where host.address && host.vars.os == "Linux"
}

Quant au service icinga, on va le renommer en Icinga:

apply Service "Icinga" {
  import "generic-service"
  check_command = "icinga"
  assign where host.name == NodeName
}

J’enregistre les modifications apportées à services.conf et j’ouvre hosts.conf, où je vais également renommer quelques tests. Ainsi, http devient HTTP:

/* Define http vhost attributes for service apply rules in `services.conf`. */
  vars.http_vhosts["HTTP"] = {
    http_uri = "/"
  }

Dans la section qui définit les tests des disques durs, je remplace disk par Hard disk:

/* Define disks and attributes for service apply rules in `services.conf`. */
vars.disks["Hard disk"] = {
  /* No parameters. */
}

En passant, je simplifie l’affichage de ce service en supprimant la stance suivante :

vars.disks["disk /"] = {
  disk_partitions = "/"
}

Toutes ces petites améliorations peuvent vous paraître insignifiantes et simplement cosmétiques. Je vous laisse donc apprécier la lisibilité de l’ensemble après avoir pris en compte l’ensemble des modifications apportées :

Dans notre prochain article, nous passons aux choses sérieuses en connectant une machine publique à notre serveur de supervision flambant neuf.

La rédaction de cette documentation demande du temps et des quantités significatives de café espresso. Vous appréciez ce blog ? Offrez un café au rédacteur en cliquant sur la tasse.