Supervision avec Zabbix

Les serveurs Linux ne sont qu'une partie du parc. Il y a les switches, les routeurs et les onduleurs, qui ne reçoivent pas d'agent. Il y a les sites et les API, qu'on veut voir depuis l'extérieur. Il y a les bases de données, et les sites distants qu'on ne veut pas relier directement au serveur central. Zabbix a une réponse pour chacun.

SNMP : superviser ce qui n'accepte pas d'agent

Presque tous les équipements réseau parlent SNMP. Zabbix les interroge directement, sans rien installer dessus.

Choisir la version

La communauté SNMPv2c circule en clair : quiconque écoute le réseau la lit. Sur un réseau d'administration séparé, c'est acceptable. Ailleurs, SNMPv3 en mode authPriv, avec SHA et AES.

Tester avant de configurer

Depuis le serveur Zabbix, vérifiez que l'équipement répond :

apt install -y snmp
snmpwalk -v2c -c ma-communaute 10.0.1.1 1.3.6.1.2.1.1
snmpwalk -v3 -l authPriv -u zabbix -a SHA -A 'mot-de-passe-auth' -x AES -X 'mot-de-passe-priv' 10.0.1.1 1.3.6.1.2.1.1

L'OID 1.3.6.1.2.1.1 est la branche « system » : nom, description, durée de fonctionnement. Si cette commande ne répond pas, Zabbix ne fera pas mieux. Vérifiez l'adresse autorisée dans la configuration SNMP de l'équipement et les pare-feu (UDP 161).

Déclarer l'équipement

Créez un hôte avec une interface SNMP, choisissez la version, et liez un template :

• Network Generic Device by SNMP pour un équipement quelconque : disponibilité, durée de fonctionnement, interfaces découvertes.
• Un template de constructeur quand il existe : Cisco IOS by SNMP, et des dizaines de modèles Juniper, HPE, MikroTik, Fortinet, Ubiquiti… Ils ajoutent CPU, mémoire, températures, ventilateurs, alimentations.

La communauté ou les identifiants SNMPv3 passent par des macros, comme {$SNMP_COMMUNITY}, définies au niveau de l'hôte ou d'un groupe. Ne les écrivez pas dans l'interface de chaque hôte.

La découverte des interfaces crée un item de trafic entrant, sortant et d'erreurs pour chaque port. Sur un switch de 48 ports, filtrez les interfaces inutiles, sinon la base se remplit de ports jamais branchés.

Les traps SNMP

Le SNMP classique est interrogé à intervalle régulier. Les traps fonctionnent à l'inverse : l'équipement envoie un message au moment où un événement se produit, une alimentation qui tombe par exemple. Leur réception demande un démon snmptrapd qui écrit dans un fichier lu par Zabbix. Le dépôt zabbix-docker fournit une image zabbix-snmptraps qui fait tout cela. Commencez par l'interrogation, et n'ajoutez les traps que pour les événements que l'interrogation rate.

Superviser les sites et les API

L'item HTTP agent

L'item de type HTTP agent envoie une requête HTTP depuis le serveur Zabbix, ou depuis un proxy, et récupère la réponse. Il gère les en-têtes, l'authentification, les méthodes POST, les codes de retour attendus. Combiné aux items dépendants du chapitre 4, il supervise n'importe quelle API qui renvoie du JSON.

Le jeton est dans une macro de type Secret text, masquée dans l'interface.

Les scénarios web

Un scénario web enchaîne plusieurs requêtes en gardant les cookies : page d'accueil, formulaire de connexion, page du compte. Chaque étape vérifie un code de retour et une chaîne attendue dans la page. Zabbix mesure le temps de réponse de chaque étape et la vitesse de téléchargement.

C'est le bon outil pour vérifier qu'un parcours complet fonctionne, pas seulement que la page d'accueil répond. Un site peut renvoyer 200 sur la page d'accueil avec une base de données en panne derrière.

Les certificats TLS

Le template Website certificate by Zabbix agent 2 lit le certificat d'un site et alerte avant son expiration. On le lie à un hôte, et on renseigne le domaine dans la macro {$CERT.WEBSITE.HOSTNAME}. Un certificat expiré un lundi matin est l'incident le plus évitable qui soit.

La supervision par navigateur

Zabbix 7.0 ajoute un type d'item Browser, encore expérimental, qui pilote un vrai navigateur via Selenium ou un WebDriver. Il exécute du JavaScript côté client, prend des captures d'écran et mesure les temps de chargement réels. Le template Website by Browser sert de point de départ. Pour une application monopage où le contenu n'existe qu'après exécution du JavaScript, c'est la seule façon de vérifier ce que voit l'utilisateur.

Les bases de données

L'agent 2 supervise PostgreSQL, MySQL, Redis ou MongoDB par des plugins, sans script. Pour PostgreSQL, on crée d'abord un utilisateur de supervision avec le rôle prévu pour cela :

CREATE USER zbx_monitor WITH PASSWORD 'mot-de-passe-fort';
GRANT pg_monitor TO zbx_monitor;

Le rôle pg_monitor donne accès aux statistiques sans droit de lecture sur les données. On lie ensuite le template PostgreSQL by Zabbix agent 2 à l'hôte, et on renseigne les macros {$PG.CONNSTRING.AGENT2}, {$PG.USER} et {$PG.PASSWORD}. Connexions, transactions, verrous, réplication, taille de chaque base découverte : tout remonte.

Pour Docker, le template Docker by Zabbix agent 2 découvre chaque conteneur et suit son état, son CPU et sa mémoire. L'agent lit le socket Docker, il faut donc l'autoriser :

usermod -aG docker zabbix
systemctl restart zabbix-agent2

Ce droit revient à un accès root sur la machine. Réservez-le aux hôtes où la supervision des conteneurs le justifie.

Les proxies

Un proxy Zabbix collecte les données à la place du serveur, les garde en mémoire tampon, puis les lui transmet. Il sert dans trois cas :

1. Un site distant : une agence, un datacenter secondaire, un client. Seul le proxy parle au serveur central, par une seule connexion sortante.
2. Un réseau isolé : une DMZ ou un réseau industriel où l'on ne veut pas ouvrir de flux vers chaque machine.
3. La montée en charge : les proxies absorbent la collecte, le serveur se concentre sur les triggers et les alertes.

Si le lien avec le serveur coupe, le proxy continue de collecter et renvoie tout au retour de la connexion. Aucune donnée n'est perdue.

Installer un proxy

Sur la machine du site distant, avec le même dépôt que pour le serveur :

apt install -y zabbix-proxy-sqlite3

SQLite suffit pour un proxy : la base ne stocke que la configuration reçue et les données en attente d'envoi.

ProxyMode=0
Server=zabbix.example.com
Hostname=proxy-agence-lyon
DBName=/var/lib/zabbix/zabbix_proxy.db

ProxyMode=0 est le mode actif : le proxy contacte le serveur, aucun port à ouvrir sur le site distant. Le Hostname doit correspondre exactement au nom déclaré dans l'interface.

mkdir -p /var/lib/zabbix && chown zabbix:zabbix /var/lib/zabbix
systemctl restart zabbix-proxy
systemctl enable zabbix-proxy

Dans Administration > Proxies, créez le proxy proxy-agence-lyon en mode actif. Sur chaque hôte du site, le champ Monitored by passe à ce proxy, et les agents du site ont Server et ServerActive pointés vers l'adresse du proxy, pas du serveur central.

Les groupes de proxies

Zabbix 7.0 introduit les groupes de proxies. Un hôte n'est plus attaché à un proxy, mais à un groupe. Zabbix répartit les hôtes entre les proxies du groupe et les redistribue si l'un d'eux tombe. Deux proxies dans un groupe, et un site distant n'a plus de point unique de défaillance. Pour des agents actifs, ServerActive liste alors tous les proxies du groupe.

SNMP, HTTP, plugins de l'agent 2 et proxies : avec ces outils, il reste peu de choses qu'on ne puisse pas superviser. Le dernier chapitre traite ce qu'on oublie jusqu'au jour où ça casse : tableaux de bord, automatisation par l'API, volumétrie de la base, haute disponibilité et sécurité.