Supervision avec Zabbix

Une installation Zabbix qui fonctionne en test peut s'effondrer en six mois de production : base de 200 Go, frontend qui rame, serveur unique dont la panne rend toute l'infrastructure aveugle. Ce chapitre couvre ce qui fait tenir Zabbix dans la durée : tableaux de bord utiles, automatisation par l'API, volumétrie, haute disponibilité, sécurité et montées de version.

Les tableaux de bord

Le tableau de bord global montre par défaut les problèmes en cours et la disponibilité des hôtes. C'est un bon début, rarement suffisant. Zabbix 7.0 a ajouté plusieurs widgets : Gauge, Pie chart, Honeycomb pour voir l'état d'un parc d'un coup d'œil, Top triggers, Item navigator et Host navigator.

Je construis trois types de tableaux de bord :

1. L'écran d'astreinte : uniquement les problèmes de sévérité High et Disaster, sans acquittement. S'il est vide, tout va bien. Il doit tenir sur un écran sans défilement.
2. Un tableau par service : facturation, site public, API. Les métriques qui comptent pour ce service, filtrées par tag, quelle que soit la machine qui les porte.
3. Le tableau de capacité : tendances d'espace disque, de mémoire et de trafic sur trois mois. C'est lui qui permet de commander un disque avant qu'il soit plein.

Les templates officiels incluent aussi leurs propres tableaux de bord, visibles depuis la fiche de chaque hôte.

Grafana

Pour ceux qui préfèrent l'affichage de Grafana, le plugin alexanderzobnin-zabbix-app lit les données de Zabbix par son API. Zabbix reste la source des métriques et des alertes, Grafana devient une vitrine. C'est aussi une façon de mettre côte à côte, dans un même tableau, les métriques de Zabbix et celles de Prometheus.

L'API

Tout ce qui se fait dans l'interface se fait aussi par l'API JSON-RPC, sur l'URL api_jsonrpc.php du frontend. Créer des hôtes, poser une maintenance, lister les problèmes, exporter des templates : tout s'automatise.

S'authentifier avec un jeton

Créez un utilisateur dédié à l'automatisation, avec un rôle limité aux actions nécessaires, puis un jeton dans Users > API tokens. Le jeton passe dans l'en-tête Authorization :

ZBX_URL="https://zabbix.example.com/api_jsonrpc.php"
ZBX_TOKEN="le-jeton-genere"
 
curl -s "$ZBX_URL" \
  -H "Content-Type: application/json-rpc" \
  -H "Authorization: Bearer $ZBX_TOKEN" \
  -d '{
    "jsonrpc": "2.0",
    "method": "problem.get",
    "params": {
      "output": ["eventid", "name", "severity", "clock"],
      "severities": [4, 5],
      "recent": true,
      "sortfield": ["eventid"],
      "sortorder": "DESC"
    },
    "id": 1
  }'

Cette requête renvoie les problèmes en cours de sévérité High (4) et Disaster (5). Le même modèle sert pour toutes les méthodes : host.get, host.create, template.get, maintenance.create…

Une maintenance pendant un déploiement

Cas d'usage classique : un pipeline de déploiement pose une maintenance de quinze minutes sur les serveurs concernés, pour qu'un redémarrage ne déclenche pas l'astreinte.

NOW=$(date +%s)
 
curl -s "$ZBX_URL" \
  -H "Content-Type: application/json-rpc" \
  -H "Authorization: Bearer $ZBX_TOKEN" \
  -d "{
    \"jsonrpc\": \"2.0\",
    \"method\": \"maintenance.create\",
    \"params\": {
      \"name\": \"Déploiement $NOW\",
      \"active_since\": $NOW,
      \"active_till\": $((NOW + 900)),
      \"groups\": [{\"groupid\": \"42\"}],
      \"timeperiods\": [{\"period\": 900, \"timeperiod_type\": 0}]
    },
    \"id\": 1
  }"

groupid est l'identifiant du groupe d'hôtes, visible dans l'URL de sa page ou via hostgroup.get. timeperiod_type: 0 désigne une période unique. Appelé depuis un workflow GitHub Actions, avec le jeton stocké en secret, ce bloc rend les déploiements silencieux pour l'astreinte, sans masquer un problème qui durerait au-delà.

La base de données, vrai goulot d'étranglement

Zabbix écrit en permanence. 10 000 items collectés chaque minute, c'est plus de 14 millions de lignes d'historique par jour. La base grossit, les requêtes ralentissent, le housekeeper (le processus qui supprime les vieilles données) n'arrive plus à suivre.

Historique et tendances

Un graphique sur un an n'a pas besoin des valeurs brutes : il lit les tendances. Réglez ces durées dans Administration > Housekeeping, en cochant Override item history period et Override item trend period pour imposer une politique globale, quels que soient les réglages des templates. C'est le réglage qui a le plus d'effet sur la taille de la base.

TimescaleDB

Sur PostgreSQL, l'extension TimescaleDB découpe les tables d'historique en morceaux par période et les compresse. Le housekeeping devient la suppression de morceaux entiers au lieu de millions de DELETE, et la compression divise souvent la taille de l'historique par dix.

Après avoir installé TimescaleDB selon la documentation de l'éditeur, on l'active sur la base Zabbix, serveur arrêté :

systemctl stop zabbix-server
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
cat /usr/share/zabbix-sql-scripts/postgresql/timescaledb/schema.sql | sudo -u zabbix psql zabbix
systemctl start zabbix-server

Puis on active la compression dans Administration > Housekeeping. Au-delà de quelques milliers d'hôtes, ce n'est plus une optimisation mais une nécessité.

Surveiller le serveur lui-même

Le template Zabbix server health est lié par défaut à l'hôte « Zabbix server ». Il suit le remplissage des caches, l'occupation de chaque type de processus et la file d'attente des valeurs. Deux signaux à surveiller :

• Un type de processus occupé à plus de 75 % : augmentez le paramètre correspondant dans zabbix_server.conf, par exemple StartPollers ou StartPreprocessors.
• Un cache rempli : augmentez CacheSize, HistoryCacheSize ou ValueCacheSize. Un ValueCacheSize trop petit force le serveur à relire la base à chaque évaluation de trigger.

Administration > Queue montre les items en retard. Une file qui grossit est le premier symptôme d'un serveur sous-dimensionné.

La haute disponibilité

Si le serveur Zabbix tombe, plus aucune alerte ne part, et personne ne le sait. Depuis la version 6.0, Zabbix intègre un mode cluster : plusieurs serveurs partagent la même base, un seul est actif, les autres prennent le relais en moins d'une minute.

Sur chaque nœud, deux lignes dans zabbix_server.conf :

HANodeName=zbx-node1
NodeAddress=10.0.0.11:10051

HANodeName=zbx-node2
NodeAddress=10.0.0.12:10051

Le frontend lit dans la base quel nœud est actif. Les agents et les proxies doivent connaître les deux adresses. Dans ServerActive, les nœuds d'un même cluster sont séparés par un point-virgule :

Server=10.0.0.11,10.0.0.12
ServerActive=10.0.0.11;10.0.0.12

Le cluster ne protège que le serveur. La base de données devient le point unique de défaillance : elle a besoin de sa propre réplication, avec Patroni pour PostgreSQL par exemple. Et la supervision du superviseur reste à prévoir : un simple check externe, comme Uptime Kuma sur une autre machine, qui vérifie que le frontend répond.

Sécuriser l'installation

Chiffrer les échanges avec les agents

Par défaut, agents et serveur communiquent en clair. Une clé partagée (PSK) chiffre les échanges en quelques lignes. Sur l'hôte supervisé :

openssl rand -hex 32 | tee /etc/zabbix/zabbix_agent2.psk
chown zabbix:zabbix /etc/zabbix/zabbix_agent2.psk
chmod 600 /etc/zabbix/zabbix_agent2.psk

TLSConnect=psk
TLSAccept=psk
TLSPSKIdentity=PSK-web-01
TLSPSKFile=/etc/zabbix/zabbix_agent2.psk

Dans l'onglet Encryption de l'hôte, cochez PSK pour les connexions entrantes et sortantes, et collez la même identité et la même clé. Une clé par hôte, pas une clé commune à tout le parc. Les certificats sont l'alternative pour les grands parcs déjà dotés d'une PKI.

Le frontend

• Changez le mot de passe d'Admin, ou mieux, désactivez ce compte après avoir créé des comptes nominatifs.
• Servez le frontend en HTTPS uniquement.
• Activez l'authentification multifacteur, nouvelle dans Zabbix 7.0 (TOTP ou Duo), au moins pour les comptes administrateurs.
• Branchez l'authentification sur votre annuaire LDAP ou votre SSO SAML si vous en avez un.
• Donnez à chaque équipe un rôle qui ne voit que ses groupes d'hôtes.

Le frontend Zabbix donne une carte complète de votre infrastructure, et ses scripts peuvent exécuter des commandes sur les hôtes. Il ne doit pas être exposé sur Internet sans VPN ou proxy d'authentification devant.

Sauvegarder

Toute la configuration de Zabbix vit dans la base : hôtes, templates, actions, utilisateurs. Sauvegarder la base, c'est sauvegarder Zabbix. Pour une base volumineuse, on peut exclure l'historique, qui se reconstitue, et ne garder que la configuration et les tendances :

pg_dump -U zabbix -Fc \
  --exclude-table-data='history*' \
  zabbix > zabbix-config-$(date +%F).dump

Ajoutez à la sauvegarde les fichiers de /etc/zabbix/, les scripts d'UserParameter et les scripts d'alerte. La stratégie de sauvegarde avec restic s'applique telle quelle à ces fichiers.

Les montées de version

Zabbix met lui-même à jour le schéma de la base au démarrage d'une nouvelle version. La procédure est simple, à condition de la préparer :

1. Lire les Upgrade notes de la version cible : paramètres supprimés, changements de comportement.
2. Sauvegarder la base.
3. Tester sur une copie de la base de production, pas sur une base vide : la migration d'une grosse base peut prendre des heures.
4. Arrêter le serveur et les proxies, mettre à jour les paquets, redémarrer, suivre le journal jusqu'à la fin de la migration.
5. Mettre à jour les proxies : en 7.0, un proxy d'une version majeure plus ancienne reste en compatibilité limitée.
6. Importer les nouvelles versions des templates officiels.

Pour la production, je recommande de passer de LTS en LTS. La 8.0 LTS est attendue pour la fin 2026 : laissez-lui quelques versions correctives avant de migrer. La 7.0 LTS est supportée jusqu'en juin 2027 pour les correctifs, juin 2029 pour les failles critiques. Rien ne presse.

La liste de contrôle de production

Zabbix demande un investissement au départ, mais il paie dans la durée : un seul outil pour les serveurs, le réseau, les bases et les sites, une seule logique d'alerte, et des années d'historique. La meilleure supervision n'est pas celle qui mesure le plus de choses. C'est celle dont chaque alerte est lue, comprise et suivie d'une action.