Standardiser le système d’alertes et l’exploiter en IaC

(engineering.ab180.co)

7 points par dongho42 2 시간 전 | Aucun commentaire pour le moment. | Partager sur WhatsApp

Introduction

Avec la croissance du service, les signaux à surveiller en production se sont eux aussi multipliés. Dans cet article, nous présentons le processus par lequel nous avons géré les alertes comme du code et standardisé le flux de réponse via Slack et PagerDuty.

L’objectif initial était simple : rendre les alertes plus faciles à créer, plus lisibles à la réception, et clarifier qui devait les consulter. Ensuite, au fil de l’exploitation, nous avons également affiné les alertes groupées, les définitions répétitives, l’automatisation des réponses et la stabilité du système de monitoring.

Motivation

Il existe plusieurs façons d’améliorer la disponibilité d’un service et de réduire l’impact sur les utilisateurs.

Parmi elles, ce travail s’est concentré sur l’amélioration du système d’alertes.

Une alerte ressemble davantage à une interface d’exploitation qui relie la prévention des incidents à leur prise en charge. Si l’on détecte plus tôt les signaux de risque, on peut agir avant qu’ils ne se transforment en incident réel ; et une fois l’incident survenu, les personnes responsables peuvent en prendre connaissance plus rapidement et commencer à répondre.

La direction que nous voulions prendre à l’époque était elle aussi claire : mieux capter les signaux de risque, faire en sorte que les responsables les remarquent plus vite, enchaîner immédiatement sur l’investigation et la réponse, et réduire les flux de réponse répétitifs.

Nous n’avons pas commencé en mesurant quantitativement chaque aspect dès le départ, mais nous avions une conviction nette : une alerte ne devait pas être une simple notification, mais un système opérationnel permettant de prévenir les incidents et de déclencher la réponse.

Le rôle des alertes

Pour un service stable, il est important de prévenir les incidents, mais aussi de détecter rapidement les signes anormaux sur un service en production.

À cet égard, les alertes jouent deux rôles. Avant qu’un incident ne survienne, elles aident à identifier rapidement les signaux de risque et à agir en amont avant qu’ils ne deviennent un incident réel ; après l’incident, elles informent les responsables du problème et les orientent vers les actions suivantes nécessaires à la compréhension de la situation, comme le contexte, un runbook, un dashboard, les logs ou un silence.

Autrement dit, une alerte n’est pas simplement une notification indiquant "un problème est survenu", mais ressemble davantage à une interface d’exploitation reliant prévention et réponse aux incidents.

Ce qui manquait dans les alertes existantes

Les principales limites des alertes existantes tenaient à trois points : elles étaient difficiles à créer, difficiles à comprendre immédiatement à la réception, et il n’était pas clair qui devait les prendre en charge et les maintenir.

Difficulté à créer une alerte

À l’époque, la création et la transmission des alertes impliquaient de nombreux systèmes : Grafana, Slack, PagerDuty, CloudWatch, EventBridge, Lambda, etc. Les sources de données étaient elles aussi variées : NewRelic, VictoriaMetrics, Steampipe, OpenSearch, Druid, MySQL, etc.

Chaque alerte avait également son propre mode de fonctionnement. Certaines alertes étaient envoyées directement de Grafana vers Slack ; d’autres ajoutaient une Lambda derrière une CloudWatch Alarm ; d’autres encore interrogeaient l’état des ressources AWS via Steampipe pour prendre une décision ; et lorsque l’intégration PagerDuty était nécessaire, il fallait prévoir une configuration séparée.

Le problème était le manque de conventions à l’échelle de l’organisation. Il n’était pas suffisamment défini où gérer telle ou telle alerte, s’il fallait envoyer uniquement vers Slack ou aussi relier PagerDuty, quelles descriptions et quels liens inclure dans le message, ni où gérer l’équipe responsable et le chemin de diffusion.

Résultat : les alertes étaient créées au fil des besoins, mais avec le temps, leurs modes de création et de gestion sont devenus de plus en plus fragmentés.

Difficulté à lire les alertes

Le fait de créer une alerte ne garantissait pas que le message Slack réel soit toujours présenté sous une forme lisible. Le format et la qualité des informations variaient selon la personne et le système qui l’avaient créée ; certaines alertes avaient des titres longs et complexes, et des valeurs internes comme Value ou Labels étaient parfois exposées telles quelles.

Même lorsqu’il y avait des liens, il arrivait que l’on ne sache pas clairement quoi consulter en premier ; et même avec des boutons Dashboard ou Log, l’intégration réelle n’était parfois pas fonctionnelle. Le contexte de l’alerte était aussi souvent insuffisant, obligeant la personne responsable à rechercher de nouveau le service, le cluster, la ressource ou la plage temporelle concernés.

En situation d’incident, quelques minutes d’écart peuvent sembler considérables. Dès la réception d’une alerte, il fallait donc pouvoir comprendre immédiatement quel est le problème, à quel point il est important, quel service et quelle ressource sont concernés, quoi vérifier en premier, et quelle est l’action suivante.

Difficulté à gérer la responsabilité de réponse aux alertes

Lorsqu’une alerte se déclenchait, il arrivait aussi que l’on ne sache pas clairement qui devait la vérifier et y répondre. Si l’équipe ou la personne responsable n’apparaissait pas, la première personne à voir l’alerte devait d’abord se demander "est-ce à moi de regarder ça ?", "à qui dois-je poser la question ?", et en situation d’incident, même ce court moment de décision pouvait retarder la réponse.

Au-delà de la responsabilité de réponse après déclenchement, il était également important de savoir qui possède et maintient l’alerte elle-même. Il fallait faire apparaître ensemble à quel service et à quelle équipe l’alerte était liée, qui pouvait en modifier les conditions, comment revoir le message ou les seuils, et qui devait nettoyer les anciennes alertes.

En résumé, la situation que nous voulions améliorer était la suivante :

Les méthodes de création et de gestion des alertes étaient fragmentées
Même à la réception d’une alerte, il était difficile d’en saisir le sens d’un coup d’œil
Lorsqu’une alerte se déclenchait, il n’était pas clair qui devait la vérifier et y répondre
L’équipe qui devait posséder et maintenir l’alerte elle-même n’était pas claire

Ce que nous avons amélioré, et comment

L’orientation de l’amélioration tenait en trois points : standardiser la façon de créer les alertes, fournir dans les messages Slack les informations nécessaires selon une structure cohérente, et réorganiser la structure pour que les responsables et les chemins de diffusion apparaissent pour chaque alerte.

Standardiser la création et la gestion des alertes

Nous avons d’abord unifié la création et la gestion des alertes. L’évaluation et l’exécution des règles d’alerte ont été uniformisées avec Grafana ; l’intégration entre Grafana, Slack et PagerDuty a été abstraite dans un module Terraform ; et toutes les définitions d’alertes sont désormais gérées en IaC sous le répertoire alerts/ du dépôt interne alerts. La connexion aux canaux Slack, l’intégration PagerDuty, le format des messages et la création de boutons communs ont aussi été confiés au module commun.

Désormais, les auteurs d’alertes n’ont plus besoin de comprendre tout le pipeline d’alerte dans son ensemble : ils peuvent se concentrer davantage sur la condition à détecter, la criticité de l’alerte, qui doit la vérifier, et quelles informations sont nécessaires pour y répondre.

Dans le dépôt, nous avons aussi géré les modes de rédaction, la structure des répertoires, les champs requis et les conventions recommandées. En gérant les alertes comme du code, les revues et l’historique des changements sont également conservés au niveau des PR et des commits.

Structure des répertoires d’alertes

Toutes les alertes ont été organisées selon la structure {main-category}/{sub-category}/{severity}/{alert-name}.yml.

Par exemple :

infra/kubernetes/critical/pod-unhealthy.yml
data/airflow/warning/task-failed.yml
finops/aws/warning/cost-increase.yml

Grâce à cette structure, le simple emplacement du fichier permet de comprendre à quel domaine appartient l’alerte et avec quel niveau de gravité elle doit être traitée. Elle permet aussi de regrouper les alertes d’un domaine donné, de vérifier les alertes redondantes ou obsolètes, et de servir de base pour relier les canaux Slack, les services PagerDuty et les CODEOWNERS.

Format de définition des alertes

Chaque fichier d’alerte contient des informations comme datasource, query, threshold, condition et message.

Nous n’avons pas créé de nouveau DSL spécifique. Il s’agit plutôt d’une représentation en YAML du contenu sérialisé en JSON des alertes Grafana ; ainsi, la plupart des alertes définissables dans Grafana peuvent être transformées en IaC avec une structure similaire.

Récemment, nous utilisons aussi des LLM. Lorsqu’une personne décrit en langage naturel "dans quelles conditions et avec quel message elle veut recevoir une alerte", le LLM s’appuie sur les exemples et conventions existants pour produire une première version de la définition d’alerte au format YAML. Cela permet aux auteurs d’alertes de se concentrer davantage sur ce qu’il faut détecter et pourquoi c’est nécessaire, plutôt que sur un format de sérialisation complexe.

Rendre les messages d’alerte immédiatement compréhensibles et actionnables

Nous avons aussi considéré le message d’alerte comme une interface. En situation d’incident, on a rarement le temps d’interpréter lentement un message ; quelle que soit l’alerte reçue, il fallait donc pouvoir trouver le même type d’informations au même endroit.

J’ai donc uniformisé la structure des messages Slack. Le titre contient le nom de l’alerte, son état et sa gravité, tandis que le corps inclut une description immédiatement compréhensible, ainsi que le responsable, l’équipe, le service, la région, le nom de la ressource et les principaux labels. Les boutons ont aussi été séparés entre boutons communs et boutons optionnels : par défaut, IaC, PagerDuty, Silence sont proposés, et Runbook, Dashboard, Log ne sont affichés que lorsque c’est nécessaire.

Les boutons communs sont générés et reliés automatiquement par le système, et tous les changements d’état d’une alerte sont aussi conservés dans le thread Slack. L’objectif était de pouvoir suivre tout le déroulé au même endroit : qui a effectué l’Acknowledge, si le traitement s’est fait depuis Slack ou PagerDuty, quand l’alerte a été résolue, et quelles notes ont été ajoutées pendant l’intervention.

Au final, quelle que soit la personne qui crée une alerte, son apparence dans Slack est devenue similaire, et les membres de l’équipe peuvent déterminer plus rapidement où regarder.

Clarifier la responsabilité des alertes

Aussi important que de comprendre immédiatement une alerte, il fallait faire apparaître qui est responsable de la vérifier.

J’ai donc utilisé les tags et labels des ressources dans le flux de prise en charge. Plutôt que de désigner directement une équipe ou une personne responsable pour chaque alerte, des métadonnées comme le service, l’équipe, la ressource et l’environnement permettent de mentionner automatiquement, dans le message Slack, l’équipe et la personne responsables appropriées.

Les chemins de transmission ont été organisés selon la même logique. La classification de l’alerte et sa severity déterminent automatiquement le canal Slack, le PagerDuty Service et l’Escalation Policy associés. Les alertes de niveau Warning sont uniquement envoyées au canal Slack, tandis que les Critical Alerts, susceptibles d’avoir un impact utilisateur important ou d’annoncer une panne, créent aussi un PagerDuty Incident.

CODEOWNERS a également été utilisé. Les fichiers d’alertes sont séparés en répertoires selon la catégorie et le domaine de service, et les équipes responsables de chaque chemin sont indiquées dans CODEOWNERS, afin de rendre visible dans le dépôt quelle équipe possède quel périmètre d’alertes.

Ainsi, la responsabilité des alertes est gérée à deux niveaux. Quand une alerte se déclenche réellement, l’équipe et la personne responsables sont mentionnées à partir des tags et labels, et quand la définition d’une alerte est modifiée, la structure de répertoires et CODEOWNERS permettent de vérifier de quelle équipe relève le périmètre.

Le rôle du proxy d’alertes

Pour que cette structure fonctionne réellement, il fallait une couche intermédiaire capable d’interpréter et de transmettre les alertes. J’ai donc placé un proxy basé sur AWS Lambda entre Grafana, Slack et PagerDuty.

Grafana évalue les Alert rules et envoie un webhook. Le proxy reçoit ce webhook, interprète le contexte de l’alerte — category, severity, label, annotation, fingerprint, etc. — et décide vers quel canal Slack l’envoyer, quel PagerDuty Incident créer, qui mentionner, quels boutons ajouter, comment mettre à jour le thread Slack existant, et comment gérer le cycle de vie Ack/Resolve.

Autrement dit, si le module Terraform et la structure de répertoires ont standardisé « comment définir les alertes », le proxy joue le rôle de lien pour que ces définitions apparaissent et fonctionnent de manière cohérente dans le flux opérationnel réel.

Grâce au proxy, le format des messages Slack, les mentions des responsables, l’intégration PagerDuty, les mises à jour des threads Slack et les interactions Ack/Resolve ont pu être gérés de façon cohérente au même endroit. Cela a ensuite facilité l’extension vers des améliorations comme les grouped Alerts, les custom action buttons, l’intégration d’agents IA et un modèle d’alerte commun.

Ce qui restait insatisfaisant

Après la première amélioration, les définitions d’alertes étaient gérées en IaC, et les messages Slack comme les chemins de transmission fonctionnaient selon des règles cohérentes. Mais un système d’alertes n’est pas un outil qu’on construit une fois pour toutes. Après près d’un an d’exploitation, de nouveaux problèmes ont commencé à apparaître à mesure que les alertes se multipliaient : comment afficher plusieurs instances issues d’une même alerte, comment gérer les définitions d’alertes répétitives, ce qu’une personne peut réellement faire après avoir vu une alerte, ou encore comment assurer et vérifier la stabilité du système d’alertes lui-même.

Quand une même alerte se déclenche simultanément sur plusieurs cibles, la lecture devient difficile

Comme il était devenu plus facile de créer des alertes, leur nombre a naturellement augmenté. Ce qui était particulièrement gênant, c’était le cas où une même Alert rule se déclenchait simultanément sur plusieurs cibles.

Dans Grafana, même pour une même rule, si les valeurs de labels comme region, name, node, pod ou app diffèrent, chacune est considérée comme une Alert instance distincte. Par exemple, avec une alerte Pod unhealthy, si plusieurs pods deviennent unhealthy en même temps, une Alert instance est créée pour chaque pod.

Grafana disposait déjà d’une fonctionnalité d’Alert Grouping, mais regrouper simplement les alertes ne suffisait pas. L’important était de présenter l’état des alertes groupées de façon compréhensible pour l’opérateur : quelles cibles se trouvent dans le groupe, lesquelles sont encore en firing, lesquelles viennent d’être resolved, s’il y a de nouvelles cibles ajoutées, et si les changements d’état d’un même groupe s’enchaînent dans un flux unique.

Les définitions d’alertes répétitives se multiplient

À mesure que les définitions d’alertes se multipliaient, la méthode consistant à copier du YAML puis à le modifier légèrement a elle aussi montré ses limites. Des alertes comme SQS lag, CloudWatch error log, Pod OOM, ALB 5xx ou Lambda error/throttle revenaient régulièrement ; au début, il suffisait de copier un fichier existant puis de changer le nom, la query, le threshold et quelques labels.

Mais avec l’augmentation du nombre de fichiers, il devenait difficile de modifier les comportements communs, et des alertes pourtant conçues dans le même but finissaient par diverger légèrement dans leurs liens vers les dashboards, la composition des labels ou la façon d’exprimer les thresholds. Il fallait donc une structure permettant de réutiliser les motifs récurrents.

Même après avoir vu une alerte, il reste un écart avant l’action suivante

Ajouter aux messages Slack des boutons Runbook, Dashboard, IaC et PagerDuty était utile, mais dans la gestion réelle des incidents, de simples liens ne suffisaient souvent pas. Les runbooks étaient clairement efficaces, mais il n’était pas facile d’associer un bon runbook à chaque alerte et de le maintenir à jour en permanence.

Dans les interventions réelles, les mêmes tâches d’investigation se répètent : vérifier les logs Kubernetes, l’état des pods, l’historique des rollouts, les métriques SQS ou Lambda, ou encore les error logs. La plupart de ces actions se déroulaient en dehors du message Slack : la personne responsable devait lire les labels et les valeurs dans l’alerte, passer à un autre outil, y reporter ces valeurs, puis repartager les résultats dans le thread Slack.

En fin de compte, la première amélioration avait rendu les alertes plus lisibles, mais l’investigation et la réponse restaient encore largement en dehors du message d’alerte.

Le système de monitoring gagne des SPOF

En structurant le système d’alertes, les points susceptibles de devenir des SPOF se sont aussi multipliés. La définition et le déploiement des Alert rules étaient centralisés dans le dépôt alerts et Terraform, l’évaluation des Alert rules était assurée par Grafana, et les messages Slack, les PagerDuty Incidents ainsi que le cycle de vie Ack/Resolve étaient gérés par le proxy.

La clarification des rôles était une bonne évolution, mais le risque que l’ensemble du flux d’alertes soit affecté en cas de défaillance de l’un de ces points augmentait aussi. Plus difficile encore : ces défaillances peuvent ne pas être visibles de l’extérieur. Si le chemin chargé de signaler les anomalies des autres systèmes s’arrête silencieusement, une panne réelle peut se produire sans que personne ne s’en aperçoive.

Cela ramène finalement à la question : « qui surveille le système de monitoring ? »

Deuxième amélioration

La première amélioration avait posé l’ossature de base du système d’alertes, mais en facilitant la création et l’envoi d’alertes, les problèmes à surveiller en exploitation ont eux aussi changé.

La deuxième amélioration s’est concentrée sur quatre points : regrouper les changements d’état et les afficher d’un coup d’œil lorsque plusieurs cibles se déclenchent simultanément à partir d’une même Alert rule, permettre la réutilisation des définitions d’alertes récurrentes sous forme de motifs communs, compléter les runbooks en reliant les investigations répétitives et certaines actions limitées d’atténuation à des boutons Slack, et mesurer et vérifier la stabilité des chemins de définition, d’évaluation et de transmission des alertes susceptibles de devenir des SPOF.

Bien gérer les grouped Alerts

Nous avons d’abord amélioré la manière de représenter les alertes groupées. Lorsque plusieurs instances d’une même règle d’alerte se déclenchent en même temps, les envoyer chacune comme message indépendant rend le canal Slack confus ; à l’inverse, les fusionner en un seul groupe fait facilement perdre de vue les ressources réellement concernées.

L’idée clé était de regrouper sans perdre l’état à l’intérieur du groupe. Dans Slack, une alerte groupée est affichée sous la forme d’un message représentatif unique, tout en listant les cibles actuellement affectées. Lorsqu’une nouvelle cible est ajoutée ou qu’une cible existante est résolue, ce changement est laissé dans le même thread. Quand de nombreux changements d’état se produisent d’un coup, ils sont affichés par batch. Côté PagerDuty, nous avons aussi ajusté le comportement pour qu’il pointe vers le même problème que l’alerte groupée vue dans Slack.

Résultat : plusieurs alertes issues de la même cause peuvent désormais être suivies dans Slack comme un seul flux.

Réduire les définitions d’alertes répétitives

La méthode consistant à copier puis modifier légèrement augmente les coûts de maintenance et le risque d’erreurs à mesure que le nombre d’alertes croît. Pour réduire cela, nous avons ajouté global/templates et matrix.

global/templates permet de définir les structures d’alertes répétitives sous forme de templates communs, tandis que matrix permet de déployer une même alerte sur plusieurs combinaisons de régions, queues, datasources et services afin de générer plusieurs alertes.

Nous avons transformé en templates des patterns répétitifs comme le lag des queues SQS, les logs d’erreurs CloudWatch, les OOM de pods sur plusieurs clusters, les 5xx d’ALB, les erreurs/throttles Lambda, ou encore la mémoire/le CPU/la capacité maximale ECS, puis nous avons fait en sorte de ne renseigner dans la matrix que les valeurs variables, comme le nom de la queue, la région, le cluster, le seuil ou les variables de dashboard.

Ainsi, la structure commune des messages, les boutons, la gestion des liens vers les runbooks/dashboards et le traitement des datasources peuvent être modifiés à un seul endroit. Cela a aussi permis de réduire les incohérences et les coûts de maintenance qui apparaissent lorsque le nombre d’alertes augmente.

Commencer à intervenir directement depuis le message Slack

Ensuite, nous avons augmenté ce qu’il est possible de faire depuis le message Slack. Les liens vers les runbooks et les dashboards restent importants, mais nous voulions réduire, directement dans Slack, les consultations répétitives ou les opérations d’atténuation limitées qui reviennent toujours de manière similaire.

Nous avons donc ajouté des custom action buttons en plus des boutons existants. Lorsqu’une commande est définie dans message.actions dans le YAML de l’alerte, elle s’affiche comme bouton dans le message Slack. Quand le bouton est cliqué, le proxy exécute la commande via une invocation Lambda séparée, puis laisse dans le même thread Slack un commentaire indiquant qui a cliqué sur quel bouton et le résultat de l’exécution.

Ces boutons permettent de proposer des actions comme la consultation de logs, la vérification de l’état d’un rollout Kubernetes, un rollout restart dans des situations limitées, l’exécution d’une commande unique ou l’exécution séquentielle de plusieurs commandes.

Le point auquel nous avons le plus prêté attention était la sécurité. Si le nom d’un bouton se termine par !, une boîte de dialogue de confirmation Slack s’affiche. Les valeurs de labels comme ${labels.namespace} ou ${labels.pod} sont substituées dans la commande avec un shell quoting afin d’éviter les injections de commandes. Les opérations nécessitant des permissions supplémentaires assument un rôle IAM via actionRole. L’utilisation de rôles non autorisés est traitée en fail-closed, et les webhooks ainsi que les interactions Slack sont vérifiés respectivement par Bearer token, signature HMAC-SHA256 et protection contre le rejeu.

Intégration avec un agent IA

Nous voulions aussi réduire le processus de collecte des informations nécessaires après réception d’une alerte. Nous avons donc connecté abot, notre agent IA interne, au flux des alertes.

Lorsque le bouton abot du message Slack est cliqué, le proxy rassemble le nom de l’alerte, sa description, les labels, les valeurs, les liens IaC ainsi que le contexte supplémentaire saisi par l’utilisateur dans une modale, puis envoie une demande d’analyse. abot fonctionne avec l’identité OAuth de la personne qui a cliqué sur le bouton, de sorte que, même lorsqu’il consulte des informations dans Grafana, AWS, Kubernetes, etc., il ne récupère que ce que l’utilisateur peut réellement voir.

Le résultat de l’analyse est laissé en commentaire dans le même thread Slack. Nous y incluons les métriques et logs consultés, les hypothèses à suspecter en priorité, ainsi que les indices pouvant être repris dans une RCA. Cela a permis de réduire le temps passé à ouvrir plusieurs systèmes pour rassembler à nouveau les informations.

Surveiller le système de monitoring

Dans la deuxième amélioration, nous avons aussi inclus le processus même de définition, d’évaluation et de livraison des alertes dans le périmètre observé.

Nous avons d’abord collecté les métriques opérationnelles du proxy : temps jusqu’à l’ack, temps jusqu’à la résolution, nombre d’alertes actuellement ouvertes, durée de présence des alertes, nombre de redéclenchements d’une même alerte, etc. Nous avons aussi ajouté un watchdog capable de détecter quand une Lambda s’approche du timeout. Si le proxy échoue pendant le traitement, il conserve la stack trace complète ainsi que le payload d’événement d’origine.

Mais la méthode où le proxy envoie lui-même l’alerte a ses limites. Si le proxy tombe avant même de pouvoir envoyer cette notification, l’alerte qui aurait dû être envoyée peut être tout simplement perdue.

Nous avons donc placé, en dehors du proxy, des mécanismes de détection reposant sur des systèmes différents. Le premier est Grafana : les métriques envoyées par le proxy sont évaluées comme alertes dans le domaine monitoring afin de faire apparaître les anomalies. Toutefois, comme Grafana et VictoriaMetrics tournent sur le même EKS, une panne complète d’EKS ou de Grafana ne peut pas être détectée par ce biais.

Le second est un deadman switch. Quand Grafana fonctionne normalement, il émet /api/health comme heartbeat, et ce heartbeat est reçu par CloudWatch, indépendant d’EKS. Si le heartbeat disparaît ou est manquant, l’alarme CloudWatch considère qu’il s’agit d’un incident et notifie directement PagerDuty et Slack sans passer par Grafana ni par le proxy.

En d’autres termes, le système qui détecte et le système détecté reposent sur des infrastructures différentes. Grâce à cela, tant qu’EKS et CloudWatch ne tombent pas simultanément, nous pouvons savoir que le système de monitoring est indisponible.

Prochaines améliorations

La deuxième phase d’amélioration est terminée, mais il reste encore des points à améliorer.

Exploiter correctement les métriques opérationnelles collectées

Comme le proxy collecte les métriques opérationnelles des alertes, il est désormais possible de répondre avec des données à des questions comme : quelles alertes se déclenchent dans quels canaux et à quelle fréquence, certaines personnes ou équipes reçoivent-elles trop d’alertes, existe-t-il des alertes qui ne font que passer de firing à auto resolve sans aucune interaction ?

Mais pouvoir consulter les données et s’en servir pour affiner réellement les alertes sont deux choses distinctes. Nous n’avons pas encore vraiment lancé les améliorations visant à ajuster les seuils, regrouper les alertes similaires, supprimer les alertes inutiles, réduire les noisy alerts, ni à diminuer concrètement le temps de prise de connaissance et le temps de résolution.

Améliorer l’IaC des alertes

Aujourd’hui, les définitions d’alertes sont déployées via CI/CD depuis le dépôt alerts, mais elles dépendent encore de la ressource grafana_rule_group du provider Terraform Grafana. Le problème est que, même lorsqu’une seule règle change, la PR donne l’impression que tout le rule group a été modifié, ce qui rend le diff difficile à lire. De plus, comme interval_seconds est défini au niveau du rule group, il faut fragmenter les groupes pour donner des fréquences d’évaluation différentes à chaque alerte.

Grafana a récemment introduit une nouvelle API d’alerting qui traite les alert rules comme des ressources Kubernetes, et le provider Terraform a ajouté la ressource grafana_apps_rules_alertrule_v0alpha1. Comme elle est encore en alpha, nous repoussons son adoption pour l’instant, mais nous envisageons de migrer depuis grafana_rule_group lorsqu’elle deviendra stable.

Les bénéfices attendus sont clairs : définir séparément les rule groups et les rules, obtenir un diff propre qui ne montre que le changement concerné lorsqu’une seule rule est modifiée, ajuster finement la fréquence d’évaluation pour chaque rule, et utiliser plus efficacement les ressources de monitoring.

Conclusion

L’objectif initial était simple : rendre les alertes plus faciles à créer, immédiatement compréhensibles à la réception, et faire en sorte que la responsabilité soit claire.

Lors de la première amélioration, nous avons centralisé les définitions d’alertes en IaC, standardisé les messages Slack et les chemins de livraison, relié les mentions des responsables à CODEOWNERS, et structuré la gestion du lifecycle Slack/PagerDuty via le proxy.

Les problèmes apparus au fil de l’exploitation ont été traités lors d’une deuxième phase d’amélioration. Les alertes provenant d’une même rule ont été regroupées pour être affichées ensemble, les définitions répétitives ont été réduites grâce à des templates et à une matrix, il est devenu possible de lancer l’investigation et les mesures d’atténuation directement depuis les messages Slack, et un dispositif a aussi été mis en place pour détecter l’arrêt du système de monitoring lui-même.

Résultat : créer, envoyer et traiter les alertes est devenu plus simple qu’auparavant.

Cependant, pouvoir consulter les données et améliorer réellement l’exploitation sur la base de ces données sont deux choses différentes. Si, jusqu’ici, le travail a consisté à standardiser le système d’alertes et à le rendre mesurable, il reste désormais à observer ces chiffres pour les réduire et les affiner concrètement.

Certains éléments n’ont pas pu être inclus dans cet article faute de place. Si vous souhaitez en savoir plus, nous vous recommandons de lire également l’article original.