Prometheus, Uptime Kuma, Centreon : comparer les outils

Zabbix n'est pas le seul outil de supervision : Prometheus (souvent avec Grafana) domine dans les environnements de conteneurs, Uptime Kuma surveille simplement la disponibilité de quelques sites, Centreon et Nagios restent très présents en France, et d'autres outils occupent des niches. Ce chapitre présente le principe de chacun, montre l'installation d'Uptime Kuma pour une petite structure, et donne une méthode pour choisir un outil et justifier ce choix devant une commission.

Prometheus et Grafana

Prometheus est un logiciel libre de collecte et de stockage de métriques, créé en 2012 chez SoundCloud et aujourd'hui projet de la Cloud Native Computing Foundation (version 3 en 2026). Son modèle est différent de celui de Zabbix.

• La collecte par interrogation HTTP. Chaque cible publie ses métriques sur une page web, par convention http://cible:port/metrics, en texte. Prometheus la lit (scrape) à intervalle régulier.
• Les exportateurs (exporters) publient cette page pour ce qui ne la publie pas lui-même : node_exporter pour un serveur Linux (port 9100), windows_exporter pour Windows, snmp_exporter pour les équipements SNMP, blackbox_exporter pour tester un site ou un port de l'extérieur. Les applications modernes et Kubernetes publient leurs métriques directement.
• Des séries temporelles à étiquettes. Chaque mesure a un nom et des étiquettes : node_filesystem_avail_bytes{instance="192.168.10.179:9100",mountpoint="/"}.
• Le langage PromQL interroge et calcule : 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) donne l'utilisation du processeur de chaque machine.
• Les alertes sont des règles PromQL évaluées par Prometheus, puis envoyées à un composant séparé, Alertmanager, qui les regroupe, les fait taire pendant une maintenance et les route (courriel, Teams, Slack).
• Pas d'interface de configuration : tout se fait dans des fichiers YAML, et Grafana sert d'interface de consultation.

Un extrait de configuration et une règle d'alerte :

# /etc/prometheus/prometheus.yml
global:
  scrape_interval: 30s
rule_files:
  - /etc/prometheus/regles-sorbier.yml
scrape_configs:
  - job_name: "serveurs-linux"
    static_configs:
      - targets: ["192.168.10.179:9100", "192.168.10.180:9100"]

# /etc/prometheus/regles-sorbier.yml
groups:
  - name: sorbier
    rules:
      - alert: DisqueBientotPlein
        expr: (1 - node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) * 100 > 85
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Disque / de {{ $labels.instance }} rempli à plus de 85 %"

La clause for: 5m joue le rôle du min(…,5m) d'un déclencheur Zabbix : la condition doit rester vraie cinq minutes.

Pour une infrastructure de PME faite de serveurs, de switchs et d'un pare-feu, Zabbix demande moins de travail. Pour une plateforme de conteneurs où les instances naissent et meurent chaque heure, Prometheus est mieux adapté. Les deux cohabitent souvent, avec Grafana pour les afficher ensemble.

Uptime Kuma pour une petite structure

Uptime Kuma est un outil libre de surveillance de disponibilité : il teste à intervalle régulier des sites web, des ports, des noms DNS, des machines (ping), et alerte quand l'un d'eux ne répond plus. Il s'installe en un conteneur et se configure entièrement à la souris. La version 2, sortie en octobre 2025 (2.5 en novembre 2026), ajoute notamment la prise en charge de MariaDB pour stocker ses données.

Prends le cas d'un cabinet comptable de douze personnes, client du prestataire où tu fais ton stage : un site vitrine chez un hébergeur, une messagerie en ligne, un NAS au bureau et un accès VPN. Personne n'a le temps d'administrer Zabbix. Uptime Kuma, sur une petite VM ou un serveur hébergé hors du bureau (pour voir le bureau tomber), suffit.

# compose.yaml
services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    container_name: uptime-kuma
    restart: unless-stopped
    volumes:
      - ./data:/app/data
    ports:
      - "3001:3001"

docker compose up -d
docker compose ps

Ouvre http://serveur:3001 : à la première visite, Uptime Kuma demande où stocker ses données (SQLite intégré suffit ici) et crée le compte administrateur. Publie-le ensuite derrière un proxy inverse en HTTPS, et ne laisse pas l'interface ouverte à tout Internet sans protection.

Puis Add New Monitor, un par service :

Les notifications (courriel SMTP, Teams, Slack, Telegram, Discord et des dizaines d'autres) se configurent une fois et s'attachent aux moniteurs. Une page de statut publique (Status Pages) montre aux salariés l'état des services, ce qui évite dix appels lors d'une panne de la messagerie en ligne. Les maintenances suspendent les alertes pendant une intervention.

Le moniteur Push sert aussi chez Sorbier, de signal de vie de Zabbix (chapitre 9) : une tâche planifiée sur srv-journaux appelle chaque minute l'adresse de push d'une instance d'Uptime Kuma hébergée hors du siège, si et seulement si le serveur Zabbix tourne.

# /etc/cron.d/signal-de-vie-zabbix
* * * * * root systemctl is-active --quiet zabbix-server && curl -fsS -m 10 "https://statut.sorbier.example/api/push/Xk29fJq7La?status=up&msg=OK" >/dev/null

Centreon et Nagios

Nagios Core (1999) a fixé une convention que tout le métier connaît : un greffon (plugin) est un petit programme qui teste une chose et répond par un code de retour :

Par exemple, check_disk -w 20% -c 10% -p / répond WARNING s'il reste moins de 20 % d'espace libre sur /, CRITICAL sous 10 %. Le moteur planifie les tests, garde l'état de chaque service, et notifie. Pour tester l'intérieur d'une machine distante, Nagios s'appuyait sur l'agent NRPE. La configuration se fait dans des fichiers texte (hôtes, services, contacts, commandes), ce qui la rend fastidieuse sur un grand parc. Un problème passe d'abord par un état SOFT (le test est refait quelques fois) avant de devenir HARD et d'être notifié : c'est l'équivalent des tentatives et des durées de Zabbix.

Centreon, éditeur français, est né comme une interface web pour Nagios ; il a ensuite développé son propre moteur, compatible avec les greffons de type Nagios, et une très large bibliothèque de greffons et de modèles. Il existe une édition libre et des éditions commerciales. On le rencontre beaucoup dans les administrations, les collectivités et les grandes entreprises françaises, et dans des offres d'alternance : si ton entreprise l'utilise, tout ce cours se transpose (hôtes, modèles, seuils, notifications, dépendances, maintenances).

D'autres outils : Icinga et Checkmk, issus de Nagios ; LibreNMS, centré sur les équipements réseau en SNMP, avec une découverte automatique très efficace ; PRTG, commercial, très simple à prendre en main sous Windows, facturé au nombre de « capteurs » ; Netdata, qui montre en direct des milliers de métriques par machine.

Choisir et justifier

À l'E6 comme en entreprise, on ne choisit pas un outil parce qu'on le connaît : on compare des solutions selon des critères issus du besoin, puis on justifie. Une matrice de choix pondérée rend le raisonnement visible.

Pour Sorbier (environ 60 hôtes, des switchs Cisco, pfSense, Windows et Linux, une agence distante, un budget limité, une petite équipe) :

Le calcul : pour Zabbix, 3 × 5 + 3 × 5 + 2 × 5 + 2 × 3 + 2 × 5 = 56. Les notes de 1 à 5 se discutent, et c'est le but : la matrice t'oblige à dire pourquoi. Uptime Kuma perd sur la couverture (pas de mesures internes), Prometheus sur la couverture réseau et la prise en main, Centreon reste un bon second choix.

Exercices

- alert: ServeurInjoignable
  expr: up{job="serveurs-linux"} == 0
  for: 3m