Jusqu'ici, une gateway croyait sur parole le projet annoncé par l'émetteur. Vous pouvez maintenant émettre des clés d'API d'ingestion par projet et laisser la clé trancher — avec un réglage par défaut qui ne change rien tant que vous n'êtes pas prêt.

Les projets ne sont plus seulement un réglage de déploiement : les administrateurs peuvent les créer, renommer et supprimer directement dans Paramètres → Général, et le sélecteur se met à jour en conséquence — tandis que le projet intégré default et les projets définis par configuration restent en lecture seule.

Vous pouvez désormais explorer un avuru obs vivant sans rien installer : un clic sur « Essayer la démo » vous connecte en lecteur en lecture seule sur une application multi-services en fonctionnement, avec des données réelles dans chaque module.

avuru obs est désormais sécurisé par défaut : le hub exige une connexion, les utilisateurs portent des rôles fixes — Admin, Éditeur, Lecteur — accordés par projet, et le SSO d'entreprise fonctionne avec n'importe quel fournisseur d'identité OpenID Connect (Keycloak, Microsoft Entra ID, Okta, Google, Dex) — en open source, pas derrière une offre entreprise, et sans proxy d'authentification à déployer.

avuru obs est en AGPL-3.0, et toute l'histoire de sa licence tient désormais en un seul endroit — ce qu'elle vous demande (presque rien), pourquoi le projet l'a choisie, et comment il assure sa pérennité sans verrouiller de fonctionnalités derrière un palier payant.

avuru obs v0.2.0 est taguée. La v0.1 a prouvé le pari : une carte des services vivante en moins de cinq minutes, sans toucher aux applications. La v0.2 en fait une installation qu'une vraie équipe peut exploiter au quotidien : sécurisée par défaut, modulaire par conception, avec quatre nouveaux modules qui transforment les données déjà collectées en triage, en état de santé et en redevabilité.

Le nouveau module green transforme la carte pod→service que vous exploitez déjà en énergie (Wh) et carbone (gCO2e) par service — les chiffres que réclament l'ESRS E1 / la CSRD et les objectifs internes de durabilité, sans estimation sur tableur ni SaaS qui veut votre télémétrie. L'énergie est mesurée par CNCF Kepler (depuis les compteurs RAPL du CPU) ; avuru obs sait déjà quel pod est quel service, et attribue donc les joules aux services de votre carte. Auto-hébergé, sans changement applicatif, sans API externe.

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à.