10 articles tagués avec « Observabilité »

Une application qui expose des métriques à Prometheus, écrit ses logs pour Loki et envoie des traces à un outil d'APM utilise souvent trois bibliothèques, trois formats et trois agents différents. Changer d'outil de traces oblige alors à réinstrumenter le code, et rien ne relie le log d'une erreur à la requête qui l'a produite. OpenTelemetry part de ce constat : il définit une seule manière de produire, de décrire et de transporter la télémétrie, indépendante de l'outil qui la stockera. Cet article présente ce que couvre le projet, les briques qui le composent et les deux notions qui rendent les données exploitables d'un outil à l'autre, la ressource et les conventions sémantiques.

En EKS Auto Mode, AWS gère les nœuds, le réseau des pods, le stockage et les load balancers. La supervision des applications reste en revanche à la charge du client : le modèle de responsabilité partagée d'Auto Mode le dit explicitement. Un cluster fraîchement créé n'envoie à CloudWatch aucune métrique de pod et aucune ligne de log applicatif. Un pod qui redémarre en boucle ou une API qui renvoie des erreurs 500 ne laissent alors de trace que dans kubectl, tant que les pods existent encore. Sur un cluster auto-hébergé, ce rôle revient à Prometheus et Loki. Sur AWS, le service natif est CloudWatch. Cet article décrit comment y raccorder un cluster EKS, et les réglages par défaut à corriger dès l'installation.

Promtail, l'agent qui pousse les logs vers Loki, est en fin de vie depuis le 2 mars 2026 : il ne reçoit plus de correctifs. Un cluster qui collecte ses logs avec lui doit changer d'agent, et la migration ne doit casser ni les dashboards ni les requêtes qui reposent sur ses labels. Le même cluster lance souvent un agent par signal : Promtail pour les logs, des exporters pour les métriques, un OpenTelemetry Collector dès que des traces apparaissent. Grafana Alloy, le remplaçant désigné de Promtail, est une distribution de l'OpenTelemetry Collector qui collecte métriques, logs, traces et profils dans un seul processus. Cet article décrit son modèle de configuration, la collecte des logs des pods et des événements Kubernetes, et ce qu'il faut reprendre de Promtail pour une bascule sans rupture.

Un serveur qui plante sans laisser de trace ne donne aucune piste de diagnostic. Dans le cas traité ici, un serveur domestique sous Ubuntu, sans écran ni clavier, s'est arrêté trois fois en quelques jours ; à chaque fois, le journal système s'interrompait net, sans message d'erreur, et la machine restait figée jusqu'à un appui sur le bouton d'alimentation. Trois problèmes se posent alors : capturer la cause du crash, faire redémarrer la machine sans intervention, et être prévenu qu'un redémarrage a eu lieu. Cet article décrit la chaîne qui répond aux trois, kdump, sysctl de panic, watchdog matériel et alerte Prometheus, puis la façon de la valider avant le prochain crash.

Un Grafana configuré à la main garde dans sa base un état que rien ne trace. Dans le cas traité ici, l'inventaire d'un Grafana en service depuis la création du cluster a relevé une datasource pointant vers un serveur MySQL décommissionné, une autre créée pour un essai et jamais utilisée, des dashboards modifiés au fil des besoins sans trace de qui avait changé quoi ni pourquoi, et un écran d'affichage dont les liens dépendaient de dashboards qu'une fausse manipulation pouvait casser. Surtout, l'ensemble vivait dans la base SQLite de Grafana, sur un unique volume persistant : sa perte effaçait des mois de travail, sans aucune copie. Les manifests du cluster étaient tous versionnés et relus ; Grafana faisait exception. Cet article décrit comment faire de Git la source de ses dashboards et datasources, et les pièges de la transition.

Sur un hôte Docker, l'essentiel des pannes se lit dans les métriques de la machine et des conteneurs : disque, mémoire, redémarrages. Sur un cluster Kubernetes, une part importante des incidents ne se voit qu'au niveau des objets de l'API : un Deployment dont le rollout ne termine pas, un pod bloqué en Pending faute de ressources, un CronJob de sauvegarde qui échoue chaque nuit, un volume répliqué qui a perdu une copie, un certificat du plan de contrôle qui approche de son expiration. Ces états ne produisent ni pic de CPU ni erreur applicative. Cet article fait suite à l'article Alertmanager et construit un socle d'alertes pour un cluster kubeadm déployé avec le chart prometheus-community/prometheus : sources de métriques, collecte, règles par domaine, pièges propres aux métriques d'état et routage.

Prometheus mesure ce que les services exposent d'eux-mêmes : consommation CPU, latence des requêtes reçues, erreurs comptées par l'application. Ces métriques internes ne disent rien d'un reverse proxy qui ne route plus, d'un certificat expiré ou d'un DNS qui ne résout plus : si aucune requête n'atteint l'application, aucun compteur d'erreurs n'augmente. Une supervision externe, dite boîte noire, interroge les services comme le ferait un client et constate directement leur disponibilité. Uptime Kuma remplit ce rôle mais se configure dans son interface web : les sondes vivent dans sa base de données, hors de tout dépôt, sans revue ni historique. Gatus déclare ces mêmes sondes dans un fichier YAML versionné. Cet article fait suite à l'article Alertmanager et décrit Gatus, son modèle de configuration, son déploiement sous Docker Compose et Kubernetes, et les pièges rencontrés en pratique.

Collecter des métriques ne suffit pas : un disque saturé ou un conteneur qui redémarre en boucle n'est découvert qu'au prochain coup d'œil sur un dashboard. Une chaîne d'alerting mal conçue produit cependant l'effet inverse : cinq messages pour un seul incident, des déclenchements sur des pics légitimes, un canal si bruyant qu'il finit ignoré. Cet article fait suite à l'introduction à Prometheus et décrit la chaîne complète : règles d'alerte, traitement par Alertmanager, conception de règles robustes et notifications push.

Sur une infrastructure de dizaines de conteneurs répartis sur plusieurs nœuds, retrouver les lignes de logs liées à un incident impose de les consulter machine par machine, et les logs d'un conteneur supprimé disparaissent avec lui. Un visualiseur en temps réel comme Dozzle affiche le flux docker logs dans un navigateur, mais il ne stocke rien : une fois le conteneur recréé, il n'y a plus rien à interroger, et rien à agréger ni sur quoi alerter. Centraliser les logs dans un moteur à indexation plein texte règle la dispersion, mais le coût de l'index, en disque comme en mémoire, augmente avec le volume ingéré. Loki, créé par Grafana Labs sur le modèle de Prometheus, fait un autre choix : il n'indexe que les métadonnées des logs, leurs labels, et parcourt le contenu au moment de la requête.

Détecter une dégradation (latence qui augmente, disque qui se remplit, taux d'erreur qui grimpe) avant qu'elle n'atteigne les utilisateurs suppose de mesurer en continu l'état de dizaines de services et de machines, puis d'interroger ces mesures dans le temps pour les comparer et les agréger. Prometheus, système de monitoring et d'alerting open source, est le standard de fait pour ces métriques dans l'écosystème Cloud Native. Conçu initialement chez SoundCloud en 2012, il est aujourd'hui un projet gradué de la Cloud Native Computing Foundation (CNCF). Cet article couvre son architecture, son installation, son modèle de données et les bases du langage de requête PromQL.