Votre supervision est aussi un système : testez le chemin, pas le tableau de bord

Un écran de supervision silencieux a deux significations possibles : tout va bien, ou la supervision ne voit pas. Depuis l'écran seul, vous ne pouvez pas dire laquelle. Toute pile de supervision est une chaîne d'équipements, d'agents, de collecteurs, de règles et de canaux de notification, et chaque maillon peut casser sans lever la moindre alarme à son sujet. Cet article porte sur la preuve que la chaîne fonctionne, en routine, avant le jour où vous en aurez besoin.

Le silence n'est pas une preuve

La plupart des conceptions de supervision vérifient soigneusement les choses supervisées et présupposent la supervision elle-même. Un switch est configuré pour envoyer du syslog, donc ses journaux sont supposés arriver. Une règle d'alarme existe, donc une alerte est supposée atteindre quelqu'un. Une sauvegarde est planifiée, donc une copie de configuration est supposée exister. Aucune de ces suppositions n'est une mesure.

Les endroits où cette chaîne casse typiquement sont banals : une interface source de journalisation ou une instance de routage qui ne peut pas atteindre le collecteur, une règle de firewall entre les deux, une entrée de collecteur reconfigurée, une intégration de notification dont le jeton a expiré, un filtre de sévérité d'alarme qui exclut discrètement le type d'événement qui vous importe. Aucun de ces cas ne fait paraître un équipement malade depuis sa propre ligne de commande.

Vérification un : chaque équipement est-il réellement entendu ?

La vue de l'équipement (show logging liste un serveur et dit que c'est activé) est une affirmation. La vue du collecteur est la preuve. Retournez la question et demandez au collecteur : quand chaque équipement a-t-il envoyé quelque chose pour la dernière fois ?

Dans Graylog, une recherche groupée par source sur la dernière journée montre chaque équipement qui a parlé ; comparez cette liste à votre inventaire, et tout ce qui manque est votre trouvaille. Un simple test de bout en bout depuis l'équipement lui-même lève tout doute. Sur Cisco IOS et NX-OS, générez un message inoffensif et cherchez-le au collecteur dans les secondes qui suivent :

send log 6 "monitoring path test from this device"

Sur un hôte Linux :

logger -p user.notice "monitoring path test from $(hostname)"

Si le message n'apparaît pas, suivez le chemin dans l'ordre : adresse source et instance de routage utilisées pour la journalisation, joignabilité du collecteur depuis cette source, tout firewall entre les deux, puis l'entrée du collecteur et les règles de flux.

Faites la même comparaison pour les sauvegardes de configuration. Un équipement dont la dernière configuration sauvegardée a des semaines a un chemin de sauvegarde cassé, même si rien n'a jamais produit d'erreur.

Vérification deux : une alarme atteint-elle un humain ?

Déclenchez exprès une vraie alarme à travers toute la chaîne : un déclencheur de test, un élément factice qui franchit un seuil, ou une signature de journal que vous injectez. Confirmez que la notification arrive dans le canal que vos ingénieurs lisent réellement, avec la bonne sévérité, dans le délai attendu. Faites-le après tout changement de la plateforme de supervision elle-même, et selon un calendrier même quand rien n'a changé, parce que les jetons expirent et que les intégrations dérivent.

Dans Zabbix, un élément de test sur un hôte supervisé plus un déclencheur à la sévérité qui alerte suffisent. Poussez une valeur et regardez-la voyager :

zabbix_sender -z <zabbix-server> -s "<host>" -k monitoring.selftest -o 1

Puis confirmez trois choses : le problème est apparu, la notification a été délivrée, et la récupération a été délivrée quand vous avez réinitialisé la valeur.

Vérification trois : les sévérités sont-elles honnêtes ?

Passez en revue quels événements atteignent une personne et lesquels non. Une liste courte et explicite de signatures qui alertent toujours (voisin de routage hors service, lien hors service, BFD hors service, échecs crypto VPN, défauts d'alimentation, de ventilateur et de température, erreurs du réseau de stockage, tables d'états de firewall proches de leur limite) est plus facile à défendre qu'un seuil que quelqu'un a fixé il y a des années.

Un second avis aide ici. Les règles filtrent d'abord le bruit connu, puis tout ce qui reste est analysé en temps réel par des modèles d'IA sur nos propres GPU NVIDIA A100, à l'intérieur de notre datacenter. L'analyse lit une alarme avec son historique récent et les événements liés et offre aux ingénieurs un second avis sur ce qui se passe probablement. Les données d'alarme ne quittent jamais notre infrastructure, et c'est toujours l'ingénieur qui décide.

Vérification quatre : regardez depuis l'extérieur

Chaque vue depuis l'intérieur de votre réseau partage les angles morts de votre réseau. Une plateforme de mesure mondiale telle que RIPE Atlas, avec une ancre ou des sondes mesurant vers vous, montre comment de vrais endroits d'Internet vous atteignent : latence, pertes et changements de chemin. Quand un opérateur fait de la maintenance, la vue extérieure vous dit combien de temps la reconvergence a pris et si quelqu'un aurait pu s'en apercevoir, ce qu'aucun compteur interne ne peut faire.

Pour les circuits privés, une sonde dédiée à chaque extrémité mesurant latence, gigue et débit dans les deux sens chaque minute, stockée de façon permanente, transforme chaque conversation avec un opérateur d'opinion en données. Excluez le trafic de la sonde des propres statistiques du circuit pour que la preuve reste propre.

Vérification cinq : balayez quand rien ne va mal

Lancez des balayages de santé en lecture seule selon un calendrier, pas seulement après une alarme. L'environnement, l'état du routage et de l'overlay, la cohérence de la redondance entre pairs, les niveaux optiques et les compteurs d'erreurs d'interface changent lentement, et le changement lent est exactement ce que les alarmes à seuil manquent. Une optique qui dérive vers sa limite basse de lumière est un remplacement tranquille cette semaine ou une panne le mois prochain.

Votre liste d'autotest de la supervision

• Pouvez-vous lister chaque équipement qui n'a pas envoyé de journal au cours de la dernière journée ?
• Pouvez-vous lister chaque équipement dont la configuration sauvegardée est plus ancienne que son dernier changement ?
• Quand avez-vous déclenché pour la dernière fois une vraie alarme de bout en bout, et est-elle arrivée ?
• Les sévérités qui alertent une personne correspondent-elles à une liste écrite ?
• Voyez-vous votre réseau depuis l'extérieur, en continu ?
• Balayez-vous quand rien n'est connu pour aller mal ?

Nous supervisons notre réseau avec Zabbix, Graylog, Observium et une ancre RIPE Atlas, et nous lançons ces vérifications contre lui selon un calendrier. Si vous voulez un fournisseur qui répond par des mesures, ou de l'aide pour tester votre propre chaîne, parlez-nous.

Parler à un ingénieur

Related (rows[1])

Voir aussi : Supervision du réseau et preuves · Comment nous changeons les choses : la discipline de changement réseau · Notre propre réseau : deux ASN, de nombreux opérateurs, du peering