HL-PRC-034 — WatchTower — résolution du statut inconnu des hôtes Zabbix

Référence

HL-PRC-034

Version

1.0

Date d’édition

07/11/2026

Statut

Validée après vérification en production

Correction d’un statut « Inconnu » erroné pour les hôtes suivis par le connecteur Zabbix de WatchTower, en distinguant disponibilité d’interface, agent actif, contrôle ICMP et incidents ouverts.

1. Objet

Cette procédure décrit le diagnostic et la correction d’hôtes Zabbix affichés « Inconnu » dans WatchTower alors que la console Zabbix indique qu’ils sont joignables. Elle porte sur l’interprétation des champs renvoyés par l’API et sur la normalisation du statut dans WatchTower ; elle ne remplace pas le diagnostic d’un échec de transport, d’authentification ou d’autorisation du connecteur.

2. Périmètre et prérequis

• Accès en lecture à l’API Zabbix et à la page des hôtes dans WatchTower.
• Connaissance du type de contrôle de chaque hôte : interface passive (agent, SNMP, IPMI ou JMX), agent actif ou contrôle ICMP.
• Accès au dépôt WatchTower et à ses suites de tests pour modifier le collecteur ou la normalisation.

3. Cause du défaut

La collecte s’appuyait sur une valeur générale available qui ne suffisait pas à représenter les versions récentes de Zabbix ni les modes de supervision différents. La disponibilité d’une vérification passive est portée par les interfaces ; les agents actifs utilisent également active_available. Pour un hôte surveillé par ICMP, l’état d’interface peut rester à zéro sans renseigner le résultat du ping.

Le défaut de modèle était donc de traiter une valeur absente ou indéterminée comme une disponibilité inconnue, sans consulter les autres signaux disponibles, et de perdre le détail d’erreur d’interface utile au diagnostic.

4. Procédure de diagnostic et de correction

4.1. Vérifier les champs collectés

Dans la requête host.get, demander le statut de l’hôte, active_available et les champs de chaque interface utiles au diagnostic :

output: ["hostid", "host", "name", "status", "active_available"]
selectInterfaces: ["interfaceid", "ip", "dns", "type", "main", "available", "error"]

Les valeurs d’interface et d’agent actif suivent les états Zabbix usuels : 1 disponible, 2 indisponible, 0 inconnu ou non applicable au type de contrôle concerné.

4.2. Appliquer une priorité explicite aux signaux

1. Si une interface est disponible ou si active_available == 1, afficher l’hôte comme disponible.
2. À défaut, si l’interface principale est indisponible ou si active_available == 2, afficher l’hôte comme indisponible et conserver le texte error renvoyé par Zabbix.
3. Si ces valeurs restent à zéro, consulter la dernière valeur de l’item icmpping lorsqu’il existe : 1 indique une réponse au ping, 0 une absence de réponse.
4. Sans signal ICMP, utiliser l’état d’activation de l’hôte et la présence d’un problème critique ou désastre ouvert comme repli. Présenter ce résultat comme une inférence de supervision, pas comme une preuve de connectivité de l’agent.

Ne pas déclarer « indisponible » uniquement parce qu’une interface porte available == 0. Ne pas masquer le message d’erreur quand Zabbix en fournit un.

4.3. Restituer le diagnostic dans WatchTower

Transmettre le champ d’erreur dans le modèle d’hôte et l’afficher avec le badge d’indisponibilité, par exemple dans son infobulle. Les états « disponible », « indisponible » et « source non disponible » doivent rester distincts ; une erreur de collecte globale ne doit pas être projetée sur chaque hôte.

5. Vérifications

La recette en production confirme le résultat à la date indiquée ; elle ne garantit pas que le même nombre d’hôtes ou le même état soit valable ultérieurement.

6. Sécurité et limites

• Conserver le jeton Zabbix dans le coffre prévu ; ne jamais l’inscrire dans un exemple, une capture, une commande copiée ou un journal publié.
• Utiliser un compte de lecture limité aux données nécessaires. Ne pas désactiver la vérification TLS pour contourner un défaut de certificat.
• Les adresses, noms d’hôtes et identifiants d’infrastructure sont volontairement omis de cette publication.
• Une collecte réussie ne prouve pas que chaque agent est joignable : distinguer statut de l’interface Zabbix, disponibilité de l’agent actif et résultat ICMP.

7. Références et historique

• WatchTower : apps/api/watchtower_api/collecteurs/zabbix.py et apps/api/watchtower_api/zabbix/modeles.py.
• Tests : apps/api/tests/test_supervision_zabbix.py.
• Procédure complémentaire : HL-PRC-020 — raccordement des connecteurs de supervision à WatchTower.