Versions
avuru obs suit le versionnage sémantique (vX.Y.Z). Cette
page est la chronologie au niveau des versions ; pour les changements datés et
détaillés, voir le Changelog, et pour la suite la
Feuille de route.
:::note Pré-1.0 Jusqu'à la v1.0.0, les incréments mineurs peuvent inclure des changements cassants ; les incréments de correctif ne sont que des corrections. :::
Le tronc main. Voir la Feuille de route.
Les décisions typées, sur le papier d’abord. Une note de conception classe les endroits où un classifieur qui répond par une probabilité calibrée plutôt que par du texte aurait sa place — la sévérité d’un log qu’aucune règle n’a su lire, des erreurs qu’une empreinte a séparées, des alertes à trier — et ce que chacun coûterait à la promesse que rien ne quitte le cluster. Un banc d’essai hors ligne mesure le premier cas depuis un poste de travail, jamais depuis le hub. Aucune modification du produit n’est livrée.
Correctif : les écrans du maillage respectent le projet. Un compte limité à des projets ne voit plus, sur le Service Mesh, que les namespaces que ses projets atteignent ; une identité autorisée sur tous les projets voit toujours le cluster entier.
Voir les artefacts.
Les logs de plusieurs services en un seul flux. L’explorateur de logs
sélectionne services et workloads, lit indépendamment les sources application,
ztunnel, waypoint et autres, et les affiche fusionnées ou en panneaux par service —
depuis Signaux et depuis un nouvel onglet du Service Mesh. GET /api/v1/logs
compose les sujets avec un jeton de pagination signé ; GET /api/v1/logs/services
les suggère. Le thème sombre passe à l’ardoise avec un texte secondaire lisible.
Explorez l’intérieur du cluster. Cluster X-Ray ajoute une vue isométrique interactive des Nodes et Pods, des couches transparentes et un inspecteur. Les connexions utilisent les identités des spans ; les adresses non résolues restent sans localisation connue. Le moteur est chargé à la demande et l’inventaire reste accessible sans WebGL.
Explorer. La carte des services devient le point d’entrée de l’application, avec un inspecteur adjacent et des liens vers les signaux associés. Les statistiques d’erreurs et les sources de logs adaptées au service facilitent l’investigation.
La page d'une charge de travail. La v0.15 mettait sur une même ligne ce que
le maillage avait reçu comme consigne et ce qu'il avait fait ; cette version
répond aux questions que cette ligne laissait ouvertes. Une charge de travail
sur l'écran du maillage s'ouvre sur la fiche que le
cluster en tient lui-même — créée quand et par quel contrôleur, type, app et
version, chaque étiquette, les annotations du contrôleur, chaque pod avec le
déploiement auquel il appartient, un verdict de santé avec la raison qui l'a
décidé — et liste, à côté des politiques qui la sélectionnent, les routes et
règles qui l'atteignent par ses Services, chacune avec ses propres constats.
Puis un onglet Journaux lit les lignes de la charge elle-même avec les
lignes de ztunnel nommant ses pods et les lignes du waypoint nommant son
Service, en un seul flux sous un seul curseur, composé par le hub qui connaît
les pods — et le dit quand il n'a pu les reconnaître que par leur nom.
Aucune permission nouvelle et aucune collecte nouvelle : la fiche vient
d'objets que mesh-config observait déjà, les journaux de tables que le module
de journaux remplit déjà. Les installations sans le module de maillage ne sont
pas touchées.
Voir l'entrée de changelog et les notes de version.
Ce que le maillage a reçu comme consigne, et ce qu'il a fait. La liste des
espaces de noms disait STRICT, et un mode est une affirmation : une
politique stricte qui ne s'applique pas à une charge ressemble, vue de la seule
configuration, exactement à une politique appliquée. Cette version lit les deux
sources que le produit ne lisait pas — les proxys eux-mêmes, et les pods — et
les met sur une même ligne. La sonde de chaque nœud collecte les sidecars,
waypoints, passerelles et ztunnel de ce nœud, découverts par les annotations que
le maillage écrit déjà ; le module mesh-config lit les pods, toujours en
lecture seule, pour que chaque charge que le cluster exécute ait une ligne,
qu'elle ait ou non jamais émis un span. Un
onglet Sécurité tire une posture par
charge — strict et tout en TLS mutuel ; déclaré strict, observé en clair, qui
est un constat ; prêt à être resserré ; appelants en clair, nommés — et la
carte des services marque chaque arête mesurée par
un proxy. Un onglet Charges de travail liste l'inscription telle que les
pods la rapportent, six vérifications de configuration deviennent dix-sept, la
page d'un proxy explique ses échecs par indicateur de réponse et par version de
destination, et le graphe du maillage dessine chaque rôle avec sa propre forme.
La collecte du plan de données est activée par défaut sous le module de
maillage et démarre à la mise à jour ; mesh.dataPlane.enabled=false
conserve l'écran sans elle. Les installations sans module de maillage ne sont
pas touchées.
Voir l'entrée du changelog et les notes de version.
Le parc qu'un agent peut atteindre. La v0.12 affirmait qu'un agent pouvait
lire le parc, et c'était vrai — au moyen d'un jeton qu'une personne devait créer
et coller à la main, depuis un serveur que rien n'acheminait, et en décrivant un
cluster maillé autrement que les écrans ne le décrivent. Cette version referme
chacun de ces écarts. Le serveur MCP parle OAuth 2.1 :
un assistant hébergé s'authentifie comme tous les autres clients, sur un écran
de consentement qui dit ce qui quitte votre installation et se révoque depuis
Réglages → Accès ; les jetons sont opaques et liés à /mcp, donc refusés sur le
reste de l'API. service_context rapporte la dépendance située derrière un
proxy de maillage plutôt que le proxy, par le même code que la
carte des services, et le temps propre par service
n'est calculé qu'une fois, pour un agent comme pour la vue Chemin des traces —
ce qui a révélé que l'outil présentait comme sain un service renvoyant des 5xx.
L'écran Maillage est devenu une console : chaque proxy
gagne un rôle et un espace de noms, de vrais octets et la santé des liens à côté
de ses appels, et une page à lui montrant ce qu'il transporte. Un module
mesh-config, accordé séparément et en lecture seule, lit les objets Istio et
Gateway API de votre cluster, liste les espaces de noms inscrits et silencieux,
et exécute six vérifications visant les pannes qui n'émettent aucune télémétrie.
Trois réparations : /mcp est désormais joignable sur une installation Helm, un
service maillé n'affiche plus son proxy comme appelant dans le schéma de
voisinage, et les images de publication sont compilées de façon croisée plutôt
qu'émulées — la construction arm64 d'une heure qui séparait un tag d'une version
publiée a disparu.
Voir l'entrée du changelog et les notes de version.
Les dépendances, enfin visibles. La page d'un service savait nommer ce qui
l'appelle et ce qu'il appelle ; elle n'en montrait pas la forme. L'onglet Vue
d'ensemble s'ouvre désormais sur un
schéma de voisinage — les appelants à gauche,
le service au milieu, ses dépendances à droite, chaque flèche portant le débit et
le p95 côté appelant de ce chemin. Cela ne coûte aucune requête supplémentaire,
puisque la page lisait déjà ces arêtes pour remplir deux tableaux, et n'affirme
rien que les tableaux refusaient d'affirmer : un saut reconstitué à travers un
proxy de maillage indique via <proxy>, une arête que personne n'a chronométrée
ne porte aucune latence plutôt qu'un 0ms, et un pair qui n'a jamais émis de
span est dessiné en contour plutôt qu'en plein. Le lien vers la carte, qui
laissait un service sur un graphe vide, arrive maintenant sur son voisinage à un
saut.
Cette version achève également le travail de la v0.12 sur les images. L'agent de
nœud reçoit sa propre distribution de collecteur : il lui faut des récepteurs
que la distribution minimale ne porte pas, et la CVE-2026-56854 n'est corrigée
dans aucune version du collecteur — aucune montée de version n'aurait pu la
fermer. Chaque image tirée par défaut par le chart est désormais exempte de
vulnérabilité critique ou haute corrigeable, si bien qu'un registre appliquant
une policy « blocage sur Critical » n'a plus rien à excepter : ce qui compte,
car un tel registre cesse de servir une image signalée, et cela se manifeste par
un déploiement qui expire plutôt que par un rapport de scan.
Voir l'entrée du changelog et les notes de version.
La dépense sur laquelle vous pouvez agir — et un parc qu'un agent peut lire. La dépense IA cesse d'être un chiffre sur un écran : des budgets mensuels, en tokens ou en monnaie, se déclenchent via les canaux d'alerting que vous avez déjà, et les prix des modèles comme les tarifs de calcul tiennent désormais dans une seule grille, avec une seule devise, éditable dans les Paramètres et appliquée sans redéploiement. L'évaluateur de budgets et les écrans lisent le même résolveur : un budget ne peut donc jamais être mesuré contre un prix différent de celui qui est affiché.
Le module IA cesse aussi de compter les exécutions d'outils comme des appels de modèles — un défaut qui gonflait le nombre d'appels, mêlait une requête de base de données à la latence des complétions et remplissait le seau « sans usage » de spans qui n'avaient jamais appelé un modèle. Les outils obtiennent leur propre table, et un tour d'agent est dessiné comme le graphe qu'il est.
Nouveauté de cette version, le serveur MCP : six outils en lecture seule sur les traces, les logs, les issues et la santé que vous stockez déjà, pour qu'un agent enquête directement sur un incident. Aucune collecte ni conteneur supplémentaire — un seul handler sur le hub, authentifié par des jetons d'API personnels — et il reste éteint tant que vous ne l'allumez pas, parce que ce qu'un agent lit sort de votre cluster.
Les deux images de collecteur qu'une installation exécute passent également sous leurs avis de sécurité : la distro de la passerelle épingle ses planchers de dépendances, et l'agent de nœud rejoint la ligne du collecteur qui scanne le plus proprement.
Voir l'entrée de changelog et les notes de version.
Ce qui était déjà dans vos traces. Aucune nouvelle collecte : chaque fonctionnalité lit des spans qu'avuru obs stocke depuis vos cinq premières minutes, donc une mise à jour vous montre votre historique et pas seulement ce qui arrivera ensuite. L'observabilité IA rapporte les appels de modèles que vos applications envoyaient déjà — par modèle et par service appelant, avec les tokens, la latence, les échecs et les troncatures, et un coût si vous déclarez vos tarifs. La même version prend position sur le contenu des messages : les prompts et les complétions sont désormais supprimés à la passerelle par défaut, parce qu'ils étaient conservés avec votre rétention habituelle et montrés à tout Viewer, sans que personne ne l'ait jamais décidé.
Les traces gagnent une Répartition — le trafic en treemap et en anneau, groupé par n'importe quel attribut porté par un span, pondéré par nombre ou par temps total, avec une queue de distribution qui est une vraie catégorie pour que les parts composent le tout. Il y a une page par service, une vue Chemin qui dessine la forme d'une requête au niveau service, et Refusé : le 4xx côté serveur comme issue à part entière, délibérément tenu hors du taux d'erreur.
Voir l'entrée de changelog et les notes de version.
Ce que ça coûte. Un cluster est dimensionné par ce que ses charges de travail réservent, pas par ce qu'elles consomment — et seule la seconde moitié était visible. Coûts & gaspillage ajoute la première : le CPU et la mémoire réservés par chaque charge face à ce qu'elle a réellement tiré, classés par l'écart, avec les charges ne déclarant aucune requête signalées comme un état à part entière et l'allocation d'un nœud affichée à côté de son usage. L'inactif se mesure face au pic, jamais à la moyenne, et les tarifs sont les vôtres à déclarer — aucune API de tarification, et rien ne sort de votre cluster pour produire un chiffre. La carte des services reconnaît désormais une passerelle quel que soit son nom, grâce aux labels que votre maillage pose sur son propre plan de données, le nom restant la réponse pour les sidecars. Et un plan de contrôle silencieux dit duquel des trois silences il s'agit, dont l'un est « ce n'est pas un plan de contrôle que nous savons lire ».
Le maillage et le noyau. Sur un cluster maillé, chaque appel est intercepté : un graphe de dépendances y dessine donc soit des sauts qui n'en sont pas, soit plus rien. Le hub remonte désormais la parenté propre à chaque trace au travers des proxies et rapporte la dépendance en dessous, en nommant le proxy traversé — et le commutateur du maillage échange les représentations au lieu de les empiler. Le maillage a gagné son écran : charge, latence et taux de succès par proxy, avec les appels transportés en entrée et en sortie comptés séparément, plus la santé du plan de contrôle et la configuration que vos proxies ont refusée. La sonde eBPF passe à une version qui exporte les retransmissions TCP, et son attribution par arête est désormais vérifiée sur un noyau réel plutôt que supposée — ce qui a mis au jour un plantage latent qui emportait toute la sonde dès que les statistiques TCP étaient activées. Enfin, les sondes de point d'entrée répondent à la question que le trafic observé ne peut pas trancher : quelque chose sert-il encore quand personne n'appelle ?
La carte grandit. Les cibles virtuelles placent sur la carte les bases de données, caches et brokers dont vos services dépendent, déduits des spans de sortie des services qui les appellent — aucun agent dans la dépendance, et un broker dessiné des deux côtés. Les pairs non détectés récupèrent l'extrémité d'une connexion que personne n'a instrumentée, que le rendu jetait. Les frontières groupent le graphe par namespace Kubernetes ou par groupe de services, et le volume des arêtes étiquette tous les chemins d'un coup. La barre latérale est devenue des couches — Topologie, Signaux, Exploitation, Infrastructure — le chemin des cinq premières minutes restant inchangé. Le tout à partir de télémétrie qui arrivait déjà : sans nouvelle collecte.
Les clients et les étiquettes. La télémétrie se range désormais sous le
vocabulaire que votre organisation emploie déjà : associez une fois un label de
pod Kubernetes (tags.labels) et il accompagne chaque signal sous la forme
avuru.tag.<clé>, appliqué à la collecte pour que les charges que personne n'a
instrumentées le portent aussi ; filtrez ensuite traces et journaux dessus — une
trace correspond dès qu'un service ayant participé porte l'étiquette. Un
service peut aussi déclarer lui-même son domaine, son environnement et son
avuru.tier en attributs de ressource et être regroupé en conséquence à travers
les namespaces Kubernetes, sans configuration côté hub, avec un avertissement
quand une déclaration ne peut pas être honorée plutôt qu'un repli silencieux.
Deux nouveaux clients lisent la même API publique : la CLI avuruobs, dont
le prédicat --fail-on verrouille un déploiement avec trois codes de sortie
pour distinguer un garde-fou déclenché d'un garde-fou en panne, et une source
de données Grafana — un plugin backend : le jeton d'API n'atteint jamais le
navigateur et les requêtes partent du serveur Grafana. Chaque écran renvoie
maintenant à la page du manuel qui l'explique. La comptabilité du trafic
inter-zones rapporte les octets par paire de zones de disponibilité depuis les
flux noyau, indépendamment de la fonctionnalité réseau par arête. Corrigé : sur
un cluster maillé, la carte dessinait chaque appel applicatif comme deux sauts à
travers un proxy, et activer les flux réseau noyau produisait une configuration
de sensor que le traceur eBPF refuse d'analyser — le conteneur ne démarrait
donc jamais. La mise à niveau est un helm upgrade normal ; tout ce qui est
nouveau est désactivé ou inchangé par défaut.
Publication GitHub
Ouvert aux deux bouts. Faire entrer les données n'oblige plus à re-pointer
tous vos émetteurs : des récepteurs Jaeger (gRPC et thrift/HTTP),
Zipkin, Prometheus remote-write et Loki push arrivent à côté
d'OTLP, un flag de values chacun et tous désactivés par défaut, chacun passant
par la même étape de tenant — les clés d'ingestion par projet sont donc
vérifiées quel que soit le format de fil. Les exportateurs de transfert
(gateway.forward.otlp, gateway.forward.kafka) dupliquent les écritures
vers le backend que vous exploitez aujourd'hui, derrière une file bornée :
adopter avuru obs devient une décision réversible, et chaque protocole est
exercé en CI à travers les récepteurs qu'une véritable installation Helm rend.
À l'autre bout, les projets membres font lire à un projet l'union de
plusieurs clusters sur tous les écrans — appartenance à un seul niveau, chacun
ne voyant que les membres qui lui sont attribués — et les interrupteurs de
composants (hub.enabled, ui.enabled, gateway.enabled) permettent à un
cluster secondaire de n'installer que la moitié « ingestion » face au stockage
central, les combinaisons impossibles étant refusées dès l'installation. Les
projets ont aussi gagné la rétention par projet (un élagage horaire limité
au tenant) et le volume de stockage par projet dans Réglages → Stockage.
Côté énergie, /green nomme les nœuds d'où viennent ses chiffres et les
budgets carbone indiquent s'ils peuvent réellement joindre un canal. Corrigé :
le hub répondait avec sa rétention intégrée plutôt qu'avec celle configurée. La
migration de schéma 0019 s'applique automatiquement ; la montée est un
helm upgrade normal.
Release GitHub
· changelog.
Piloter depuis l'interface. Presque tout ce qu'un opérateur changeait par
values.yaml vit désormais dans l'application : la collecte pilotable à
chaud (des interrupteurs par signal que le capteur suit en quelques secondes,
désactivée par défaut derrière un rôle délibérément étroit), les groupes de
services écrits dans Paramètres → Groupes, un mapping SSO groupe→rôle
éditable à côté des règles du chart en lecture seule, et des jetons d'API
personnels — hachés au repos, montrés une seule fois, résolus vers les
permissions vivantes de leur propriétaire : désactiver un utilisateur
désactive tous ses jetons. Le Tableau de bord devient l'écran d'accueil —
santé des groupes, topologie vivante, alertes actives et capacité Kubernetes
en une seule vue — et la carte des services affiche de vrais anneaux de
statut issus de la consolidation de santé, le p50/p95 par arête côté appelant,
le survol focalisé et des filtres partageables. Également : tri et filtres sur
l'écran Nœuds, et la correction de trois points d'API green qui répondaient
sans authentification. Les migrations de schéma 0016 à 0018 s'appliquent
automatiquement ; la montée de version est un helm upgrade ordinaire.
Version GitHub
· changelog.
Des comptes que vous administrez. La v0.2 créait les utilisateurs ; la v0.4
termine leur cycle de vie. Paramètres → Utilisateurs permet de modifier un
nom et des rôles, de réinitialiser un mot de passe et de supprimer un compte
selon la règle « désactiver d'abord », tandis qu'un nouvel onglet
Paramètres → Compte permet à chacun de changer son propre mot de passe — le
mot de passe actuel est exigé, les autres sessions sont fermées, la vôtre reste
ouverte. Ces opérations sont refusées aux utilisateurs SSO, dont l'identifiant
appartient au fournisseur d'identité. La revue de cette surface a refermé
trois portes d'entrée : un mot de passe local que l'on pouvait créer sur un
compte purement SSO, un verrouillage des connexions que la rotation d'adresses
IP contournait, et une connexion SSO capable de s'approprier l'e-mail d'un
compte local. Côté exploitation : une installation dont la migration de schéma
n'a jamais tourné se répare d'elle-même (hub.autoMigrate) et publie l'état
du schéma dans Paramètres → État ; un nom de base ClickHouse autre que celui par
défaut fonctionne ; green survit aux nœuds sans RAPL ; et la connexion
fonctionne derrière un reverse proxy qui réécrit Host. La montée de version
est un helm upgrade ordinaire.
Version GitHub
· changelog.
Correctif. Les valeurs d'images par défaut du chart n'ont jamais
correspondu à ce que publie le workflow de release — mauvais dépôts et un
format de tag jamais poussé : un helm install sans --set ne pouvait
résoudre ni le hub, ni l'UI, ni la passerelle, ni l'estimateur TDP. Les deux
moitiés sont corrigées ; l'estimateur green, livré sans aucun dépôt, se
comporte désormais comme ses homologues. Aucune migration de schéma, aucun
changement d'API ni de configuration.
Version GitHub
· changelog.
Une multi-tenance digne de confiance. La v0.2 avait sécurisé la lecture ;
la v0.3 verrouille l'écriture. Les projets deviennent quelque chose que vous
administrez — création, renommage et suppression depuis l'interface, les
entrées natives et déclarées dans la configuration restant en lecture seule —
et les clés d'ingestion par projet mettent fin à la confiance topologique :
les clés sont validées dans la passerelle et, en mode enforce, le projet de
la clé fait autorité sur le tenant, quel que soit celui que l'émetteur
déclare (le mode log par défaut ne change rien au pipeline : la promesse
OTLP « prise en charge directe » survit à la mise à jour). Une démo en
lecture seule en un clic connecte un visiteur en tant que lecteur restreint
sans que le mot de passe partagé n'atteigne jamais le navigateur. Le module
green fonctionne désormais sur les VM cloud dépourvues de RAPL, chaque
chiffre modélisé étant étiqueté estimé de bout en bout. Le plan de contrôle
de la collecte à chaud pose ses fondations — stockage de la surcouche, API
validée, droits RBAC restreints — et la couche de déploiement est renommée
avuruops → avuruobs (rupture ; voir le
guide de mise à jour).
Version GitHub
· changelog.
Profondeur et contrôle. L'installation en cinq minutes devient celle qu'une vraie équipe peut exploiter au quotidien : le hub est sécurisé par défaut (connexion, rôles Admin/Éditeur/Lecteur accordés par projet, SSO OIDC avec n'importe quel IdP), les signaux sont modulaires (un interrupteur par famille contrôle d'un bloc schéma, API, pipeline, collecte et interface), et le capteur peut être laissé activé en toute confiance — garanti par la CI. Quatre nouveaux modules s'appuient sur les données déjà collectées : le suivi des erreurs (problèmes dédupliqués et triables, plus une voie d'ingestion navigateur), la santé des services par groupes (niveaux de criticité avec propagation par dépendance), les alertes (webhooks protégés contre les SSRF sur les transitions de santé) et l'énergie & carbone (Wh/gCO2e par service, budgets, export prêt pour la CSRD). La santé réseau arrive sur les liaisons de la carte des services. Sous licence AGPL-3.0 à partir de cette version. Version GitHub · changelog.
La première version taguée : le coin. Un cluster Kubernetes neuf atteint une carte des services en direct en moins de cinq minutes sans changement applicatif — garanti par une porte CI. Les quatre niveaux de signaux v0.1 sont livrés — traces (complet), logs (basique), profilage CPU continu (allégé, sur option), métriques d'infra (support) — plus la migration OTLP « drop-in », un modèle par projet avec contrôles de collecte, et une inspection de traces approfondie. Version GitHub · changelog.
Une fois une version taguée, son entrée renvoie vers la
version GitHub et les
éléments correspondants du Changelog. Les versions sont coupées
selon le RELEASING.md du dépôt moteur.