Des alertes qui sonnent pour rien : un socle d'observabilité pour une scale-up sans SRE

Dans une scale-up sans équipe SRE (Site Reliability Engineering, l'ingénierie de la fiabilité), la supervision peut grandir par couches : un chart Helm et ses règles par défaut, un seuil ajouté après chaque incident, un canal où tout arrive. Des alertes sonnent alors pour des nœuds chargés qui servent normalement, se répètent pendant une panne jusqu'à noyer la seule qui comptait, et un incident sérieux peut être signalé par un client avant de l'être par la supervision. Ce qui manque est une règle : ce qui mérite une alerte, qui la reçoit, ce qu'on attend de cette personne.

Ce guide pose un socle tenable sans équipe dédiée : alerter sur les symptômes, fixer quelques objectifs de niveau de service (SLO, Service Level Objectives), alerter sur la consommation de leur budget d'erreur, décider ce qui réveille, ce qui ouvre un ticket et ce qui reste un tableau de bord, puis choisir une télémétrie proportionnée.

Observabilité, supervision et bruit : pourquoi les alertes ne disent plus rien

Qu'est-ce que l'observabilité informatique, et en quoi diffère-t-elle de la supervision ? Le livre SRE de Google définit la supervision comme la collecte, le traitement, l'agrégation et l'affichage en temps réel de données quantitatives sur un système. OpenTelemetry définit l'observabilité comme la capacité à comprendre un système de l'extérieur, en lui posant des questions sans connaître son fonctionnement interne. En pratique, la supervision répond à des questions connues d'avance (le service répond-il ?) ; l'observabilité permet d'en poser de nouvelles pendant un incident inédit, parce que métriques, journaux et traces portent assez de contexte pour être croisés.

Aucune des deux ne produit de bonnes alertes par elle-même. Le livre SRE range les notifications destinées à un humain en trois familles : tickets, alertes par e-mail et pages (l'appel qui sollicite immédiatement la personne de garde). Il juge les alertes par e-mail de valeur très limitée, vite noyées dans le bruit, et leur préfère un tableau de bord des problèmes non critiques en cours.

Cinq mécanismes qui fabriquent du bruit

1. Des seuils posés sur des causes. CPU, mémoire ou redémarrage d'un pod décrivent une cause possible, pas un effet sur l'utilisateur.
2. Des doublons. Une seule condition anormale peut produire plusieurs alertes ; le livre SRE demande de les regrouper et compte une supervision mal configurée parmi les causes courantes de surcharge opérationnelle.
3. Des dérives permanentes. Selon la documentation d'Argo CD, une application peut rester OutOfSync juste après une synchronisation réussie, par exemple si un contrôleur ou un webhook de mutation modifie l'objet après son envoi ; une alerte sur ce statut ne s'éteint jamais et cesse d'être lue.
4. Des destinataires absents. Le cas extrême est silencieux : le chart Helm kube-prometheus-stack livre une configuration Alertmanager par défaut dont la route racine pointe vers un récepteur nommé null, seul récepteur défini, sans aucune intégration. Tant qu'elle n'est pas remplacée, les alertes s'évaluent et personne n'est notifié.
5. Des alertes sans action. Le livre SRE demande que chaque page appelle une action, et note qu'on ne réagit avec un sentiment d'urgence que quelques fois par jour avant la fatigue.

Le coût du bruit dépasse le sommeil perdu : selon le livre SRE, des alertes de faible priorité reçues toutes les heures, ou plus souvent, installent une fatigue qui peut faire traiter les alertes sérieuses avec moins d'attention que nécessaire.

Alerter sur les symptômes : signaux clés, SLI, SLO et budget d'erreur

Le livre SRE demande à la supervision de dire ce qui est cassé (le symptôme) et pourquoi (une cause, parfois intermédiaire). Des réponses en erreur servies aux utilisateurs sont un symptôme ; une base de données qui refuse les connexions peut en être la cause. L'alerte qui réveille part du symptôme ; la cause se cherche ensuite. La documentation de Prometheus recommande d'alerter sur la latence et le taux d'erreur le plus haut possible dans la pile, et de ne réveiller sur la latence qu'en un seul point de la pile.

SLI, SLO et SLA sans jargon

Le Workbook SRE, second ouvrage SRE de Google, raisonne sur des indicateurs de niveau de service (SLI, Service Level Indicators) exprimés comme le rapport entre le nombre de bons événements et le nombre total d'événements. Pour un service à requêtes : disponibilité (part des requêtes servies avec succès), latence (part des requêtes servies plus vite qu'un seuil) et, si le service se dégrade de façon contrôlée, qualité (part des réponses servies sans dégradation) ; fraîcheur, exactitude et couverture concernent plutôt les traitements de données. Dans ses exemples, les requêtes sont mesurées au répartiteur de charge, plus près de l'utilisateur que les journaux applicatifs ; sur Kubernetes, le contrôleur d'entrée peut jouer ce rôle, et une sonde externe couvre les pannes qui n'atteignent pas le cluster. Pour la latence, le livre SRE rappelle qu'une moyenne de 100 ms peut cacher 1 % de requêtes à 5 secondes.

Un objectif (SLO) fixe la valeur cible d'un SLI sur une période ; un accord de niveau de service (SLA, Service Level Agreement) est un contrat, explicite ou implicite, avec les utilisateurs, qui prévoit des conséquences selon que les objectifs qu'il contient sont atteints ou manqués. Ce socle ne traite que d'objectifs internes. Peu d'objectifs, pas d'absolu : le livre SRE juge irréaliste et non souhaitable d'exiger que les SLO soient tenus 100 % du temps. Le Workbook indique qu'une fenêtre glissante de quatre semaines s'est révélée un bon intervalle d'usage général ; son chapitre sur les alertes raisonne sur 30 jours.

Le budget d'erreur et sa politique

Le budget d'erreur vaut 1 moins l'objectif. Exemple du Workbook : 1 000 000 de requêtes sur quatre semaines avec un objectif de 99,9 % autorisent 1 000 erreurs. Exemple fictif, par le calcul : sur 30 jours, une panne totale épuise un budget de 99,9 % en environ 43 minutes.

Le budget n'a d'intérêt que s'il déclenche une décision écrite d'avance. L'exemple de politique publié par le Workbook suspend, après dépassement du budget sur quatre semaines, les changements et mises en production autres que les correctifs critiques ou de sécurité, jusqu'au retour dans l'objectif, et prévoit un chemin d'escalade en cas de désaccord. Signée par la technique et le produit, une telle politique transforme l'arbitrage entre vitesse et fiabilité en règle.

Attention au faible trafic : avec 10 requêtes par heure, un seul échec fait 10 % d'erreurs sur l'heure. Le Workbook propose un trafic synthétique, le regroupement de petits services sous un même objectif, ou des changements du service et de l'infrastructure (nouvelles tentatives côté client, chemins de repli côté serveur ou client) qui réduisent l'impact d'un échec isolé.

Alerter sur la vitesse de consommation du budget : fenêtres multiples et règle Prometheus

Le Workbook compare six manières d'alerter sur un SLO selon quatre critères : la précision (part des événements détectés qui étaient significatifs), le rappel (part des événements significatifs détectés), le temps de détection et le temps de réinitialisation (durée pendant laquelle l'alerte sonne encore après la résolution). Il déconseille d'ajouter une durée minimale aux conditions d'alerte fondées sur un SLO : des pics répétés d'erreurs peuvent consommer une part importante du budget sans jamais déclencher l'alerte.

Taux de consommation et seuils

Le taux de consommation (burn rate) mesure la vitesse à laquelle le service consomme son budget, relativement à l'objectif : à 1, le budget s'épuise exactement en fin de période ; pour 99,9 % sur 30 jours, c'est un taux d'erreur constant de 0,1 %. Le taux à retenir pour une alerte se déduit de la part de budget jugée significative : taux = part du budget × période / fenêtre. Le Workbook en donne un exemple : 5 % du budget de 30 jours consommés en une heure demandent un taux de 36. Pour réveiller quand 2 % du budget part en une heure : 0,02 × 720 h / 1 h = 14,4.

Chaque fenêtre longue est doublée d'une fenêtre courte, dont le Workbook recommande de fixer la durée au douzième de la fenêtre longue. Elle vérifie que le budget brûle encore au moment de notifier : moins de faux positifs, réinitialisation rapide. Points de départ du Workbook (2 % du budget en une heure et 5 % en six heures pour réveiller, 10 % en trois jours pour un ticket), avec les taux calculés :

Ces seuils supposent 30 jours (720 heures). Sur quatre semaines (672 heures), la première ligne devient 0,02 × 672 / 1 = 13,44 : recalculer, pas recopier.

Une règle Prometheus minimale

Exemple fictif : un service api exposé par un compteur http_requests_total avec le code HTTP dans l'étiquette code, objectif de 99,9 % sur 30 jours. Les noms de règles suivent la convention niveau:métrique:opérations de la documentation Prometheus, celle qu'emploie aussi le Workbook. Métrique, étiquettes et URL sont à adapter ; la règle n'a pas été exécutée sur une instance réelle pour cet article.

groups:
  - name: slo-api-enregistrements
    rules:
      - record: job:slo_errors_per_request:ratio_rate5m
        expr: sum by (job) (rate(http_requests_total{job="api",code=~"5.."}[5m])) / sum by (job) (rate(http_requests_total{job="api"}[5m]))
      - record: job:slo_errors_per_request:ratio_rate30m
        expr: sum by (job) (rate(http_requests_total{job="api",code=~"5.."}[30m])) / sum by (job) (rate(http_requests_total{job="api"}[30m]))
      - record: job:slo_errors_per_request:ratio_rate1h
        expr: sum by (job) (rate(http_requests_total{job="api",code=~"5.."}[1h])) / sum by (job) (rate(http_requests_total{job="api"}[1h]))
      - record: job:slo_errors_per_request:ratio_rate6h
        expr: sum by (job) (rate(http_requests_total{job="api",code=~"5.."}[6h])) / sum by (job) (rate(http_requests_total{job="api"}[6h]))
      - record: job:slo_errors_per_request:ratio_rate3d
        expr: sum by (job) (rate(http_requests_total{job="api",code=~"5.."}[3d])) / sum by (job) (rate(http_requests_total{job="api"}[3d]))

  - name: slo-api-alertes
    rules:
      - alert: ApiBudgetErreurConsommationRapide
        expr: |
          (
            job:slo_errors_per_request:ratio_rate1h{job="api"} > (14.4 * 0.001)
          and
            job:slo_errors_per_request:ratio_rate5m{job="api"} > (14.4 * 0.001)
          )
          or
          (
            job:slo_errors_per_request:ratio_rate6h{job="api"} > (6 * 0.001)
          and
            job:slo_errors_per_request:ratio_rate30m{job="api"} > (6 * 0.001)
          )
        labels:
          severity: page
          team: plateforme
        annotations:
          summary: "api : budget d'erreur consommé trop vite ({{ $value | humanizePercentage }} d'erreurs)"
          runbook_url: "https://runbooks.example.internal/api/budget-erreur"
      - alert: ApiBudgetErreurConsommationLente
        expr: |
          job:slo_errors_per_request:ratio_rate3d{job="api"} > 0.001
          and
          job:slo_errors_per_request:ratio_rate6h{job="api"} > 0.001
        labels:
          severity: ticket
          team: plateforme
        annotations:
          summary: "api : budget d'erreur en baisse continue"
          runbook_url: "https://runbooks.example.internal/api/budget-erreur"

Points de lecture :

• Rapport de sommes. Numérateur et dénominateur sont agrégés séparément puis divisés : la documentation Prometheus proscrit la moyenne de rapports.
• Deux fenêtres. L'alerte ne part que si les deux fenêtres dépassent le seuil : and ne garde que les séries de gauche qui ont un équivalent à droite avec exactement les mêmes étiquettes, ici job seul après agrégation.
• Pas de clause for. Elle ferait passer l'alerte par l'état « pending » pendant la durée indiquée avant l'état « firing » ; la fenêtre courte filtre déjà.
• Absence de trafic. Sans requête, le rapport vaut 0/0 : l'arithmétique de PromQL suit la norme IEEE 754 et donne NaN, et une comparaison fausse retire la série du résultat. L'alerte reste muette ; une sonde externe ou une alerte sur l'effondrement du trafic couvre ce cas.
• Latence. Avec un histogramme classique, la part de requêtes servies en moins de 300 ms s'écrit sum by (job) (rate(http_request_duration_seconds_bucket{le="0.3"}[5m])) / sum by (job) (rate(http_request_duration_seconds_count[5m])) ; une borne de seau doit exister exactement à 0,3, sinon aucun résultat n'est renvoyé. Avec un histogramme natif, histogram_fraction(0, 0.3, sum by (job) (rate(http_request_duration_seconds[5m]))) donne une estimation interpolée. Le taux d'erreur à alerter vaut 1 moins cette part.

La méthode ne dépend pas de l'outil : Datadog propose des alertes de burn rate à fenêtre longue et fenêtre courte, en recommandant au départ une fenêtre courte d'un douzième de la fenêtre longue, comme Google ; Grafana Alerting se déclare construit sur le modèle d'alerte de Prometheus.

Réveiller, ouvrir un ticket ou afficher : routage, propriétaires et runbooks

Trois destinations suffisent. Une page interrompt la personne de garde, pour ce qui touche les utilisateurs maintenant ou très bientôt et demande une action urgente. Un ticket entre dans la file de l'équipe propriétaire. Un tableau de bord sert au diagnostic et aux revues. Les questions du livre SRE (la règle détecte-t-elle une condition urgente, actionnable et visible des utilisateurs ; l'action peut-elle attendre le matin ; d'autres personnes sont-elles déjà appelées pour ce problème) se ramènent à l'arbre suivant.

Router avec Alertmanager

Les règles d'alerte de Prometheus disent ce qui est cassé maintenant ; sa documentation confie à Alertmanager le regroupement, la limitation des notifications, les silences et les dépendances entre alertes.

• Regroupement. Les alertes qui partagent les étiquettes de group_by partent en une notification. Par défaut : 30 secondes avant la première notification d'un groupe (group_wait), 5 minutes avant de notifier les changements d'un groupe déjà notifié (group_interval), 4 heures avant de répéter la dernière notification (repeat_interval). Le chart kube-prometheus-stack fixe ce dernier à 12 heures dans sa configuration par défaut.
• Inhibition. Si le cluster entier est injoignable, les notifications des alertes qui le concernent peuvent être coupées ; equal exige la même valeur d'étiquette, par exemple cluster, chez l'alerte source et l'alerte cible.
• Silences. Ils coupent temporairement les notifications des alertes désignées par des matchers ; un silence prolongé sans motif clair est une alerte supprimée qui ne dit pas son nom.
• Plages horaires. active_time_intervals et mute_time_intervals bornent une route à des jours et heures, dans un fuseau de la base IANA.

Exemple fictif de routage minimal :

route:
  receiver: tickets
  group_by: ['alertname', 'cluster', 'service']
  routes:
    - matchers: ['alertname = "Watchdog"']
      receiver: veille-externe
      repeat_interval: 5m
    - matchers: ['severity = "page"']
      receiver: garde
inhibit_rules:
  - source_matchers: ['alertname = "ClusterInjoignable"']
    target_matchers: ['severity =~ "page|ticket"']
    equal: ['cluster']
receivers:
  - name: garde
    webhook_configs:
      - url: "https://garde.example.internal/alertmanager"
  - name: tickets
    webhook_configs:
      - url: "https://tickets.example.internal/alertmanager"
  - name: veille-externe
    webhook_configs:
      - url: "https://veille.example.internal/ping"

Propriétaire, runbook et preuve que l'alerte arrive

Chaque règle porte une étiquette d'équipe et une annotation runbook_url (Prometheus prévoit les annotations pour les descriptions et les liens de runbook) ; un contrôle en intégration continue peut refuser une règle qui n'a pas les deux. Le runbook suit une structure fixe : symptôme et impact, tableaux de bord, diagnostic, contournement, retour arrière, critère de retour à la normale, escalade. Il doit pouvoir être exécuté par quelqu'un d'autre que son auteur.

La documentation de Prometheus demande de s'assurer que la supervision elle-même fonctionne, et juge un test de bout en bout de la chaîne d'alerte préférable, quand c'est possible, à des alertes séparées sur chaque composant. Le runbook Watchdog du projet prometheus-operator décrit une alerte qui sonne en permanence pour prouver que toute la chaîne fonctionne : si elle cesse d'arriver, un système externe doit alerter. Dans la configuration par défaut de kube-prometheus-stack, elle part elle aussi vers null : il faut la brancher sur un service externe. À chaque changement de rotation ou de configuration, une alerte de test doit atteindre le téléphone de la personne de garde, date et résultat notés.

La garde de l'équipe : le minimum à écrire

L'organisation de la garde (l'astreinte, au sens courant) appartient à l'équipe qui opère le service. Quatre points s'écrivent :

• La plage couverte, service par service. Hors plage, une page ne réveille personne : mieux vaut l'assumer et la traiter comme un ticket.
• La rotation : le livre SRE décrit des rotations avec une personne principale et une secondaire ; une passation à chaque relève reprend incidents ouverts, silences et changements prévus.
• L'escalade : qui appeler si personne ne répond, puis le fournisseur cloud, puis la direction pour une décision métier.
• Le volume : selon le livre SRE, traiter un incident de garde demande chez Google six heures en moyenne (analyse, remédiation, suivi), d'où au plus deux incidents par garde de douze heures. Le chiffre vaut pour Google ; le raisonnement tient partout : une rotation absorbe un nombre borné de pages.

La revue des alertes

Un rituel court, hebdomadaire au départ, reprend chaque page et chaque ticket issus d'une alerte : a-t-il mené à une action, était-elle urgente, une autre alerte disait-elle la même chose ? Chaque alerte en sort avec une décision : garder, rétrograder, corriger (seuil, fenêtre, regroupement, runbook) ou supprimer. La part des pages suivies d'une action donne une approximation de la précision au sens du Workbook (part des alertes qui correspondaient à un événement significatif). Selon le livre SRE, une configuration d'alerte sollicitée moins d'une fois par trimestre (seuil de certaines équipes SRE) est candidate à la suppression.

Pour que cette revue reste possible, chaque notification doit permettre de remonter à sa règle et à son propriétaire : nom de la règle, étiquettes d'équipe et de sévérité, lien du runbook, et emplacement de la règle dans le dépôt versionné.

Le socle de télémétrie minimal et ce qu'il coûte

L'ordre suit l'usage : d'abord les métriques des SLI et des quatre signaux, qui alimentent les alertes ; puis des journaux structurés portant l'identifiant de trace, pour passer de l'alerte à la requête fautive ; enfin des traces sur les parcours critiques, pour localiser l'étage qui échoue.

OpenTelemetry fournit la couche neutre : un cadre indépendant des éditeurs et des outils, qui produit et transporte traces, métriques et journaux sans être lui-même un système de stockage ni d'affichage. Son Collector reçoit, traite et exporte les données, se déploie en agent ou en passerelle, et évite d'exploiter un agent par outil. Une instrumentation sans modification du code existe pour .NET, Go, Java, JavaScript, PHP et Python ; sur Kubernetes, l'opérateur OpenTelemetry peut l'injecter, notamment pour .NET, Java, Node.js, Python et Go. L'intérêt est la réversibilité : Datadog, par exemple, documente la réception de données envoyées par un Collector OpenTelemetry.

Datadog, pile Grafana ou montage mixte

Le choix se fait sur l'exploitation, pas sur une liste de fonctions. Les questions suivantes départagent les options sans préjuger du résultat :

Volume, cardinalité et rétention

Trois variables font le coût. La cardinalité : pour Prometheus, chaque combinaison unique d'étiquettes crée une série, et sa documentation proscrit les étiquettes à forte cardinalité (identifiants d'utilisateur, adresses e-mail, ensembles de valeurs non bornés). Loki n'indexe pas le contenu des lignes mais les étiquettes des flux, renvoie les données de forte cardinalité vers des métadonnées structurées et déconseille les étiquettes par identifiant d'utilisateur ou de client. Le volume : niveaux de journalisation, doublons de collecte et traces conservées en totalité gonflent l'ingestion sans servir les alertes. La rétention : la durée de conservation de chaque signal se décide selon son usage (alerte, diagnostic, revue), et les règles d'enregistrement précalculent les rapports des SLI plutôt que de les recalculer à chaque évaluation sur les séries brutes. Pour inscrire ce poste dans un pilotage des coûts cloud, voir « FinOps, c'est quoi ? Définition 2026, méthode et par où commencer ».

Liste de départ

• Lister les parcours critiques et leur équipe propriétaire.
• Définir un SLI de disponibilité, et si utile de latence, mesuré à l'entrée du cluster.
• Fixer objectif et période ; faire signer la politique de budget d'erreur.
• Écrire les règles de burn rate ; recalculer les seuils hors 30 jours.
• Remplacer toute route vers null ; brancher Watchdog sur un service externe ; tester la chaîne jusqu'au téléphone.
• Exiger équipe, sévérité et runbook_url sur chaque règle.
• Rétrograder les alertes de cause qui réveillent ; corriger les dérives permanentes plutôt que les faire taire.
• Écrire plage couverte, rotation et escalade.
• Tenir la revue des alertes.
• Instrumenter avec OpenTelemetry, sans étiquette à forte cardinalité.

Pour cadrer ce socle sur une plateforme existante, la section sprint d'observabilité de la page Plateforme Kubernetes : livrer sans perdre le contrôle décrit ce que nous définissons : signaux utiles, seuils reliés à une action, procédures de premier niveau (runbooks) et tableau de lecture partagé. Si une partie de l'exploitation est ensuite confiée à un tiers, règles, runbooks et historique ont intérêt à rester dans les comptes de l'entreprise ; la page Infogérance cloud & maintien en conditions opérationnelles (MCO) décrit les dimensions que nous convenons avant toute responsabilité d'exploitation : périmètre couvert, fenêtre de couverture, canal d'entrée, chemin d'exception et réversibilité.

Sources officielles et limites de lecture

Les faits cités ont été vérifiés le 7 octobre 2026 : ouvrages SRE de Google, documentations de Prometheus, d'Alertmanager, d'Argo CD, d'OpenTelemetry, de Grafana, de Loki et de Datadog, valeurs par défaut du chart kube-prometheus-stack 91.8.1.

Limites. Les seuils de burn rate sont un point de départ pour 30 jours, à régler service par service. Règles et routages sont des exemples fictifs, non exécutés sur une instance réelle pour cet article. Les valeurs par défaut du chart changent selon les versions. Aucun chiffre sur le bruit des alertes, le temps de rétablissement ou le coût des outils n'est avancé ; le seul chiffre de garde est une observation de Google sur ses propres équipes. Ce guide ne traite ni le cadre du droit du travail applicable aux gardes, ni la détection d'intrusion, ni les journaux d'audit.

Sources

1. Monitoring Distributed Systems, Site Reliability Engineering (chapitre 6), Google, https://sre.google/sre-book/monitoring-distributed-systems/, consulté le 07/10/2026.
2. Service Level Objectives, Site Reliability Engineering (chapitre 4), Google, https://sre.google/sre-book/service-level-objectives/, consulté le 07/10/2026.
3. Embracing Risk, Site Reliability Engineering (chapitre 3), Google, https://sre.google/sre-book/embracing-risk/, consulté le 07/10/2026.
4. Being On-Call, Site Reliability Engineering (chapitre 11), Google, https://sre.google/sre-book/being-on-call/, consulté le 07/10/2026.
5. Alerting on SLOs, The Site Reliability Workbook (chapitre 5), Google, https://sre.google/workbook/alerting-on-slos/, consulté le 07/10/2026.
6. Implementing SLOs, The Site Reliability Workbook (chapitre 2), Google, https://sre.google/workbook/implementing-slos/, consulté le 07/10/2026.
7. Example Error Budget Policy, The Site Reliability Workbook (annexe B), Google, https://sre.google/workbook/error-budget-policy/, consulté le 07/10/2026.
8. Alerting rules, documentation Prometheus, https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/, consulté le 07/10/2026.
9. Alerting (bonnes pratiques), documentation Prometheus, https://prometheus.io/docs/practices/alerting/, consulté le 07/10/2026.
10. Recording rules (bonnes pratiques), documentation Prometheus, https://prometheus.io/docs/practices/rules/, consulté le 07/10/2026.
11. Histograms and summaries, documentation Prometheus, https://prometheus.io/docs/practices/histograms/, consulté le 07/10/2026.
12. Metric and label naming, documentation Prometheus, https://prometheus.io/docs/practices/naming/, consulté le 07/10/2026.
13. Operators, documentation Prometheus (langage PromQL), https://prometheus.io/docs/prometheus/latest/querying/operators/, consulté le 07/10/2026.
14. Alertmanager, documentation Prometheus, https://prometheus.io/docs/alerting/latest/alertmanager/, consulté le 07/10/2026.
15. Alertmanager configuration, documentation Prometheus, https://prometheus.io/docs/alerting/latest/configuration/, consulté le 07/10/2026.
16. Release 3.15.0, prometheus/prometheus, GitHub, https://github.com/prometheus/prometheus/releases/tag/v3.15.0, consulté le 07/10/2026.
17. Release 0.34.1, prometheus/alertmanager, GitHub, https://github.com/prometheus/alertmanager/releases/tag/v0.34.1, consulté le 07/10/2026.
18. kube-prometheus-stack 91.8.1, fichier values.yaml (section alertmanager.config), prometheus-community/helm-charts, GitHub, https://github.com/prometheus-community/helm-charts/blob/kube-prometheus-stack-91.8.1/charts/kube-prometheus-stack/values.yaml, consulté le 07/10/2026.
19. Watchdog, runbooks prometheus-operator, https://runbooks.prometheus-operator.dev/runbooks/general/watchdog/, consulté le 07/10/2026.
20. NodeFilesystemSpaceFillingUp, runbooks prometheus-operator, https://runbooks.prometheus-operator.dev/runbooks/node/nodefilesystemspacefillingup/, consulté le 07/10/2026.
21. KubeCPUOvercommit, runbooks prometheus-operator, https://runbooks.prometheus-operator.dev/runbooks/kubernetes/kubecpuovercommit/, consulté le 07/10/2026.
22. Diffing Customization, documentation Argo CD 3.5.3, argoproj/argo-cd, GitHub, https://github.com/argoproj/argo-cd/blob/v3.5.3/docs/user-guide/diffing.md, consulté le 07/10/2026.
23. What is OpenTelemetry?, OpenTelemetry, https://opentelemetry.io/docs/what-is-opentelemetry/, consulté le 07/10/2026.
24. Observability primer, OpenTelemetry, https://opentelemetry.io/docs/concepts/observability-primer/, consulté le 07/10/2026.
25. Collector, OpenTelemetry, https://opentelemetry.io/docs/collector/, consulté le 07/10/2026.
26. Zero-code Instrumentation, OpenTelemetry, https://opentelemetry.io/docs/zero-code/, consulté le 07/10/2026.
27. Injecting Auto-instrumentation, opérateur OpenTelemetry pour Kubernetes, https://opentelemetry.io/docs/platforms/kubernetes/operator/automatic/, consulté le 07/10/2026.
28. Grafana Alerting, fundamentals, Grafana Labs, https://grafana.com/docs/grafana/latest/alerting/fundamentals/, consulté le 07/10/2026.
29. Understand labels, documentation Grafana Loki, https://grafana.com/docs/loki/latest/get-started/labels/, consulté le 07/10/2026.
30. Burn Rate Alerts, documentation Datadog, https://docs.datadoghq.com/service_management/service_level_objectives/burn_rate/, consulté le 07/10/2026.
31. Install and Configure the OpenTelemetry Collector, documentation Datadog, https://docs.datadoghq.com/opentelemetry/setup/collector_exporter/, consulté le 07/10/2026.