Sujet : observability
-
Le profilage continu en production : des profils par échantillonnage permanents et les questions auxquelles ils répondent
Le profilage continu recueille systématiquement des profils CPU et mémoire au fil du temps et les stocke sous forme de séries étiquetées, pour savoir quelle fonction a le plus consommé de CPU hier sur l'ensemble du parc ou ce qui a changé entre deux versions ; les profileurs par échantillonnage rendent cette collecte assez peu coûteuse pour rester active en permanence, et les points d'accès des environnements d'exécution, comme /debug/pprof/ de Go, ou les agents eBPF fournissent les profils.
-
Quelle stratégie d'échantillonnage des traces garde les défaillances rares visibles dans un service à faible trafic ?
Question ouverte : les recommandations d'échantillonnage sont rédigées pour des services produisant des milliers de traces par seconde, où un pour cent reste un échantillon représentatif ; pour un service recevant quelques requêtes par seconde, quelle combinaison d'échantillonnage en tête, d'échantillonnage en fin de trace, de taux par route et de rétention a permis de garder disponible l'unique trace en échec de la semaine, à un coût accepté par l'équipe ?
-
Déclencher les alertes d’astreinte sur les symptômes plutôt que sur les causes
Déclencher les alertes à partir de ce que vivent les utilisateurs (taux d’erreur, latence, disponibilité, fraîcheur des données), avec des seuils liés aux objectifs, les acheminer selon leur urgence et corriger ou supprimer toute alerte bruyante.
-
Quels signaux d'observabilité un service JVM ou .NET devrait-il émettre par défaut, et à quel coût ?
Question ouverte : les deux environnements d'exécution embarquent une télémétrie native (Flight Recorder et la journalisation du GC sur la JVM ; les compteurs EventPipe et dotnet-trace sur .NET) et disposent tous deux d'une auto-instrumentation OpenTelemetry, mais il existe peu de preuves partagées sur lesquels de ces signaux devraient être activés en permanence en production, ce qu'ils coûtent, et lesquels ont réellement raccourci des incidents.
-
Échantillonnage des journaux pour les événements à fort volume : conserver toutes les erreurs, échantillonner les lignes répétitives
L'échantillonnage rejette volontairement une fraction d'événements de journal similaires ; les formes utiles sont le un-sur-N, la rafale-puis-taux par période, les règles par niveau qui laissent intactes les alertes et les erreurs, et l'échantillonnage en pipeline indexé sur un identifiant de requête afin qu'une requête entière soit conservée ou rejetée en bloc, le taux appliqué étant inscrit dans les événements conservés.
-
Le traçage distribué en bref : spans, identifiants parents et W3C Trace Context
Une trace est un arbre de spans, chacun avec un identifiant de trace, son propre identifiant de span, un identifiant de span parent, des horodatages, des attributs et un statut ; l'en-tête W3C traceparent transporte l'identifiant de trace, l'identifiant parent et un indicateur sampled au-delà des frontières de processus, et un service qui se contente de retransmettre les deux en-têtes garde malgré tout les traces cohérentes.
-
Transfert et collecte distante avec journald : ForwardToSyslog, systemd-journal-upload/-remote et limitation de débit
journald peut transmettre ses entrées à un démon syslog local avec ForwardToSyslog=, ou les envoyer directement en HTTPS avec systemd-journal-upload vers un récepteur systemd-journal-remote, qui écrit ses propres fichiers de journal. Les deux voies sont soumises à la limitation de débit par service de journald : au-delà d'un seuil de rafale, les messages excédentaires sont abandonnés et seul leur nombre est consigné.
-
Concevoir un tableau de bord d'exploitation : une question par panneau, un écran par public
Partir des questions auxquelles une personne d'astreinte doit répondre, attribuer un panneau à chaque question, ordonner les panneaux du général au particulier, normaliser les unités et les axes, utiliser des variables de modèle plutôt que des copies, relier chaque alerte déclenchant un appel au tableau de bord dont elle a besoin, et conserver la définition du tableau de bord sous contrôle de version.
-
Windows Event Forwarding : abonnement initié par la source, wecutil et groupe EventLog Readers
Dans un abonnement WEF initié par la source, chaque ordinateur source récupère sa configuration auprès d'un collecteur via une stratégie de groupe et lui envoie les événements correspondants. wecutil gère l'abonnement sur le collecteur, et le transfert du journal Security exige d'ajouter le compte NETWORK SERVICE au groupe EventLog Readers sur chaque source.
-
Utiliser des identifiants de corrélation tout au long d'une tâche d'agent
Séparer l'identité de la tâche, les tentatives individuelles et le contexte de trace distribuée afin de pouvoir suivre les nouveaux essais sans journaliser de charges utiles sensibles.
-
Concevoir des alertes utiles : peu de notifications, chacune avec une prochaine étape
Une alerte qui réveille quelqu'un doit être urgente, guider vers une action et être perceptible par les utilisateurs ; tout le reste est un ticket. Alerter sur les symptômes ressentis à la frontière des utilisateurs, lier les seuils aux objectifs et au taux de consommation du budget d'erreur, poser un délai d'attente contre le flottement, lier le runbook, et chaque semaine, supprimer ou réajuster toute alerte restée sans action.
-
Hygiène des alertes pour la supervision d'hôtes : taux de variation plutôt que seuil fixe, unités en échec et fenêtres de durée
Une page d'astreinte doit signifier qu'un humain doit agir immédiatement ; un disque d'hôte proche de la saturation doit déclencher une page sur son taux de remplissage, pas sur un pourcentage fixe qu'une partition à croissance lente peut frôler pendant des mois, et un seuil franchi un instant ne doit pas déclencher de page du tout. Les documents SRE de Google sur la discipline de paging et l'alerting multifenêtre fournissent le raisonnement, appliqué ici aux signaux d'hôte de cette série.
-
Journaux d'exécution rejouables pour les agents : enregistrer chaque appel de modèle et d'outil
Une exécution d'agent ne peut être déboguée que si chaque requête de modèle, chaque réponse, chaque appel d'outil et chaque résultat d'outil est enregistré dans l'ordre, avec identifiants et paramètres ; les conventions sémantiques GenAI d'OpenTelemetry nomment ces champs, et un journal rejouable permet de reproduire un échec sans payer pour une nouvelle exécution.
-
Nommage des métriques et cardinalité des labels : les unités dans le nom, des valeurs bornées dans les labels
Les conventions de nommage de Prometheus placent dans le nom de la métrique un préfixe d'application, une unité de base et, pour les compteurs, un suffixe _total, et réservent les labels aux dimensions bornées ; chaque combinaison distincte de valeurs de labels constitue sa propre série temporelle, de sorte que des identifiants utilisateur, des URL brutes ou des messages d'erreur placés dans des labels multiplient le stockage jusqu'à dégrader le serveur.
-
Transférer syslog avec rsyslog en TCP via une file d'attente assistée par disque
Un fichier drop-in dans /etc/rsyslog.d/ permet de transférer tous les messages vers un collecteur central en TCP, tandis qu'une file d'attente d'action assistée par disque les met en tampon localement : une panne du collecteur ou une coupure réseau n'entraîne donc pas de perte de logs. rsyslogd -N1 valide la syntaxe avant l'application de la modification.
-
Corrélation et causalité dans les données d'incidents et d'exploitation
Un coefficient de corrélation mesure à quel point deux séries évoluent ensemble ; il ne dit rien sur laquelle entraîne l'autre, sur le fait qu'un troisième facteur tel que le trafic entraîne les deux, ou sur le fait que les données aient été sélectionnées par le résultat lui-même. Tracer d'abord un graphique, contrôler les causes communes évidentes, vérifier la chronologie, et confirmer par une intervention telle qu'un flag ou un canary avant d'agir.
-
La méthode RED pour les services pilotés par requêtes, avec des exemplaires reliant un bucket lent à une trace
Instrumenter chaque service traitant des requêtes de façon identique avec le taux, les erreurs et la durée (rate, errors, duration) : un compteur avec des étiquettes route, méthode et statut, et un histogramme de durée ; lorsqu'un traçage existe, attacher à l'histogramme des exemplaires (un ID de trace accompagné d'une valeur enregistrée) afin qu'un bucket lent sur le tableau de bord ouvre la trace qui y a atterri.
-
Rotation des journaux et limites de conservation
Les journaux doivent être bornés en taille et en âge à chaque niveau (application, runtime de conteneur, proxy, journal système), avec une durée de conservation choisie en fonction des besoins de débogage et des obligations légales plutôt que d'un principe de « tout conserver ».
-
Surveillance synthétique et contrôles de disponibilité : sonder de l'extérieur ce que voient les personnes utilisatrices
Un contrôle synthétique envoie une requête scriptée depuis l'extérieur du système à intervalle fixe et enregistre si la réponse était correcte et combien de temps elle a pris ; il s'agit d'une surveillance en boîte noire au sens SRE, qui détecte des défaillances que l'instrumentation interne ne peut pas voir (DNS, TLS, le répartiteur de charge, un domaine expiré), et doit être sondé depuis plus d'un endroit avant de déclencher une alerte pour quiconque.
-
Configurer le module de journalisation une seule fois, au point d'entrée
Les bibliothèques obtiennent des loggers et ne configurent jamais de gestionnaires ; l'application configure les gestionnaires, les niveaux et les formats une seule fois au démarrage, afin que la sortie soit contrôlée en un seul endroit et que les doublons soient évités.
Lisible par machine : JSON