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.

L'installation du chart Helm déploie désormais un sensor par nœud qui observe chaque service du cluster — traces eBPF, métriques RED et collecte des logs, sans SDK, sans sidecar, sans changement applicatif.

L'écran Services est disponible : chaque service vu dans la fenêtre sélectionnée — découvert zéro-code sur Kubernetes ou envoyant de l'OTLP directement — avec son débit, son pourcentage d'erreurs et ses percentiles de latence dans une table triable.

Notre étoile polaire — un cluster Kubernetes neuf affichant une carte des services en direct en moins de cinq minutes, zéro changement applicatif — est désormais une porte CI stricte, et la gateway est distribuée comme un collecteur minimal construit sur mesure.