Nagios : monitoring Core, plugins et NRPE (2026)

À la fin de cette page pilier, vous saurez pourquoi superviser après avoir déployé, compiler Nagios Core 4.5.3 sur Ubuntu 24.04, installer les plugins, exposer l’UI Apache, et étendre les checks via NRPE — puis relier cela au Capstone et au reste du menu.

Niveau : Intermédiaire · Temps estimé : 55–75 min · Versions cibles : Nagios Core 4.5.3 · plugins 2.4.12 · Ubuntu 24.04 LTS · Dernière vérification : 2026-09-13

Prérequis

• Ubuntu 24.04 LTS, 4 Go RAM, 2 vCPU, sudo
• Apache (ou Nginx) + PHP ; pare-feu HTTP/HTTPS
• Bases Linux (services, utilisateurs)
• Idéalement un service déjà déployé (Jenkins, un conteneur Docker, le Capstone)
• Coût estimé : 0 € en lab

Ce hub traduit et densifie le tutoriel live anglais (compile Core, webconf, plugins, NRPE, erreurs, FAQ) en français pédagogique. Les commandes de compilation et les versions 4.5.3 / 2.4.12 sont conservées : enrichir, jamais effacer.

Ce que nous allons construire

Hub Nagios (menu DevOps)
  ├── Pourquoi monitorer (après livrer)
  ├── Compile Nagios Core 4.5.3 + Apache + htpasswd
  ├── Plugins + NRPE (port 5666)
  ├── Premier hôte / service
  ├── Erreurs fréquentes + FAQ (5)
  └── Carte : intro Nagios, Azure Monitor, CloudWatch

Étape 1 — Pourquoi Nagios dans un parcours 2026

Livrer sans observer, c’est attendre que la prod vous fasse le job. Nagios Core reste une solution ouverte et prévisible pour hôtes, services et équipements : un ordonnanceur, des plugins qui renvoient OK/WARNING/CRITICAL/UNKNOWN, une UI, des notifications. En 2026, beaucoup d’équipes ajoutent Prometheus/Grafana ; Nagios n’est pas « mort » pour autant — surtout pour l’apprentissage des checks et pour les parcs hétérogènes.

Dans ce site, Nagios est le module 08 du menu DevOps, juste avant le Capstone : vous observez ce que Git → Maven → Docker → K8s → Ansible → Jenkins ont produit.

Étape 2 — Dépendances et compilation Core 4.5.3

Mettez à jour, installez la chaîne de build et Apache/PHP.

sudo apt update && sudo apt upgrade -y
sudo apt install -y build-essential libgd-dev openssl libssl-dev unzip 
  apache2 php php-gd php-mbstring
sudo systemctl status apache2
sudo useradd nagios || true
sudo groupadd nagcmd || true
sudo usermod -a -G nagcmd nagios
sudo usermod -a -G nagcmd www-data
cd /tmp
wget https://github.com/NagiosEnterprises/nagioscore/releases/download/release-4.5.3/nagios-4.5.3.tar.gz
tar xzf nagios-4.5.3.tar.gz
cd nagios-4.5.3
./configure --with-httpd-conf=/etc/apache2/sites-enabled
make all
sudo make install
sudo make install-init
sudo make install-config
sudo make install-commandmode
sudo make install-webconf
sudo systemctl enable nagios
sudo systemctl start nagios
sudo systemctl restart apache2
sudo htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin

UI : http://VOTRE_IP/nagios avec le compte créé. En prod : HTTPS, restriction IP, mot de passe fort.

Étape 3 — Plugins et NRPE

Les plugins sont les checks. Compilez la release 2.4.12, puis NRPE pour l’exécution distante (port 5666).

cd /tmp
wget https://github.com/nagios-plugins/nagios-plugins/releases/download/release-2.4.12/nagios-plugins-2.4.12.tar.gz
tar xzf nagios-plugins-2.4.12.tar.gz
cd nagios-plugins-2.4.12
./configure --with-nagios-user=nagios --with-nagios-group=nagios
make
sudo make install
sudo apt install -y nagios-nrpe-server nagios-plugins
sudo systemctl enable --now nagios-nrpe-server

Éditez nrpe.cfg : allowed_hosts doit contenir l’IP du serveur Nagios. Pare-feu : ouvrir 5666 depuis ce serveur seulement. Sur chaque hôte surveillé : client NRPE + plugins + commandes dans nrpe.cfg.

Intro concepts : Nagios introduction. Série monitoring : monitoring.

Étape 4 — Premier hôte, premier service

Définissez un hôte (localhost d’abord, puis la VM Capstone) et un service (ping, HTTP 8080, disque, load). Validez la config avant restart : une faute de syntaxe coupe toute la supervision. Habitude 2026 : versionnez /usr/local/nagios/etc/ dans Git (sans htpasswd) et déployez via Ansible.

Pour le Capstone banking : check HTTP sur le conteneur 8080 et check process Apache. Vous voyez l’UNSTABLE Jenkins et le trou réseau.

Habitudes et suite

Sauvegardez la conf avant chaque upgrade (stop service, recompile, restart). NRPE n’est pas le seul agent : exporters Prometheus existent ; NRPE reste léger pour des checks simples. Grafana peut s’y brancher. Haute dispo : deux serveurs, conf partagée via Git. Nagios XI (commercial) ajoute reporting et escalades — hors lab gratuit.

Conteneurs / Kubernetes : plugins officiels ou agent en DaemonSet ; images système côté K8s via registry.k8s.io. Ce hub ne remplace pas Prometheus, il enseigne le vocabulaire host/service/check.

Superviser pour de vrai (pas une UI vide)

Compiler Core et voir le logo Nagios n’est pas de la supervision. La supervision commence quand un check échoue et que quelqu’un est prévenu — ou au moins quand vous savez lire un CRITICAL sans paniquer.

Modèle mental. Un hôte a une adresse et une disponibilité. Un service appartient à un hôte et exécute un plugin. Le plugin renvoie un code et une ligne de texte. Nagios agrège, historise, notifie. Si vous sautez cette phrase, vous passerez des heures dans des fichiers cfg à copier-coller sans comprendre pourquoi localhost est vert et la VM Capstone rouge.

Périmètre lab. Surveillez peu, mais juste : ping de l’hôte, HTTP du conteneur banking (8080), process Apache, disque / au-delà de 80 %, charge. Cinq services bien nommés valent mieux qu’un import de soixante checks « au cas où ». Chaque check a un intervalle et un nombre de tentatives : trop nerveux, vous dormirez sous les fausses alertes ; trop mou, vous apprendrez l’incident par un utilisateur.

NRPE. Le Core n’exécute pas magiquement df sur une autre machine. NRPE écoute, vérifie que l’appelant est autorisé, lance le plugin local, renvoie le résultat. D’où allowed_hosts et le port 5666. Un « connection refused » n’est presque jamais « Nagios cassé » : c’est firewall, service down, ou IP oubliée. Testez le check sur l’hôte avant de l’ajouter au Core.

Conf as code. Traitez objects/ comme un dépôt. Une PR pour un nouvel hôte. Pas de modification live oubliée le vendredi. Ansible peut pousser les cfg et recharger Nagios (nagios -v puis reload). Vous reliez ainsi les modules 05 et 08 du menu.

Limites honnêtes. Nagios Core n’est pas une plateforme d’observabilité cloud. Pas de traces distribuées, pas de cardinality Prometheus. Pour Azure et AWS, le site a d’autres pages. Ici, l’objectif est de savoir poser un check et de l’accrocher au Capstone. Ensuite seulement, vous jugerez s’il faut Grafana, un exporter, ou Nagios XI.

Mettez à jour en 2026 comme en 2016 : backup etc/, stop, compile, restart, vérifier que les hôtes sont toujours là. Les versions 4.5.3 et 2.4.12 de ce hub sont le contrat du lab ; si vous montez, relisez les notes et retestez NRPE.

Quand Jenkins envoie un UNSTABLE par e-mail et que Nagios passe HTTP en CRITICAL, vous avez deux signaux cohérents. C’est le but du parcours, pas d’avoir « installé Nagios ».

Relier au Capstone et à Jenkins

Le job dummy du Capstone prouve la notification développeur. Nagios prouve que la machine et le port vivent après le pipeline. Les deux ne se remplacent pas. Un build rouge avec un hôte vert, c’est la CI. Un build vert avec HTTP CRITICAL, c’est la prod qui mentait. Apprenez à lire les deux tableaux.

Documentez l’URL de l’UI, le compte (pas le mot de passe dans Git), et la liste des checks du lab dans le README du Capstone. Un futur vous (ou un reviewer) doit pouvoir ouvrir Nagios et comprendre ce qui est censé être vert.

Erreurs fréquentes

Notifications, silence et hygiène d’alertes

Une UI verte n’aide personne à 3 h du matin. Décidez qui est notifié, quand, et comment (e-mail lab, pas un SMS payant). En formation, un e-mail Mailpit ou le même SMTP que Jenkins suffit : le geste compte. Un check qui flap (OK/CRITICAL en boucle) doit être calmé (retries, intervalle) avant d’ajouter d’autres hôtes. Autrement vous apprendrez à ignorer Nagios — le pire résultat pédagogique.

Nommez les services comme des phrases : HTTP banking 8080, disk root, pas check1. Quand le Capstone changera de port, vous saurez quoi éditer. Gardez localhost comme canari : si localhost passe CRITICAL, c’est le Core ou le plugin, pas l’appli métier.

Ne survillez pas Docker « en général ». Surveillez le résultat (HTTP, process). L’orchestration interne du daemon intéresse peu le client banking. De même, ne dupliquez pas Jenkins : le build rouge et le port mort sont deux histoires.

Enfin, planifiez un créneau mensuel : nagios -v, review des downtimes, plugins à jour. La supervision pourrit par abandon, pas par la compile du premier jour. Ce hub vous laisse un Core 4.5.3 propre ; à vous de ne pas le transformer en musée.

Si vous visez le cloud ensuite, emportez le vocabulaire (hôte, service, seuil, notification) vers Azure Monitor ou CloudWatch. Les boutons changent ; la question « qu’est-ce qui est cassé pour l’utilisateur ? » non.

FAQ

1. Comment mettre à jour Nagios sur Ubuntu 24.04 ?
Sauvegarder etc/, arrêter le service, recompiler la nouvelle archive, redémarrer. Ne jamais « écraser et prier ».

2. NRPE peut-il être remplacé ?
Oui : agent officiel ou exporters. NRPE reste supporté et pédagogique.

3. Comment sécuriser l’UI ?
HTTPS, restriction IP Apache, mots de passe forts, pas d’admin par défaut exposé sur Internet.

4. Nagios et les conteneurs ?
Oui, via plugins ou agent. Pour un cluster, voyez aussi la stack K8s du site.

5. Quelle version stable en septembre 2026 ?
Nagios Core 4.5.3 est la release recommandée ici pour Ubuntu 24.04, avec plugins 2.4.12.

Un après-midi type (pour ancrer)

Matin : compile Core 4.5.3, UI, login. Midi : plugins, un check localhost HTTP ou ping. Après-midi : NRPE sur une deuxième VM, allowed_hosts, un check disque. Si vous arrivez à faire passer un CRITICAL volontaire (arrêter Apache) puis un retour OK, le hub a réussi. Le reste (Grafana, HA, XI) attend.

Écrivez dans le README du lab : URL, version Core, liste des services, port 5666. Un reviewer du Capstone doit comprendre le tableau sans vous appeler. Reliez l’e-mail Jenkins UNSTABLE et le CRITICAL HTTP : deux portes, une vérité métier (l’API banking répond-elle ?).

N’ajoutez pas vingt hôtes « pour faire joli ». Deux hôtes honnêtes valent mieux. La supervision est une discipline de moins d’alertes, pas plus. Ce message est volontairement répété : les installs Nagios abandonnées le sont parce que le bruit a gagné.

Pour la densité pédagogique : souvenez-vous que le plugin est un contrat (code de sortie + texte). Vous pouvez écrire un plugin de dix lignes qui vérifie un fichier de santé. Vous n’êtes pas limité aux checks livrés. En 2026, c’est toujours vrai, que vous restiez sur Core ou que vous partiez vers un exporter. Le vocabulaire de ce hub vous suit.

Points clés à retenir

• Superviser après avoir livré : hosts, services, notifications.
• Core 4.5.3 compilé, Apache, htpasswd, plugins, NRPE 5666.
• Versionnez la conf ; backup avant upgrade.
• Pont Capstone : HTTP 8080 + Apache.
• Alternatives cloud déjà sur le site (Azure Monitor, CloudWatch).

Pour aller plus loin

• Nagios introduction
• Grafana, HA, discovery Ansible
• Capstone puis observabilité cloud

Maillage série DevOps