Nagios, Icinga, Xymon : les anciens qui tiennent bon

Dans chaque salle serveur un peu ancienne, il existe une machine que personne n'ose éteindre. Elle porte un nom de planète ou de personnage de dessin animé, elle n'a pas été redémarrée depuis une mise à jour du noyau dont plus personne ne se souvient, et elle fait tourner un Nagios configuré par quelqu'un qui a quitté l'entreprise en 2011. Le plus troublant, c'est qu'elle fonctionne. Elle envoie ses alertes, et elles sont justes.

Cet article rend hommage à ces anciens, sans nostalgie excessive : ce qu'ils font encore mieux que les outils récents, ce qu'il ne faut plus leur demander, et comment décider de leur sort.

01Une courte généalogie

02Nagios, le contrat qui a gagné

L'apport durable de Nagios n'est pas son interface, qui a peu changé depuis l'époque où l'on choisissait ses cadres HTML avec soin. C'est son contrat de greffon : un programme, dans n'importe quel langage, qui affiche une ligne et sort avec un code. Zéro pour OK, un pour WARNING, deux pour CRITICAL, trois pour UNKNOWN. Rien de plus.

#!/bin/sh
# check_sauvegarde : age de la derniere sauvegarde, en heures
f=$(ls -1t /srv/sauvegardes/*.tar.zst 2>/dev/null | head -1)
[ -z "$f" ] && { echo "SAUVEGARDE UNKNOWN - aucun fichier"; exit 3; }

age=$(( ($(date +%s) - $(stat -c %Y "$f")) / 3600 ))
perf="age=${age};26;48;0"

if [ "$age" -ge 48 ]; then
  echo "SAUVEGARDE CRITICAL - derniere sauvegarde il y a ${age} h | $perf"; exit 2
elif [ "$age" -ge 26 ]; then
  echo "SAUVEGARDE WARNING - derniere sauvegarde il y a ${age} h | $perf"; exit 1
fi
echo "SAUVEGARDE OK - derniere sauvegarde il y a ${age} h | $perf"; exit 0

Ce contrat est d'une simplicité désarmante, et c'est précisément pourquoi il a survécu à tout. Des milliers de greffons existent pour à peu près tout ce qui possède une prise réseau, et ils s'exécutent aujourd'hui dans Icinga, Naemon, Checkmk ou Sensu. Zabbix peut les appeler par un paramètre utilisateur. Un greffon écrit en 2005 tourne encore sans modification.

Ce que Nagios Core fait toujours bien

• Exécuter des vérifications et alerter, sans surprise, pendant des années.
• Tenir sur une machine minuscule : quelques centaines de services n'occupent presque rien.
• Se configurer en fichiers texte, versionnables et générables par script.

Ce qu'il ne faut plus lui demander

• Des graphiques : il faut des greffons tiers, et le résultat date d'une autre époque.
• Une architecture distribuée propre : les solutions existent, mais tiennent du bricolage.
• Une API moderne : l'interface d'origine repose sur des CGI.

03Icinga, Nagios repensé

Icinga 2 garde le contrat des greffons et réécrit tout le reste. Sa configuration est un vrai langage, avec des règles d'application qui attachent un service à tous les hôtes qui remplissent une condition, au lieu de les énumérer.

object CheckCommand "sauvegarde" {
  command = [ PluginDir + "/check_sauvegarde" ]
}

apply Service "sauvegarde" {
  check_command = "sauvegarde"
  check_interval = 1h
  # execute sur l'agent Icinga de l'hote lui-meme
  command_endpoint = host.name
  assign where "sauvegarde" in host.vars.roles
}

Ses autres atouts sont sérieux : une architecture en zones, maître, satellites et agents, avec des certificats et un chiffrement natifs ; une API REST complète ; Icinga DB et Icinga Web pour une interface actuelle ; et le module Director, qui permet de tout configurer depuis l'interface ou d'importer l'inventaire depuis une CMDB.

Icinga est aujourd'hui le choix naturel pour qui veut rester dans le monde des greffons Nagios avec un outil moderne et activement développé. C'est aussi le chemin de migration le plus doux pour un vieux Nagios : les greffons et les commandes se reprennent tels quels.

04Xymon, la grille de couleurs

Xymon a une philosophie différente. Chaque machine fait tourner un petit client qui envoie toutes les cinq minutes un rapport complet au serveur : processus, disques, mémoire, ports, journaux. Le serveur analyse et affiche une grande grille, une ligne par hôte, une colonne par test, une pastille de couleur par case.

La couleur violette mérite qu'on s'y arrête. Elle signifie « je n'ai plus de nouvelles », et elle est active par défaut sur tous les tests, depuis toujours. Combien de plateformes récentes découvrent l'importance d'alerter sur l'absence de données après l'avoir payée ? Xymon l'avait réglé il y a vingt ans.

Côté maintenance, la dernière version officielle, 4.3.30, date de 2019. Le projet reste empaqueté et corrigé dans Debian et Ubuntu, et un fork communautaire a publié en 2026 une interface entièrement refaite en HTML5. C'est un outil stable, plus qu'un outil vivant : parfait pour qui l'a déjà, déconseillé pour démarrer.

05Ce qu'ils font encore mieux

06Garder, moderniser ou migrer

Un outil ancien qui fonctionne n'est pas un problème à résoudre. Il en devient un dans des cas précis, et c'est sur ces cas qu'il faut décider.

• Garder si la plateforme est stable, les alertes sont justes, quelqu'un maîtrise encore la configuration, et le système qui la porte est maintenu. Mettez-le à jour, documentez-le, et passez à autre chose.
• Moderniser vers Icinga 2 si vous tenez aux greffons, que la configuration à plat devient ingérable, ou qu'un deuxième site arrive. C'est une migration de quelques jours, pas un projet.
• Migrer vers Zabbix ou une pile Prometheus si le besoin a changé de nature : métriques fines et tendances, centaines d'hôtes, équipes multiples, découverte automatique.
• Migrer d'urgence dans un seul cas : la machine qui porte l'outil n'est plus maintenue. Un Nagios en parfait état sur un système sans correctifs de sécurité, exposé au réseau, n'est plus un vétéran, c'est une porte d'entrée.