# Zabbix ou Prometheus pour superviser un parc de serveurs WordPress

> Une trentaine de serveurs à surveiller et des alertes email qui n'alertent plus personne. Comparatif concret entre Zabbix et Prometheus pour un parc WordPress d'agence.

- Auteur : Clément Hadrot
- Publié le : 2022-04-27
- Mis à jour le : 2022-04-27
- Catégorie : Hébergement & serveurs
- URL : https://wpmoderne.dev.wordpress-developpement.fr/hebergement/zabbix-prometheus-supervision-parc-wordpress/

## L’essentiel

- Zabbix centralise agents et alerting dans un seul outil
- Prometheus s'appuie sur un écosystème modulaire à assembler
- Le choix dépend surtout du temps disponible en interne

Une agence cliente gérait une trentaine de serveurs WordPress avec, pour toute supervision, des scripts cron qui envoyaient un email en cas de souci. Le problème n'était pas le principe, mais l'usage réel : les alertes s'accumulaient dans une boîte partagée, personne ne les lisait plus après la troisième fausse alerte, et un serveur était resté injoignable douze heures avant qu'un client ne s'en plaigne. Il fallait un outil de supervision digne de ce nom, mais lequel ?

Deux candidats revenaient systématiquement dans les discussions : Zabbix, solution de supervision historique tout-en-un, et Prometheus, plus jeune, né chez SoundCloud puis adopté par la CNCF, pensé pour les métriques et souvent associé à Grafana pour la visualisation. Les deux sont open source, les deux savent surveiller un parc de cette taille. Leurs philosophies, en revanche, divergent nettement.

## Zabbix : une solution intégrée, pensée pour l'infrastructure classique

Zabbix installe un agent léger sur chaque serveur, qui remonte des métriques système (CPU, RAM, disque, processus) vers un serveur central. L'interface web permet de créer des déclencheurs (triggers), des actions et des escalades d'alerte sans écrire une ligne de code : un ingénieur système peu familier avec les langages de requête peut configurer une alerte sur la charge CPU en quelques clics.

Cette approche « batteries incluses » convient bien à une agence qui veut une solution posée une fois et qui tourne, sans maintenir un empilement d'outils séparés. La contrepartie est une certaine rigidité : personnaliser un tableau de bord avancé ou exporter des métriques vers un autre système demande de sortir des sentiers battus de l'interface.

## Prometheus : la supervision par métriques, modulaire

Prometheus fonctionne à l'inverse par « pull » : il interroge périodiquement des points d'exposition HTTP (des « exporters ») qui publient des métriques au format texte. Node Exporter couvre le système, mysqld_exporter la base de données, et il existe des exporters dédiés à nginx ou PHP-FPM. Le langage de requête PromQL permet des calculs riches — moyennes glissantes, dérivées, agrégations par groupe de serveurs — mais impose une vraie courbe d'apprentissage.

| Critère | Zabbix | Prometheus + Grafana |
| --- | --- | --- |
| Mise en place initiale | Rapide, agent + serveur central | Plus longue, plusieurs briques à assembler |
| Alerting natif | Intégré, riche en escalades | Nécessite Alertmanager en plus |
| Visualisation | Correcte, moins flexible | Excellente via Grafana |
| Rétention des métriques | Base SQL, verbeuse à grande échelle | Base de séries temporelles, optimisée |
| Courbe d'apprentissage | Douce | Plus raide (PromQL) |

> L'essentiel à retenir : Zabbix centralise agents et alerting dans un seul outil ; Prometheus s'appuie sur un écosystème modulaire à assembler ; Le choix dépend surtout du temps disponible en interne

## Ce que ça change concrètement pour un parc WordPress

Sur ce parc de trente serveurs, l'enjeu réel n'était pas seulement de récolter des métriques, mais de définir des seuils pertinents pour WordPress spécifiquement : nombre de processus PHP-FPM actifs proches de la limite du pool, temps de réponse de `admin-ajax.php`, taille des tables MySQL qui grossissent anormalement vite, certificats TLS proches de l'expiration. Ni Zabbix ni Prometheus ne connaissent WordPress nativement : tout se construit avec des vérifications personnalisées.

Sur Zabbix, cela s'écrit sous forme d'« items » personnalisés exécutant un script local et remontant sa sortie. Sur Prometheus, on écrit un petit exporter maison ou on détourne le Node Exporter avec son mode « textfile », qui lit des métriques déposées par un script cron dans un fichier au format attendu.

- Zabbix a été retenu pour les serveurs mutualisés à l'agence, où une seule personne administre l'ensemble sans expertise Prometheus
- Prometheus a pris le dessus sur les VPS où l'équipe technique voulait des tableaux de bord Grafana par client, partageables en lecture seule
- Les deux outils cohabitent finalement, chacun sur son périmètre, reliés à la même astreinte téléphonique

## Notre verdict

Zabbix gagne quand l'équipe veut une solution qui fonctionne dès l'installation, avec un alerting mature intégré et peu de composants à maintenir. Prometheus l'emporte quand l'agence veut des dashboards fins par client, une rétention longue de métriques et une intégration native avec d'autres outils cloud-native. Pour une agence de taille moyenne sans ingénieur SRE dédié, Zabbix reste souvent le choix le plus pragmatique ; pour une équipe qui investit déjà dans Grafana ou Kubernetes, Prometheus s'intègre naturellement dans l'existant.