Zabbix : 3 pièges rencontrés pendant mon lab

Pourquoi cet article

Mon lab Zabbix a fonctionné, mais pas du premier coup. Je note ici trois obstacles réels, parce que c'est en les résolvant que j'ai le plus appris.

Piège 1 : un prérequis en échec sur la locale

Pendant l'assistant d'installation web, le contrôle des prérequis affichait « Fail » pour la locale du système. Le serveur n'avait pas la locale en_US.UTF-8 de générée. J'ai activé cette ligne dans /etc/locale.gen, lancé locale-gen, puis redémarré Apache. Après rechargement de la page, tous les prérequis sont passés en OK. Ce que j'en retiens : un message d'échec dans un assistant pointe souvent vers un paramètre système simple, pas vers Zabbix lui-même.

Piège 2 : une page qui ne s'ouvre pas, à cause de https

Mon interface Zabbix ne répondait pas, alors que le service fonctionnait. J'avais tapé https dans l'adresse. L'interface de mon lab n'est servie qu'en http. Ce que j'en retiens : avant de chercher une panne, vérifier ce que l'on tape, puis ce que le service écoute vraiment.

Piège 3 : des problèmes affichés qui n'étaient pas des pannes

Dès l'ajout du Windows, Zabbix affichait déjà deux problèmes sur cette machine : les services AppXSvc et InventorySvc. Ce n'étaient pas de vraies pannes : le modèle surveille les services Windows à démarrage automatique, et ces deux-là ne tournent qu'à la demande. J'ai choisi de les laisser visibles, et de bien les distinguer de mon test d'alerte. Ce que j'en retiens : une supervision produit du bruit, et le travail consiste aussi à savoir trier ce qui compte.

Ce que je ferais ensuite

Régler ce bruit en ajustant les déclencheurs du modèle, et configurer une notification par e-mail pour que les vraies alertes ne restent pas seulement dans l'interface. Le déroulé complet, les commandes et les captures de ce lab sont dans le dépôt GitHub du projet.