Je commence cet article par une dédicace spéciale à Thomas Pointdessous et Yann Coleu. Merci pour la transmission de vos conseils avisés et de votre expertise indéniable du run !

Ça fait un moment que je pense à rédiger cet article. Ce sujet revient régulièrement dans mes expériences précédentes, et malgré tout, je n’ai pas trouvé de contenu que je juge satisfaisant pour parler de cette problématique.

On trouve facilement du contenu pour construire des alertes Prometheus, déclencher des webhooks, connecter des chats ou des SaaS pour faire du paging, mais j’ai l’impression que personne ne parle vraiment de ce qui constitue une alerte efficace ou de ce qui est une alerte de nuisance.

Ce que je veux dire par là : qu’est-ce qui justifie vraiment de réveiller quelqu’un à 5h du mat pour une intervention, et qu’est-ce qui mérite juste qu’on balance le téléphone d’astreinte direct dans les chiottes.

Aujourd’hui, on laisse de côté l’implémentation technique, les problématiques de PromQL et de configuration des alertes. On va s’occuper de l’humain !

La fatigue d’alerting, le premier facteur d’inefficacité

Un des premiers réflexes quand on construit un système d’alerte, c’est de fouiller dans la masse d’informations et de métriques à notre disposition. La promesse, c’est de pouvoir détecter chaque aspect de notre infrastructure, la moindre petite variation ou le moindre symptôme qui pourrait provoquer un problème.

Même si l’idée est louable au départ, si on ne réfléchit pas en amont à ce qui est réellement pertinent, on finit par provoquer une grappe d’alertes incessantes, et le canal d’alerte est irrémédiablement mis en sourdine ou ignoré. Il en résulte des situations un peu paradoxales, où les alertes pertinentes se retrouvent noyées dans une masse d’autres alertes, soit redondantes, soit complètement inutiles.

Tout ce temps investi à faire des alertes est donc jeté à la poubelle, parce que le channel / le téléphone sonne trop. C’est con, mais ça arrive très souvent.

Ne pas router les alertes vers des emails

Eh non, une adresse email n’est pas un canal efficace pour distribuer des alertes. On peut mettre en place des filtres, mais inévitablement, ça finira dans la corbeille dès que l’alerting envoie trop d’alertes, elles seront traitées comme des emails de liste de diffusion et ignorées.

Utilisez plutôt des canaux de messagerie instantanée, avec des groupes de personnes concernées. Si vous déclenchez des astreintes, configurez un logiciel de paging de manière efficace pour router uniquement les alertes qui nécessitent une action humaine immédiate.

Encore pire que de les envoyer par email : ne pas router les alertes du tout, et les laisser pourrir dans l’outil.
Une alerte qui s’affiche dans un dashboard mais que personne ne consulte, c’est comme un gamin dans un parc d’attractions : si personne n’est désigné responsable, tout le monde pense que quelqu’un d’autre le surveille.

Produire de la documentation / des directives actionnables

Les devs et la doc, on sait que c’est le grand amour… mais du côté run et admin sys, ce n’est pas tellement mieux :)

Une alerte efficace doit être documentée et indexée dans un outil externe à Prometheus (au hasard : un wiki Confluence ou GitLab). Cette documentation doit être consultable et éditable par l’ensemble des personnes responsables de la plateforme, et elle doit être maintenue à jour.

Il est de bon ton d’avoir une procédure d’intervention sommaire sur quoi faire en cas d’alerte. Mais il faut conserver un esprit critique, et ne pas la suivre aveuglément.

Par exemple, pour une alerte de disque plein, il peut être utile d’avoir une procédure listant des actions comme le nettoyage des caches, trouver les plus gros fichiers, le redimensionnement des disques et des partitions.

Mais attention : le redimensionnement ne doit pas être systématique. Il faut toujours évaluer le contexte avant d’agir.

Il faut toujours garder en tête qu’en situation d’astreinte, on peut avoir quelqu’un réveillé trois fois à 5h du mat, les yeux encore collés, qui ne sait même plus de quel côté tenir son clavier.

La procédure doit être claire, rapide à lire, et aider à aller à l’essentiel. Ce n’est pas le moment de faire de la pédagogie ou de l’archéologie documentaire.

Ne pas faire sonner pour des problèmes sporadiques ou auto-rémédiables

Il faut absolument éviter de faire sonner une alerte pour un problème qui se résout tout seul ou qui n’est pas stable dans le temps.
Rien de plus agaçant que d’être réveillé pour une alerte qui se résout d’elle-même avant même d’être devant l’ordi.

Exemples de mauvaises alertes :

• Un pod Kubernetes qui tombe, juste une fois
  • Kubernetes le remonte tout seul. Ça ne nécessite pas de réveiller quelqu’un pour ça.
• Une machine avec un pic de CPU à 80%
  • OK José, balek.

Exemples de bonnes alertes :

• Un pod en état CrashLoopBackOff
  • Il faut comprendre pourquoi le pod crash et intervenir manuellement pour le remédier.
• Une machine qui plafonne à 100% de CPU depuis plus d’une heure
  • Probablement une machine sous-dimensionnée.

Réévaluer les alertes au fur et à mesure de l’évolution de la plateforme

Tel un Pokémon, ton infrastructure évolue, et il est important de réévaluer de temps à autre tes alertes pour qu’elles restent adaptées aux changements.
Les alertes qui étaient pertinentes il y a six mois peuvent ne plus l’être aujourd’hui, surtout si ta plateforme a grandi ou que de nouveaux services ont été ajoutés.

Comme à la bourse, les performances passées ne présagent pas des performances futures. Il est essentiel d’ajuster régulièrement les seuils de déclenchement de tes alertes en fonction de l’évolution de ta plateforme.

Ne laisse pas tes alertes devenir obsolètes, comme un vieux Canarticho !

Alerter sur les problèmes et non sur les symptômes

De manière générale, les symptômes bas niveau peuvent être intéressants, mais ils ne doivent pas être routés vers le canal d’alerte principal.
Un canal secondaire, qui peut rester muet et être consulté de temps en temps, périodiquement ou lorsqu’un problème d’astreinte est déclenché.

Cela nécessite néanmoins une certaine discipline et organisation, sinon c’est encore un channel d’alerte jamais consulté.

Tester les alertes au moins une fois

Il est primordial de tester toutes les alertes au moins une fois, soit en provoquant volontairement un incident qui déclenche l’alerte, soit en simulant des conditions négatives.
La discipline nécessaire consiste à produire l’alerte, à documenter son fonctionnement, et à la tester avant de la mettre en production.

Par exemple :

Une alerte de disque plein à 90 % → On peut la tester avec un curseur de disque plein à 10 %

Une alerte de base de données down → On peut la tester en alertant sur une base de données up

Alerte négative ou curseur plus sensible !

Monitorer les entrypoints depuis l’extérieur de ton cluster

Utiliser un outil de monitoring secondaire pour tester les points d’accès publics et les pages critiques de l’application.
Le but, c’est de ne pas se retrouver complètement à poil dans ces cas :

• si le cluster fonctionne mais qu’il y a un problème au niveau du point d’accès public
• si le monitoring est complètement HS et ne route plus les alertes

Tester systématiquement les services et dépendances tierces, mettre en place un circuit breaker idéalement.

Par exemple, si ton infra dépend d’un backend ou d’une API externe, c’est une bonne idée de tester le point d’entrée de cette API.

Le circuit breaker permet de fonctionner avec une application en mode dégradé si cette API ne répond plus. Il faut que le front puisse gérer ce mode dégradé.

Les alertes incontournables

Monitorer les certificats SSL publics

• 30 jours avant l’expiration du certificat
• 24h avant l’expiration du certificat

Tips :

• Utiliser le certificate manager des cloud providers
• Utiliser Let’s Encrypt ou cert-manager dans Kubernetes

Pas de certificat ou certificat expiré = indisponibilité facilement évitable.

Monitorer l’augmentation soudaine des erreurs 50X / 40X

Cela traduit souvent des problèmes de backend : erreurs non catchées ou routes mal configurées.
Trop de 403 et 401 peuvent être des symptômes de tentatives d’intrusion.
Des 404 en cascade sur des routes inexistantes peuvent indiquer un bot qui tente d’accéder à des routes vulnérables connues.

Monitorer les services :

• 1 seul pod disponible sur 3 : le service va probablement lâcher sous peu → peut-être prévoir un scaling manuel ?
• Pods en état CrashLoopBackOff :
  • Base de données ou dépendances HS
  • Probe de liveness trop restrictive
  • Cluster sous pression, les pods laggent en remontant

Dans les compute nodes, monitorer les unités systemd en état failed.

Détecter les OOMKill, symptomatiques d’un dépassement de RAM ou d’une limite de RAM trop petite par rapport aux besoins des pods.

Alerter sur les manques d’inodes et sur la taille des disques.

Mettre en place des alertes prédictives sur 4 jours et des alertes sur 24h, afin d’avoir le temps de prévoir un redimensionnement de disque avant qu’une indisponibilité n’intervienne, et pouvoir le faire au moment le plus adapté.

Alerte sur la consommation CPU élevée pendant une longue période. Cela indique que la machine est sous pression depuis un moment et que ses ressources ne sont probablement pas adaptées à la charge.

Alerte sur la consommation de RAM > 90%. Cela présente un risque d’OOMKill imminent, ce qui pourrait entraîner l’arrêt brutal de certains processus ou services.

Monitorer les queues de messages : si les queues se remplissent sans se vider, ça traduit un problème sur les services consumers.

Alerter les mises en production de nouvelles versions d’applications.

Organiser le Run et la documentation associée à la plateforme

Produire une fiche avec les contacts d’urgence, leur disponibilité et moyens de contact.

Documenter systématiquement les incidents de run en produisant des documents de retours d’expérience, avec un template basique :
Titre de l’incident, contexte, description de l’incident, déroulé des événements, analyse de la root cause, action de remédiation.

Créer une fiche récapitulative avec les informations suivantes pour chaque personne clé :

• Nom du contact
• Rôle et responsabilités
• Disponibilité
• Moyens de contact
• Escalade et procédures à suivre en cas d’indisponibilité
• Accès technique admin à la ou les plateformes
• Transmission minimale d’information technique sur le fonctionnement de l’infra

Cette fiche doit être facilement accessible et régulièrement mise à jour pour garantir que les bonnes personnes peuvent être contactées rapidement en cas d’urgence.

Points importants à prendre en compte en astreinte

Outre les aspects légaux de l’astreinte détaillés ici.

Voici les points qui me semblent essentiels de prendre en compte pour avoir des astreintes avec le moins de problèmes possible :

• Avoir au moins 4 personnes en astreinte pour assurer une rotation suffisante. Une semaine d’astreinte une fois par mois, c’est déjà un gros poids.
• Organiser vos vacances et congés en tenant compte du planning de vos collègues.
• S’organiser à titre personnel pour être joignable et opérationnel pendant la semaine d’astreinte.
• On a le droit de faire ses courses et d’avoir des activités sociales, mais il faut être disponible et contactable en cas d’urgence, donc être dans un endroit qui capte le téléphone et la 4G au moins, avec votre ordinateur d’astreinte pas trop loin.
• Respecter les horaires de repos et exiger une rémunération suffisante de votre activité d’astreinte.
• Éviter la consommation d’alcool excessive pour préserver au maximum votre sommeil. Vous devez être en capacité de répondre aux incidents, et si les contraintes de l’astreinte le demandent, prendre votre voiture pour vous rendre sur les lieux.

Quand tous les collègues sont au bar et que l’astreinte se déclenche, vous avez tout le monde avec vous pour vous aider.

Mais à 5h du matin, une fois rentré chez vous, après trois pintes et sans personne autour : vous serez seul face à l’incident.

Le mot de la fin

Le run et les astreintes ne s’improvisent pas.

Vous avez la sérénité et la santé de vos collègues entre vos mains. À vous de vous organiser pour que les choses se passent le mieux possible.

J’ai conscience que cet article est moins fun que d’habitude, mais j’espère qu’il sera utile pour nombre d’entre vous et que c’est un bon retour à la communauté qui m’a tant apporté :)

N’hésitez pas à le partager et à me faire des retours sur ce sujet.