Une alarme est un message à une personne, pas une ligne de log

Toute plateforme de supervision peut détecter un problème. La partie difficile, c'est le dernier kilomètre : mettre la bonne alarme devant une personne capable d'agir, en quelques secondes, sans enterrer cette personne sous des alarmes sans importance. Voici comment nous routons les alarmes dans Zabbix, et comment vous pouvez vérifier si votre propre chaîne fonctionne vraiment.

La détection est bon marché, l'attention coûte cher

La plupart des installations de supervision n'échouent pas parce qu'elles ratent un problème. Elles échouent parce que personne ne lit ce qu'elles produisent. Les alertes e-mail atterrissent dans un dossier qui se remplit plus vite que quiconque ne peut le vider. Les tableaux de bord passent au rouge et restent rouges pendant des semaines, jusqu'à ce que le rouge ne veuille plus rien dire. L'ingénieur qui finit par remarquer réagit en général à un client, pas au moniteur.

Ajouter des contrôles ne corrige pas cela. Ce qui le corrige, c'est une conception du routage qui traite l'attention d'un ingénieur comme la ressource la plus rare dont vous disposez, et ne la dépense que pour ce qui a besoin d'un humain maintenant.

Décidez de ce qui a le droit d'atteindre une personne

Commencez par la sévérité, et soyez strict. Chaque trigger Zabbix porte une sévérité, de information à disaster. Nous ne routons que les deux plus hautes, high et disaster, vers l'ingénieur d'astreinte, et chaque trigger à ce niveau doit passer un test : si cela se déclenche la nuit, quelqu'un doit-il agir avant le matin ? Si la réponse honnête est non, c'est un warning. Les warnings ont leur place sur les tableaux de bord et dans la revue quotidienne, pas dans la poche de quelqu'un.

Dans Zabbix, cette décision vit à deux endroits : les conditions de l'action (la sévérité du trigger est supérieure ou égale à High) et le filtre de sévérité sur le média de l'utilisateur. Réglez les deux, et faites-les concorder. Une action qui correspond à tout, combinée à un filtre de média qui en jette discrètement la moitié, est une configuration sur laquelle personne ne peut raisonner à trois heures du matin.

Ensuite, supprimez les échos. Quand un switch tombe, chaque hôte derrière lui devient injoignable aussi. Les dépendances de triggers disent à Zabbix que les alarmes des hôtes dépendent de l'alarme du switch, pour que l'ingénieur reçoive une alarme qui nomme la cause plutôt que quarante qui nomment les symptômes.

Livrez-la là où l'ingénieur se trouve déjà

Nos alarmes quittent Zabbix par un webhook vers un canal d'exploitation dédié dans Mattermost, le chat dans lequel nos ingénieurs travaillent toute la journée et qu'ils emportent sur leur téléphone la nuit. Pour les alarmes, le chat bat l'e-mail pour des raisons pratiques. C'est là que les gens regardent déjà. Il montre qui a vu le message. Et la conversation sur le correctif se tient dans le fil sous l'alarme, de sorte que le fil devient l'enregistrement de ce qui a été fait et quand.

Un bon message d'alarme porte assez pour agir sans ouvrir trois autres outils : l'hôte, le nom du trigger, la sévérité, la valeur courante, depuis combien de temps il est dans cet état, et un lien direct vers le graphique. Écrivez le modèle de message une fois, soigneusement, et chaque alarme que vous enverrez jamais en bénéficie.

Rendez la prise en charge visible

Une alarme que trois personnes ont vue et que personne n'a prise est aussi mauvaise qu'une alarme que personne n'a vue. L'acquittement ferme cette brèche. Quand l'ingénieur d'astreinte acquitte un problème dans Zabbix, avec une courte note, tous les autres voient qu'il est pris en charge, et la note est la première ligne de l'enregistrement. Si votre équipe a une seconde ligne, une étape d'escalade sur l'action (une notification supplémentaire quand un problème de haute sévérité reste non acquitté après un nombre de minutes défini) transforme « quelqu'un regardera probablement » en règle.

Le travail planifié mérite le traitement inverse : une équipe alertée par sa propre maintenance apprend à ignorer les alertes, et cette habitude ne reste pas confinée à la fenêtre de maintenance.

Prouvez que cela fonctionne

Prouvez la chaîne après chaque changement

Rien de tout cela ne compte tant que vous n'avez pas vu une vraie alarme parcourir tout le chemin. Après chaque changement sur la plateforme de supervision, nous déclenchons une alarme réelle et la chronométrons du trigger au message. Notre équipe réseau a décrit exactement comment exécuter ce test, et comment confirmer que chaque équipement est toujours entendu, dans Votre supervision est aussi un système : testez le chemin, pas le tableau de bord. Conservez les temps que vous relevez. Si le nombre grimpe lentement entre deux tests, quelque chose dans la chaîne ralentit, et vous l'avez appris par un test plutôt que par une panne.

Réglez par hôte, ne faites jamais taire à l'aveugle

Les templates partagés sont le berceau de la fatigue d'alerte. Un serveur de base de données tourne légitimement chaud, quelqu'un relève le seuil CPU dans le template pour le calmer, et tous les autres hôtes du parc viennent de perdre une alarme utile. Nous ne modifions jamais un template partagé pour régler une seule machine. Les seuils qui doivent différer sont définis comme des surcharges de macro au niveau de l'hôte, par exemple la valeur propre de {$CPU.UTIL.CRIT} sur cet hôte, pour que le réglage d'une machine ne change jamais les alarmes d'une autre.

La même règle s'applique à la désactivation des triggers. Un trigger qui se déclenche en permanence vous dit quelque chose : soit le seuil est faux pour cet hôte, soit l'hôte a un vrai problème. Le désactiver pour que le tableau passe au vert supprime le seul témoin. Corrigez le seuil sur cet hôte, ou corrigez l'hôte.

Surveillez le surveillant

Un moniteur à l'arrêt est pire que pas de moniteur, parce que vous faites confiance à son silence. Deux contrôles couvrent l'essentiel du risque. Dans Zabbix, un trigger nodata sur chaque agent, comme nodata(/<host>/agent.ping,5m)=1, attrape un hôte qui a cessé de remonter, ce qui est une panne différente et plus silencieuse qu'un hôte qui signale un problème. Hors de Zabbix, quelque chose d'indépendant doit remarquer quand la plateforme elle-même se tait : un battement de cœur que le serveur envoie à intervalle régulier vers un système séparé, qui lève sa propre alarme quand le battement cesse d'arriver.

Nous traitons aussi la plateforme de supervision comme de la production : rétention de base de données imposée, et audit depuis le matériel jusqu'au système d'exploitation, à la base de données, au démon et au chemin des alertes.

Un second avis avant que l'ingénieur ne la lise

Les règles filtrent d'abord le bruit connu, puis chaque alarme restante est analysée en temps réel par des modèles d'IA qui tournent sur nos propres GPU NVIDIA A100, dans notre propre datacenter. L'analyse examine l'alarme avec les événements récents, les hôtes liés et les motifs connus, et place à côté d'elle un court second avis : quoi d'autre a changé à proximité, et ce que ce motif a signifié par le passé. Elle ne décide rien et n'alerte personne. Elle épargne à l'ingénieur les premières minutes de recherche. Comme les modèles tournent sur notre propre matériel, les données de supervision ne quittent jamais notre réseau et ne sont jamais envoyées à un service d'IA public.

Si vous construisez quelque chose de semblable, gardez la même frontière. L'IA annote l'alarme. Une personne détient la décision.

Vérifiez votre propre chaîne

• Quelles sévérités atteignent une personne, et cette décision est-elle écrite quelque part ?
• Tout le monde peut-il voir qui a pris en charge une alarme ouverte ?
• À quand remonte la dernière fois où quelqu'un a déclenché une vraie alarme de test et l'a chronométrée de bout en bout ?
• Une panne de switch arrive-t-elle comme une alarme ou comme quarante ?
• Quelqu'un a-t-il réglé un seuil en modifiant un template partagé ?
• Combien de triggers sont désactivés en ce moment, et quelqu'un sait-il pourquoi ?
• Qu'est-ce qui vous dit que la plateforme de supervision elle-même s'est arrêtée ?

Si vous souhaitez un second regard sur la façon dont vos alarmes atteignent vos équipes, nous le ferons volontiers. Parler à un ingénieur

related line: Voir aussi : Supervision du parc et routage des alarmes · Télémétrie réseau et électrique, logs, détection DDoS

footer line: Publié le 22 octobre 2026. Toutes les notes de terrain