Nagios sur Hyper-V : guide du monitoring de serveurs

Le monitoring de serveurs avec Nagios sur Hyper-V gagne encore sa place en 2026, et voici tout le montage du début à la fin. Monte une VM Ubuntu 24.04, compile Nagios Core 4.5 depuis le tarball officiel, pointe des probes sur HTTP, SSH, MySQL et disque, puis branche le mail et Telegram pour que les alertes te trouvent vraiment. Hyper-V t'offre des checkpoints pour revenir en arrière, un VHDX qui part dans la sauvegarde que tu fais déjà, et un surveillant qui vit à l'écart des choses qu'il surveille. Compte deux à trois heures pour la première installation sur une VM vierge. Après, ajouter un host, c'est cinq minutes.

Nagios Core, c'est le truc pas sexy. La bête de somme vers laquelle je reviens toujours. Il surveille des salles serveurs depuis 1999, et allez savoir comment, en 2026, il gagne encore sa place dans plein de petites et moyennes boîtes. La mienne aussi. Je le fais tourner en VM sur Hyper-V (Windows Server, ou Windows 11 Pro avec le rôle Hyper-V activé), et franchement cette config m'apporte des trucs auxquels je tiens sans doute plus que de raison : une machine de monitoring qui ne coûte rien de plus, des snapshots que je peux restaurer quand je casse quelque chose. Le VHDX part dans la sauvegarde que je fais déjà. Et le surveillant vit à l'écart des choses qu'il surveille. Cet article déroule tout, du début à la fin. Monter la VM, glisser Ubuntu 24.04 à l'intérieur, compiler Nagios, pointer des probes sur HTTP / SSH / MySQL / disque, puis brancher le mail et Telegram pour que les alertes te trouvent vraiment. Les bonnes habitudes de maintenance viennent à la fin, parce que ce sont elles qui gardent la machine honnête au lieu de la laisser te mentir tranquillement en pleine figure. Compte deux à trois heures pour la première installation sur une VM vierge. Après ça ? Ajouter un host, c'est cinq minutes. Dix si tu prends ton temps.

Pourquoi Nagios + Hyper-V en 2026

Le marché du monitoring est bruyant et bondé, alors pourquoi je continue d'aller chercher le vieux truc ? Les plugins, surtout. Il y a plus de 5 000 checks communautaires dans monitoring-plugins, et je n'ai encore jamais croisé une charge de travail qu'aucun d'eux ne savait surveiller. Et puis il y a le modèle de données, brut dans le meilleur sens du terme. Les hosts sont UP / DOWN / UNREACHABLE. Les services tombent en OK / WARNING / CRITICAL / UNKNOWN. C'est tout le vocabulaire. Je peux garder l'état complet de mon parc dans la tête, et ça vaut une petite fortune à 3 h du matin quand je suis à moitié réveillé et qu'un truc est en feu. La config aide aussi : du texte brut, gardé dans git. Pas de base de données propriétaire qui ronronne quelque part où je ne peux pas la voir. Rien qui me tende une embuscade le jour d'une mise à jour.

Faire tourner Nagios sur Hyper-V règle discrètement les parties du self-hosting qui mordent d'habitude. Je prends un checkpoint avant de toucher à la config, comme ça le jour où je massacre un fichier (et ce jour arrive), je n'ai pas accidentellement rendu mon propre surveillant aveugle. Le VHDX part dans la sauvegarde Windows que je fais déjà. Pas de danse séparée à se rappeler. Et il y a l'isolation, qui compte plus que les gens ne le croient. La dernière chose que tu veux, c'est que ton monitoring meure dans la même panne exacte que les machines pour lesquelles il est censé hurler. Hyper-V est gratuit avec n'importe quelle licence Windows Pro ou Server déjà posée sur ton réseau. Donc tout ça ne te coûte rien.

Étape 1 : créer la VM Nagios dans Hyper-V

Ouvre le Gestionnaire Hyper-V (Windows + R, tape virtmgmt.msc). Clic droit sur ton serveur dans le volet de gauche, puis Nouveau > Ordinateur virtuel. Rien de compliqué pour l'instant.

Voilà la forme que je donne à une VM Nagios fraîche qui va surveiller une cinquantaine de hosts. Allège-la pour un lab si tu veux. C'est juste la base avec laquelle je suis à l'aise :

• Génération 2 (UEFI, Secure Boot). Ubuntu moderne ne démarre pas proprement en Gen 1, alors ne rogne pas là-dessus.
• 2 vCPU et 4 Go de RAM (dynamique, min 2 Go / max 6 Go).
• VHDX de 30 Go en disque dynamique sur un volume rapide. Nagios touche à peine au disque. Mais les logs s'empilent au fil des mois, alors donne-lui de la marge quand même.
• Commutateur virtuel externe branché sur ton LAN de management. La VM doit pouvoir vraiment atteindre les hosts qu'elle sonde, évidemment.
• Si ton DHCP distribue ses baux par réservation MAC, fige la MAC de la VM en statique. Sinon tu vas courir après une IP qui bouge plus tard.

Un détail que tout le monde rate. Dans les paramètres de la VM, sous Sécurité, règle le modèle de secure boot sur Microsoft UEFI Certificate Authority, pas celui de Windows par défaut. C'est le certificat qui correspond au bootloader signé d'Ubuntu. Laisse-le mal réglé et la VM ne démarre tout simplement pas, et tu n'auras aucune idée pourquoi, et tu vas y perdre une heure. Tant que tu y es, active tout sous Services d'intégration. La « Synchronisation de l'heure » surtout. Tu veux que l'horloge de cette VM soit collée à celle de l'hôte, parce que la dérive d'horloge sur une machine de monitoring déclenche les fausses alertes les plus bizarres. Celle-là m'a pris un temps fou à débusquer la première fois.

Étape 2 : installer Ubuntu 24.04 LTS et le durcir

Récupère l'ISO serveur d'Ubuntu 24.04 LTS sur ubuntu.com et monte-la sur la VM. Démarre dessus, déroule l'installeur. Mes choix, à chaque fois : installation minimale, on saute LVM (tu n'en as pas besoin ici, ça ajoute juste une couche à laquelle penser), on coche OpenSSH. Puis tu dis non à tous les autres snaps qu'il essaie de te refourguer. Une fois en route, connecte-toi et lance ma passe de durcissement habituelle des cinq premières minutes :

sudo apt update
sudo apt upgrade -y
sudo apt install -y ufw fail2ban unattended-upgrades

# Open SSH and (later) Nagios web UI
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

# Set hostname for clarity
sudo hostnamectl set-hostname nagios-01

Tu veux le traitement complet ? SSH par clé uniquement, AppArmor en mode enforce, auditd, tout le tralala. Je garde tout ça dans notre checklist de durcissement Ubuntu 24.04, et tu devrais vraiment aller le faire. Réfléchis à ce que cette machine contient en réalité. Des clés SSH et des identifiants pour la moitié de ton parc. Un attaquant qui prend le serveur de monitoring obtient une carte de tout ce que tu possèdes. Verrouille-le avant qu'il ne voie jamais la production.

IP statique recommandée. Édite /etc/netplan/00-installer-config.yaml pour fixer une IP statique. J'ai appris ça à la dure, bêtement, lentement. Laisse le DHCP déplacer l'adresse de ton serveur de monitoring et tu vas cramer un après-midi entier à fixer « pourquoi toutes les probes échouent d'un coup ? » avant que ça ne fasse enfin tilt.

Étape 3 : installer Nagios Core 4.5

Petit avertissement. Le Nagios dans l'apt d'Ubuntu 24.04 est en 4.4, et la branche 4.5.x a corrigé pas mal de trucs qui valent le coup. Donc je zappe le paquet et je compile directement depuis le tarball officiel. Ça fait plus peur que ça n'en a l'air. Copie le bloc ci-dessous, attends deux minutes, c'est fait.

# Build dependencies
sudo apt install -y autoconf gcc libc6 make wget unzip apache2 apache2-utils \
  php libapache2-mod-php libgd-dev libssl-dev libmcrypt-dev bc gawk dc build-essential

# Create the nagios user/group
sudo useradd nagios
sudo groupadd nagcmd
sudo usermod -aG nagcmd nagios
sudo usermod -aG nagcmd www-data

# Download and extract Nagios Core 4.5.x
cd /tmp
wget https://github.com/NagiosEnterprises/nagioscore/releases/download/nagios-4.5.9/nagios-4.5.9.tar.gz
tar xzf nagios-4.5.9.tar.gz
cd nagios-4.5.9
./configure --with-command-group=nagcmd
sudo make all
sudo make install
sudo make install-init
sudo make install-config
sudo make install-commandmode
sudo make install-webconf

# Install the standard plugins
cd /tmp
wget https://nagios-plugins.org/download/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
sudo make
sudo make install

Maintenant, définis le mot de passe de l'interface web et démarre le service.

sudo htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin
# Enter a strong password when prompted

sudo systemctl enable nagios apache2
sudo systemctl start nagios apache2
sudo a2enmod cgi rewrite
sudo systemctl reload apache2

Pointe ton navigateur sur http://nagios-01.local/nagios (ou juste l'IP, si le mDNS fait des siennes). La page de login Nagios se charge. Connecte-toi en nagiosadmin avec le mot de passe que tu viens de définir. Ton serveur de monitoring tourne.

Nagios Core Version 4.5.9
Current Status > Hosts: 1 UP (localhost)
 Services: 8 OK

Étape 4 : configurer ton premier host et ses probes

Nagios lit sa config depuis /usr/local/nagios/etc/objects/. Une habitude m'a évité plus d'ennuis que tout le reste ici. Un fichier par cible surveillée. Ne fourre pas tout dans un seul énorme .cfg. Quand un truc casse à 2 h du matin, tu veux ouvrir précisément le host qui déconne, pas faire défiler un mur de 600 lignes pour le chercher.

sudo mkdir -p /usr/local/nagios/etc/servers
sudo nano /usr/local/nagios/etc/nagios.cfg
# Add this line:
cfg_dir=/usr/local/nagios/etc/servers

Voici un vrai fichier host que je déposerais dans /usr/local/nagios/etc/servers/web01.cfg. Un serveur web, avec les quatre checks que je veux presque toujours en surveillance dès le premier jour :

define host {
    use             linux-server
    host_name       web01
    alias           Production web server
    address         10.0.0.10
    max_check_attempts 5
    check_period    24x7
    contact_groups  admins
}

define service {
    use                 generic-service
    host_name           web01
    service_description HTTPS
    check_command       check_http!--ssl -H peoplearegeek.com
}

define service {
    use                 generic-service
    host_name           web01
    service_description SSH
    check_command       check_ssh
}

define service {
    use                 generic-service
    host_name           web01
    service_description Disk root partition
    check_command       check_disk!20%!10%!/
}

define service {
    use                 generic-service
    host_name           web01
    service_description MySQL port
    check_command       check_tcp!3306
}

Ces quatre-là surveillent un host depuis l'extérieur. Utile, mais limité. Quand tu veux voir à l'intérieur de la machine, le CPU et la mémoire, le disque par partition, ou si tel process précis respire encore, il te faut NRPE qui tourne sur la cible pour que Nagios puisse lui demander directement :

# On the monitored host
sudo apt install -y nagios-nrpe-server monitoring-plugins
# Add nagios-01 IP to allowed_hosts in /etc/nagios/nrpe.cfg
sudo systemctl restart nagios-nrpe-server

Valide toujours avant de recharger. Ce check -v m'a rattrapé plus de coquilles que je n'oserais l'avouer à voix haute, et c'est la différence entre un reload propre et un serveur de monitoring qui refuse catégoriquement de démarrer :

sudo /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# Should print "Things look okay - No serious problems were detected"

sudo systemctl reload nagios

Étape 5 : alertes mail (SMTP via msmtp)

Quand Nagios veut t'alerter, il appelle /usr/bin/mail. Tu pourrais monter un Postfix complet pour ça. Honnêtement, ne le fais pas. Sur une machine de monitoring c'est démesuré, et c'est juste un daemon de plus à patcher. J'utilise msmtp, un remplaçant de sendmail prêt à l'emploi qui relaie via le serveur SMTP que tu as déjà sous la main (celui de ton hôte, SendGrid, SES, peu importe). Petit et ennuyeux. Il fait son boulot, point.

sudo apt install -y msmtp msmtp-mta mailutils

# Edit /etc/msmtprc
sudo nano /etc/msmtprc

defaults
auth           on
tls            on
tls_starttls   on
logfile        /var/log/msmtp.log

account        default
host           smtp.your-provider.com
port           587
from           nagios@yourdomain.com
user           nagios@yourdomain.com
password       your-smtp-app-password

Ce fichier contient ton mot de passe SMTP en clair. Alors verrouille les permissions à 600 avant de faire quoi que ce soit d'autre, puis lance un test :

sudo chmod 600 /etc/msmtprc
echo "Test from nagios" | mail -s "Nagios test" you@yourdomain.com
# You should receive the email in less than a minute

Nagios livre déjà les commandes notify-host-by-email et notify-service-by-email dans /usr/local/nagios/etc/objects/commands.cfg, donc tu n'as rien à écrire. Ce qui reste est minime. Mets ta vraie adresse dans /usr/local/nagios/etc/objects/contacts.cfg (par défaut elle pointe sur nagios@localhost, ce qui ne mène précisément nulle part), recharge, puis prouve que ça marche en arrêtant brièvement un service surveillé. Ne fais pas confiance à la config tant que tu n'as pas vu cet e-mail atterrir pour de vrai dans ta boîte. Vu, sous tes yeux.

Étape 6 : alertes Telegram via un bot webhook

Le mail, c'est la trace écrite. Telegram, c'est la tape sur l'épaule qui dit « arrête de scroller, regarde ça maintenant ». Le mail finit enseveli sous quarante autres trucs, alors qu'une vibration de téléphone passe au travers direct. Je trouve que c'est le bout que la plupart des gens zappent puis regrettent, et c'est peut-être cinq minutes de boulot.

Écris à @BotFather sur Telegram, crée un bot, garde le token qu'il te file. Ensuite, et c'est la partie que tout le monde rate, envoie /start à ton tout nouveau bot depuis ton propre compte. Loupe ça et le bot ne peut littéralement pas te répondre. Ça piège quasiment tout le monde la première fois. Ouvre https://api.telegram.org/bot<TOKEN>/getUpdates dans un navigateur et ton chat_id est là, posé en plein dans le JSON.

Dépose ce script de notification dans /usr/local/nagios/libexec/notify-telegram.sh et colle ton token et ton chat ID tout en haut :

#!/bin/bash
TOKEN="123456:ABC-DEF..."
CHAT_ID="987654321"

MESSAGE="*[$1]* $2: $3
Host: \`$4\`
Service: \`$5\`
State: $6 ($7)
$8"

curl -s -X POST "https://api.telegram.org/bot${TOKEN}/sendMessage" \
    -d "chat_id=${CHAT_ID}" \
    -d "parse_mode=Markdown" \
    -d "text=${MESSAGE}"

sudo chmod +x /usr/local/nagios/libexec/notify-telegram.sh
sudo chown nagios:nagios /usr/local/nagios/libexec/notify-telegram.sh

Maintenant dis à Nagios que la commande existe, puis boulonne-la sur ton contact admin juste à côté de l'e-mail pour que les alertes frappent les deux canaux d'un coup :

# /usr/local/nagios/etc/objects/commands.cfg - append:
define command {
    command_name notify-by-telegram
    command_line /usr/local/nagios/libexec/notify-telegram.sh \
      "$NOTIFICATIONTYPE$" "$HOSTSTATE$" "$SERVICESTATE$" \
      "$HOSTNAME$" "$SERVICEDESC$" "$SERVICESTATE$" \
      "$SERVICESTATEID$" "$SERVICEOUTPUT$"
}

# /usr/local/nagios/etc/objects/contacts.cfg - add to the contact block:
service_notification_commands notify-service-by-email,notify-by-telegram
host_notification_commands    notify-host-by-email,notify-by-telegram

Recharge, puis force un vrai test en faisant tomber un service surveillé. Mon téléphone vibre une seconde ou deux plus tard, et c'est là que j'arrête de bidouiller.

Étape 7 : dashboard et vues personnalisés

Soyons honnêtes sur l'interface Nagios d'origine. Elle marche. Elle ressemble aussi à un truc stylé pour la dernière fois en 2009, parce que c'est le cas. Tu n'es pas obligé de vivre avec, cela dit. Deux projets communautaires lui collent un visage moderne sans jamais toucher au moteur central :

• Thruk (thruk.org) est celui que je vais chercher en boucle. C'est un frontend Perl qui lit la même config Nagios que tu as déjà écrite, puis te donne un vrai filtrage, du reporting sur les heures ouvrées et une UI qui ne s'effondre pas à la seconde où tu l'ouvres sur un téléphone. L'installation tient en une ligne : sudo apt install thruk.
• NagVis superpose l'état des hosts sur une vraie image. Un schéma réseau, disons, ou le plan d'étage de ton bâtiment. C'est ce que je sors quand un manager veut des voyants verts et rouges plutôt qu'une grille de hostnames qu'il ne lira jamais.

Et tu n'es pas obligé d'en choisir un. Les deux tournent sans problème à côté de la vieille UI CGI. Alors essaie-les, garde celui dont ton équipe arrête de se plaindre.

Étape 8 : snapshot et maintenance régulière

Tant que l'installation est encore propre et ennuyeuse, prends un checkpoint Hyper-V (clic droit sur la VM > Point de contrôle). C'est ton bouton annuler. Le jour où une modif de config part de travers, et ça arrivera, tu reviens à celui-ci et te voilà entier en quelques secondes au lieu de reconstruire la machine à partir de rien. Prends l'habitude d'en prendre un avant chaque vrai changement. Le toi du futur dit merci.

Et le monitoring, ce n'est pas « on installe et on oublie », même si on adorerait tous. Le rythme que je tiens, plus ou moins :

• Chaque semaine : survole /var/log/nagios.log à la recherche du même warning qui revient encore et encore. Cette répétition, c'est presque toujours un service qui flappe. Ça veut dire que tes seuils de flapping ont besoin d'un coup de pouce, pas que le host est en train de mourir pour de bon.
• Chaque mois : sudo apt upgrade la VM. Checkpoint d'abord, redémarrage de Nagios après. Dans cet ordre, parce que la seule fois où tu sautes le checkpoint, c'est la fois où la mise à jour bouffe quelque chose.
• Chaque trimestre : réconcilie la liste des hosts avec la réalité. Chaque machine que tu surveilles devrait encore exister. Chaque machine qui existe devrait être surveillée. C'est cette deuxième moitié le tueur silencieux, parce que le serveur que personne ne s'est donné la peine d'ajouter, c'est celui qui tombe à 3 h du matin sans qu'aucune alerte ne parte.
• Chaque année : revisite tes niveaux WARNING / CRITICAL. Après douze mois tu as enfin de vrais chiffres sur le comportement de ce parc, et des seuils ajustés battent les approximations sorties de la boîte à tous les coups.

Pièges courants et comment les éviter

• La fatigue d'alerte. À la seconde où ton équipe commence à balayer les e-mails de Nagios sans les lire, tu as déjà perdu. Et c'est un problème de seuils plus qu'un problème de personnes. Les alertes crient au loup. Pousse le niveau WARNING vers le haut jusqu'à ce qu'une notification veuille dire de façon fiable « un humain doit regarder ça », pas « Nagios est encore bavard ».
• Le firewall des hosts surveillés. Celui-là m'a eu plus d'une fois. Un host va parfaitement bien mais affiche DOWN, et c'est parce que son propre firewall jette discrètement la probe. Lance sudo ufw allow from 10.0.0.5 sur la cible (mets ta vraie IP Nagios) et regarde-le repasser au vert.
• La dérive d'horloge entre hosts. Quand Nagios et un host surveillé ne sont pas d'accord sur l'heure qu'il est, deux trucs vicieux arrivent. Tes logs cessent de s'aligner. Et les probes SSL se mettent à échouer au hasard, sans cause évidente, ce qui va te rendre dingue. Vérifie le NTP partout avec timedatectl status. Trente secondes de vérif, ça t'épargne des heures.
• Oublier de surveiller Nagios lui-même. C'est le piège qui mord le plus fort. Si le serveur de monitoring plante, il se tait, et le silence se lit exactement comme « tout va bien ». Alors pose un petit check sur une deuxième machine (un VPS pas cher, voire ton laptop) qui confirme juste que l'interface web de Nagios répond encore. Qui surveille le surveillant ? Ce doit être toi. Il ne peut pas se surveiller lui-même.

Sources et pour aller plus loin

• Nagios, documentation

Questions fréquentes