Le tracing zéro-code ne vaut que s'il ne casse rien. La gate wedge le prouve désormais : la CI maintient un workload volontairement fragile — limite CPU serrée, liveness probe agressive — Ready sous le capteur, et un nouveau mode opt-in permet aux flottes prudentes d'adopter les uprobes étiquette par étiquette.

Un nouveau module Alerting boucle la boucle sur la santé des services : quand un groupe, un service ou un niveau passe dans un mauvais état et y reste, avuru-obs déclenche un webhook — vers Slack, PagerDuty, Opsgenie, Alertmanager, ou tout point de terminaison qui en accepte un. C'est dérivé de la santé que vous calculez déjà : aucune sonde, aucun nouveau signal.

La carte des services affiche désormais la santé au niveau des connexions sur ses arêtes : le RTT TCP et les connexions échouées/réinitialisées par arête, mesurés dans le noyau par OBI — sans traces, sans SDK, sans modification applicative. Un lien lent ou qui refuse les connexions est maintenant visible sur la topologie que vous surveillez déjà.

Un nouveau tableau Santé des services consolide la santé RED de chaque service en un état de groupe — avec des niveaux de criticité et une règle : un service ne peut pas être au vert tant qu'une dépendance critique est au rouge. Le tout est dérivé des traces que vous envoyez déjà : aucun health check, aucune sonde, aucun stockage supplémentaire.

Un nouveau module Suivi des erreurs transforme les exceptions qui circulent déjà dans avuru-obs — événements d'exception de span, spans en erreur et logs ERROR/FATAL — en problèmes de premier plan : dédupliqués par empreinte, chacun avec une stack trace, une chronologie d'occurrences, un lien vers une trace représentative et un cycle de triage. Aucune modification de code requise.

Installer ne veut plus dire cloner le dépôt. Le chart Helm et chacune des images sont désormais publiés sur GHCR — signés avec cosign et compilés pour amd64 + arm64 — si bien qu'une seule commande démarre toute la stack.

avuru obs v0.1.0 est taguée : installez le chart Helm sur un cluster Kubernetes neuf et regardez une carte des services en direct apparaître en moins de cinq minutes, sans changement applicatif — une promesse garantie par la CI, pas une démo.

L'écran Profiling est disponible : des flame graphs CPU à l'échelle du cluster, échantillonnés par eBPF sans changement applicatif et stockés dans le même ClickHouse que vos traces, logs et métriques. Expérimental et opt-in en v0.1 (sensor.profiler.enabled=true) — le chargeur alpha upstream ne prend pas encore en charge tous les noyaux.

L'écran Nodes est disponible : CPU, mémoire et réseau par nœud, avec les pods les plus actifs en dessous — collectés par l'agent de nœud du sensor (kubeletstats), stockés dans le même ClickHouse que tout le reste.

L'écran Metrics est disponible : débit de requêtes, pourcentage d'erreurs et percentiles de latence dans le temps pour les services les plus actifs de la fenêtre — dérivés des mêmes spans que l'explorateur de traces, donc rien de plus à instrumenter ni à opérer.