État des fonctionnalités

Un aperçu de ce qui est disponible aujourd'hui par rapport à ce qui arrive. avuru obs v0.18.0 est publiée et le tronc évolue vite — pour le plan, voir la Feuille de route, et pour les changements livrés le Changelog.

Disponible maintenant

Capacité	État	Depuis
Cluster X-Ray — placement interactif des Nodes et Pods, couches transparentes et connexions issues des traces, avec inventaire de repli et limites explicites de la scène	Livré	v0.18
Explorateur de logs multiservice — plusieurs services et workloads en un flux fusionné ou en panneaux par service, sources application/ztunnel/waypoint/autres choisies indépendamment, depuis Signaux → Logs et Service Mesh → Logs ; GET /api/v1/logs composé avec un jeton de pagination signé	Livré	v0.19
Carte des services — arêtes d'appel dérivées des traces, anneaux de santé issus de la consolidation service-health, latence p50/p95 par arête côté appelant, survol focalisé, et filtres de recherche/statut/groupe partageables	Livré	M1
Cibles virtuelles — les bases de données, caches et brokers dont vos services dépendent, déduits de leurs spans de sortie ; aucun agent dans la dépendance, et un broker dessiné des deux côtés	Livré	v0.8
Frontières sur la carte — groupez le graphe par namespace Kubernetes ou par groupe de services, chacun dessiné en conteneur étiqueté	Livré	v0.8
Pairs non détectés — l'extrémité d'une connexion que personne n'a instrumentée, dessinée au lieu d'être jetée, et comptée à part des services	Livré	v0.8
Voisinage d'un service — les appelants et les dépendances d'un service dessinés en schéma fixe, de gauche à droite, sur son onglet Vue d'ensemble, chaque flèche portant le débit et le p95 côté appelant de ce chemin. Mêmes arêtes que les tableaux, aucune requête supplémentaire, et les mêmes refus : un saut reconstitué à travers un proxy de maillage indique via <proxy>, une arête non 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	Livré	v0.13
Un assistant hébergé peut se connecter — le serveur MCP parle OAuth 2.1 : découverte, enregistrement, code d'autorisation avec PKCE, jetons de rafraîchissement à rotation. Les jetons d'accès sont opaques et liés au point d'entrée MCP : l'un d'eux ne peut jamais être rejoué contre le reste de l'API, et ce qu'il peut atteindre est relu à chaque requête. L'écran de consentement indique qu'approuver fait sortir traces et corps de journaux de l'installation, signale que le nom déclaré par l'application n'est pas vérifié, et limite l'accès à un seul projet ; Réglages → Accès liste ce que vous avez connecté et permet de le déconnecter. Désactivé par défaut, derrière son propre interrupteur	Livré	v0.14
Mise au point sur la carte — « Voir sur la carte » conserve un service et son voisinage à un saut au lieu de filtrer le graphe jusqu'à un nœud isolé	Livré	v0.13
Traces — recherche, filtres (tags, ordre, durée, statut), heatmap de latence, aperçu RED par opération	Livré	M1
Visualiseur de traces — chronologie, table des spans, flamegraph, statistiques, graphe, JSON	Livré	M4
Comparaison de traces — diff structurel de deux traces	Livré	M4
Logs — recherche plein texte, filtres sévérité/service, corrélation trace_id	Livré	M1
État du système — santé des composants, stockage, rétention, disque	Livré	M1
DaemonSet sensor — traces + RED eBPF zéro-code (OBI), collecte de logs zéro-config	Livré	M2
Inventaire des services — table RED triable, exploration vers les traces	Livré	M2
Tableau de bord RED — graphiques débit/erreurs/durée par service	Livré	M3
Santé des nœuds / pods — CPU, mémoire, réseau par nœud & pod (kubeletstats), triables sur chaque colonne et filtrables par nom, espace de noms ou charge de travail	Livré	M3
Profilage continu — flame graphs CPU par service (expérimental, opt-in)	Livré	M4
Projets — portée par environnement, sélecteur dans la barre latérale, liens ?project= partageables	Livré	v0.1
Gestion des projets — créer, renommer et supprimer des projets depuis l'UI ; les projets default et définis par configuration restent en lecture seule	Livré	v0.3
Démo en lecture seule — lecteur « Essayer la démo » en un clic, alimenté par des données réelles (OpenTelemetry Astronomy Shop) ; opt-in, connexion côté serveur	Livré	v0.3
Projets membres — un projet lit l'union de plusieurs clusters sur tous les écrans ; l'appartenance a un seul niveau et chacun ne voit que les membres qui lui sont attribués	Livré	v0.6
Rétention par projet — donner à un projet une fenêtre plus courte que celle de l'installation, appliquée par un balayage horaire limité à ce projet	Livré	v0.6
Volume de stockage par projet — lignes, taille estimée, débit d'ingestion et rétention effective du projet sélectionné, à côté des totaux de l'installation	Livré	v0.6
Interrupteurs de composants — n'installer que la moitié « ingestion » sur un cluster secondaire (hub.enabled / ui.enabled / gateway.enabled), en écrivant dans un stockage partagé	Livré	v0.6
Contrôles de collecte — par signal/namespace/pod/nœud, avec inventaire des agents par nœud	Livré	v0.1
Collecte pilotable à chaud — activez ou coupez chaque signal depuis Réglages → Collecte et le capteur suit en quelques secondes, sans helm upgrade ; affiche la configuration effective et revient aux valeurs du chart. Optionnelle, derrière un rôle limité à l'espace de noms et aux ressources de capteur du hub	Livré	v0.5
Suivi des erreurs — problèmes dédupliqués depuis spans/logs, cycle de triage, ingestion au protocole Sentry	Livré	v0.2
Santé des services — santé de groupe avec niveaux de criticité et propagation des dépendances critiques, dérivée du RED	Livré	v0.2
Groupes de services depuis l'interface — créez, modifiez et supprimez les groupes de santé dans Paramètres → Groupes ; effectif dès la lecture de santé suivante, sans helm upgrade. Les groupes déclarés dans le chart restent en lecture seule et l'emportent en cas de collision de nom ; le regroupement automatique par espace de noms est inchangé	Livré	v0.5
Alerting — notifications par webhook quand un service/groupe passe dans un mauvais état	Livré	v0.2
Santé réseau sur la carte des services — RTT + connexions échouées/réinitialisées par arête (stats TCP OBI)	Livré	v0.2
Green — énergie (Wh) & carbone (gCO2e) par service via CNCF Kepler, budgets carbone, export prêt pour la CSRD (désactivé par défaut ; mesuré sur matériel RAPL)	Livré	v0.2
Sûreté du capteur — gate CI « do no harm » (canari sensible aux probes) + mode d'instrumentation opt-in (discovery.mode)	Livré	v0.2
Authentification — sécurisé par défaut : utilisateurs locaux, rôles fixes (admin/éditeur/lecteur) avec droits par projet, sessions côté serveur, Paramètres → Utilisateurs, lecteur anonyme opt-in	Livré	v0.2
SSO — OpenID Connect (découverte, PKCE) avec n'importe quel IdP, mapping groupe→rôle/projets (rechargé à chaud), forceSSO	Livré	v0.2
Modules — un interrupteur par famille de signaux (modules.<name>.enabled) contrôle d'un bloc schéma, API, pipeline, collecte et interface ; barre latérale pilotée par les capacités	Livré	v0.2
Clés d'API d'ingestion — clés par projet validées dans la gateway ; en enforce, le projet de la clé devient le tenant qui fait autorité ; déploiement progressif off/log/enforce	Livré	v0.3
Green sur les nœuds sans RAPL — estimation de puissance par TDP pour les VM cloud (optionnelle), étiquetée estimée de bout en bout et jamais mélangée à l'énergie mesurée ; panneau de couverture sur /green. La source mesurée peut être retirée entièrement (sensor.green.kepler.enabled=false) pour qu'une flotte sans RAPL conserve ses autres signaux	Livré	v0.3
Gestion des utilisateurs — modifier le nom et les rôles d'un utilisateur, réinitialiser les mots de passe et supprimer un compte selon la règle « désactiver d'abord » ; opérations de mot de passe refusées aux comptes SSO	Livré	v0.4
Changement de mot de passe en libre-service — Paramètres → Compte, mot de passe actuel exigé, autres sessions fermées pendant que la vôtre reste ouverte	Livré	v0.4
Auto-réparation du schéma — le hub applique les migrations manquantes à la connexion (hub.autoMigrate) et signale l'état appliqué face à l'attendu via un composant Schéma dans Paramètres → État	Livré	v0.4
Connexion derrière un reverse proxy — auth.trustedOrigins et un contrôle d'origine enforce/log/off pour les proxys qui réécrivent Host	Livré	v0.4
Vue Stockage — connexion ClickHouse (lecture seule), taille, compression et ancienneté par signal, et rétention configurée confrontée au TTL réellement appliqué par les tables	Livré	v0.5
Vue Accès — quel rôle peut lire et lequel peut modifier chaque domaine, déduit par le hub des gardes avec lesquelles ses routes sont enregistrées : impossible de diverger de ce qui est appliqué	Livré	v0.5
Tableau de bord — l'écran d'accueil : santé des groupes de services, topologie compacte, alertes actives et capacité Kubernetes en une seule vue. Chaque bande suit son module et se rabat sur les services les plus actifs, au lieu de disparaître, quand la santé des services est désactivée	Livré	v0.5
Mapping des groupes SSO depuis l'interface — Paramètres → Accès affiche les règles OIDC groupe→rôle déclarées dans le chart et permet à un administrateur d'en créer, modifier et supprimer d'autres à côté ; le chart l'emporte en cas de collision de nom et une règle éclipsée dit pourquoi. Un changement s'applique à la prochaine connexion du groupe, sur tout le cluster en ~15 s	Livré	v0.5
Jetons d'API personnels — émettez, listez et révoquez des jetons bearer dans Paramètres → Accès ; seul le SHA-256 est stocké et la valeur brute n'est montrée qu'une fois. Un jeton est résolu vers les droits vivants de son propriétaire : désactiver un utilisateur désactive tous ses jetons ; un jeton invalide est un 401 net, jamais une rétrogradation anonyme	Livré	v0.5
Compatibilité d'ingestion élargie — récepteurs Jaeger, Zipkin, Prometheus remote-write et Loki push en plus d'OTLP, un flag de values chacun et tous désactivés par défaut ; chaque récepteur passe par la même étape de tenant, donc les clés d'ingestion s'appliquent à l'identique quel que soit le protocole. Des exporteurs de transfert (OTLP/Kafka) dupliquent les écritures vers un second backend pendant une migration, derrière une file bornée pour qu'une cible morte n'exerce aucune contre-pression sur le stockage	Livré	v0.6
Couverture green et délivrabilité des budgets — un tableau d'énergie par nœud sur /green, la distinction mesuré/estimé conservée ligne par ligne, des budgets carbone qui disent s'ils peuvent réellement joindre un canal, et un avertissement quand un budget vise un groupe de services auquel rien ne se rattache	Livré	v0.6

| Étiquettes métier — 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 non instrumentées le portent aussi ; filtrez ensuite traces et journaux dessus, les clés et valeurs découvertes étant proposées comme contrôles. Une trace correspond dès qu'un service ayant participé porte l'étiquette | Livré | v0.7 | | Métadonnées déclarées par le service — un service annonce lui-même son domaine (service.namespace), son environnement et son avuru.tier en attributs de ressource, et le tableau de santé le regroupe en conséquence, à travers les namespaces Kubernetes et sans configuration côté hub. La configuration de l'opérateur l'emporte toujours, et une déclaration inutilisable est signalée plutôt qu'ignorée en silence | Livré | v0.7 | | CLI avuruobs — services, health, traces, logs, status via l'API publique avec un jeton personnel, -o table\|json, et un prédicat --fail-on pour les garde-fous de CI, avec trois codes de sortie pour distinguer un garde-fou déclenché d'un garde-fou en panne | Livré | v0.7 | | Source de données Grafana — RED par service, santé des services, recherche de traces et trafic inter-zones dans les tableaux de bord que vous exploitez déjà. Un plugin backend : le jeton d'API n'atteint jamais le navigateur et les requêtes partent du serveur Grafana | Livré | v0.7 | | Comptabilité du trafic inter-zones — octets par paire de zones de disponibilité depuis les flux noyau, indépendante de la fonctionnalité réseau par arête : la comptabilité coûte le cardinal des paires de zones, pas celui des paires de charges de travail | Livré | v0.7 | | Carte des services consciente du maillage — les charges de transport (sidecars de maillage, proxys waypoint et ztunnel, passerelles d'entrée et de sortie) sont reconnues et masquées derrière une bascule Afficher maillage et passerelles au lieu d'être dessinées comme des dépendances ; les arêtes issues des flux sont tracées et comptées à part des appels tracés | Livré | v0.7 | | Documentation contextuelle — chaque écran renvoie à la page du manuel qui l'explique | Livré | v0.7 | | Une carte des services plus riche — frontières de namespace et de groupe de services, volume porté par chaque arête à la demande, pairs non détectés dessinés au lieu d'être jetés, une légende qui explique chaque canal utilisé et un indicateur de zoom | Livré | v0.8 | | Cibles virtuelles — bases de données, caches et courtiers de messages comme nœuds à part entière de la carte, dérivés des spans sortants déjà stockés. Un courtier est dessiné par ses deux extrémités : une file n'est jamais une impasse | Livré | v0.8 | | Navigation par couches — barre latérale groupée par la question à laquelle chaque écran répond (Topologie, Signaux, Opérations, Infrastructure), le chemin des cinq premières minutes inchangé, et une couche dont tous les écrans sont inactifs disparaît au lieu d'afficher un manque | Livré | v0.8 | | Reconstitution du saut de proxy — la vraie dépendance app → app retrouvée à travers jusqu'à trois proxys enchaînés, en remontant la parenté propre à chaque trace, et nommée avec le proxy traversé. La bascule Afficher maillage et passerelles échange les représentations au lieu de les empiler : une requête n'est jamais dessinée deux fois | Livré | v0.9 | | Surfaces dédiées au maillage — 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 : proxys connectés, convergence des poussées, et la configuration que vos proxys ont refusée. Sans collecte, l'écran le dit au lieu d'afficher zéro | Livré | v0.9 | | Retransmissions TCP sur les arêtes de la carte — la perte de paquets sur un lien, que le RTT seul ne révèle pas, aux côtés du RTT p95 et des connexions échouées ; une arête qui retransmet est signalée dégradée pour cette seule raison | Livré | v0.9 | | Attribution réseau par arête, vérifiée en intégration continue sur un vrai cluster eBPF plutôt que supposée — ce qui a révélé et corrigé un plantage latent emportant toute la sonde dès que les statistiques TCP étaient activées | Livré | v0.9 | | Sondes de point d'entrée — requêtes planifiées rattachées à un groupe de santé, pour distinguer un groupe sans trafic d'un groupe sans service. Deux échecs consécutifs font bouger un groupe, jamais un seul, et chaque sonde émet son propre span : une sonde en échec renvoie vers la trace de la requête qui a échoué | Livré | v0.9 | | Coûts & gaspillage — le CPU et la mémoire réservés par chaque charge de travail face à ce qu'elle a réellement consommé, classés par l'écart, avec les charges qui ne déclarent 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. Les tarifs sont les vôtres à déclarer ; sans eux, les écrans affichent des cœurs et des octets et le disent — aucune API de tarification, aucune sortie de données. Désactivé par défaut | Livré | v0.10 | | Transport reconnu par les labels Kubernetes — une passerelle que vous avez nommée n'importe comment est classée grâce au label que votre maillage lui a posé, le nom restant la réponse pour les sidecars (qui portent les labels de leur application) et votre liste applications restant décisive | Livré | v0.10 | | Silence du plan de contrôle expliqué — rien ne le collecte, la cible ne répond pas, ou elle a répondu avec des métriques qui ne sont pas celles d'un plan de contrôle que ce produit sait lire. Trois états et trois corrections différentes, là où il n'y avait qu'une phrase | Livré | v0.10 | | Observabilité IA — les appels de modèles que vos applications envoient déjà : par modèle, les appels, les tokens en entrée et en sortie, la latence, les échecs et les troncatures ; par service appelant, les mêmes chiffres avec un propriétaire. Le modèle qui a répondu l'emporte sur celui demandé, les deux orthographes des tokens sont lues, un appel sans usage rapporté est exclu plutôt que compté à zéro, et la troncature est signalée à part de l'échec. Les tarifs sont les vôtres à déclarer ; il n'y a pas d'API de tarification. Désactivé par défaut | Livré | v0.11 | | Prompts et complétions supprimés à la passerelle par défaut — le contenu des messages n'atteint le stockage que parce que le SDK d'une application l'a capturé, et il y était jusqu'ici conservé avec la rétention habituelle et montré à tout Viewer. Ancré pour qu'un compteur de tokens ne soit jamais pris pour un prompt, et délibérément non conditionné au module IA | Livré | v0.11 | | Répartition des traces — le trafic en treemap et en anneau, groupé par service, opération, issue, type de span ou n'importe quel attribut de span/ressource, pondéré par nombre de requêtes ou par temps total, sur une population de spans explicite (servi / entré / tous les spans). La queue est une vraie catégorie, donc les parts composent le tout | Livré | v0.11 | | Page de détail par service — la santé d'un service, son RED dans le temps, ses appelants et ses dépendances en deux listes séparées, et ses traces, journaux et incidents derrière des onglets. Composée de lectures qui existaient déjà | Livré | v0.11 | | Chemin de trace — le graphe au niveau service d'une seule requête, pondéré par le temps passé dans chaque service plutôt que par la durée du span, avec les dépendances qui n'ont jamais émis dessinées comme les sauts terminaux qu'elles sont | Livré | v0.11 | | Refusé — le 4xx côté serveur comme issue à part entière, à côté de ok et erreur, sur le badge du span, l'aperçu des opérations, la table des traces et le filtre de recherche, et délibérément tenu hors du taux d'erreur | Livré | v0.11 | | Appels d'outils distingués des appels de modèles — le module IA vérifiait la présence de gen_ai.operation.name sans jamais en lire la valeur : sur une charge agentique, chaque span execute_tool comptait comme un appel de modèle. Le nombre d'appels gonflait, la latence mêlait une requête en base à une complétion, le modèle ne se résolvait plus et le compartiment « aucun usage » se remplissait de spans qui n'en étaient pas. Les embeddings restent comptés comme des appels de modèles : ils consomment de vrais tokens | Livré | v0.12 | | Table des outils — par outil exécuté par un agent : appels, échecs, p95 et services appelants, un outil sollicité quatre fois formant une seule ligne avec un compteur. Ni tokens ni coût : une exécution d'outil n'en consomme pas, et un zéro se lirait « gratuit » | Livré | v0.12 | | Vue Tour d'agent — un tour dessiné comme le graphe qu'il est, appels de modèles et exécutions d'outils comme types de nœuds distincts, pondérés par le temps passé à l'intérieur de chaque appel plutôt que par la durée du span. Proposée uniquement sur les traces qui en contiennent un | Livré | v0.12 | | Budgets de dépense — plafonds mensuels en tokens ou en monnaie, par service appelant ou pour tout le parc, déclenchés via vos canaux d'alerting existants. Un budget en monnaie sans prix déclaré est refusé au démarrage plutôt que de rester éternellement sous tous les seuils, et un périmètre partiellement tarifé indique que son chiffre est un plancher | Livré | v0.12 | | Une seule grille tarifaire — prix des modèles et tarifs de calcul dans un même document avec une seule devise, éditable dans les Paramètres et appliquée sans redéploiement. Les valeurs déclarées dans le chart restent lisibles et en lecture seule, les entrées de l'interface s'y superposent, et chaque ligne indique son origine | Livré | v0.12 | | Serveur MCP — six outils en lecture seule sur les traces, les logs, les issues et la santé déjà stockés, pour qu'un agent enquête sur un incident au lieu qu'une personne retape un écran. Un seul handler sur le hub, authentifié par les jetons d'API personnels qui résolvent les permissions vivantes de leur propriétaire. Un service mal orthographié renvoie les correspondances les plus proches plutôt qu'un résultat vide, et une section à laquelle l'installation ne peut pas répondre est nommée plutôt que silencieusement absente. Éteint par défaut : ce qu'un agent lit sort de votre cluster vers le fournisseur de modèle choisi, l'interrupteur est donc le vôtre — et chaque appel d'outil est journalisé avec le propriétaire du jeton, l'outil, ses arguments et le nombre de lignes | Livré | v0.12 | | Des images de collecteur sans Critical corrigeable — la distro de la gateway épingle x/crypto, x/text et grpc au-dessus de leurs avis de sécurité, et l'agent de nœud suit la ligne du collecteur qui scanne le plus proprement. Un registre appliquant une policy « blocage sur Critical » cesse de servir une image signalée, ce qui se manifeste par un déploiement qui expire plutôt que par un rapport de scan | Livré | v0.12 | | Aucune image n'a besoin d'exception dans un registre — l'agent de nœud reçoit sa propre distribution de collecteur, ne portant exactement que les composants utilisés par sa configuration rendue et fixant x/crypto et x/mod là où aucune version du collecteur ne le fait. Chaque image tirée par défaut par le chart est exempte de vulnérabilité critique ou haute corrigeable ; l'image amont d'origine reste disponible en surcharge, et le fichier de valeurs dit ce que cela coûte | Livré | v0.13 |

| Proxys de maillage par rôle — plan de contrôle, passerelles d'entrée et de sortie, waypoint, ztunnel et sidecar comme rôles filtrables, à côté de l'espace de noms de chacun, lus dans des labels que votre maillage écrit déjà et que le stockage conservait déjà. Les appels transportés en entrée et en sortie sont nommés comme des appels ; les octets, le temps d'aller-retour, les connexions échouées et les retransmissions ont leurs propres colonnes, et une installation qui n'en mesure aucun n'affiche pas de colonne plutôt qu'un zéro | Livré | v0.14 | | Un proxy que l'on peut ouvrir — le débit, les erreurs et la latence propres à un proxy dans le temps, et ce qu'il transporte : les vraies dépendances app → app reconstituées à travers lui, avec le nombre de proxys traversés par chacune. Plus un graphe du maillage dessiné en conservant ces sauts, c'est-à-dire ce que la carte des services existe pour retirer. Composé à partir de lectures qui existaient déjà | Livré | v0.14 | | La configuration du maillage, et ce qui ne va pas dedans — un module en lecture seule accordé séparément (get/list/watch, son propre compte de service, aucun verbe d'écriture que le chart accepterait de rendre) qui liste tous les espaces de noms définis par le cluster, y compris ceux qui sont inscrits et silencieux qu'aucune télémétrie ne pouvait montrer, et vérifie six façons dont un maillage casse sans rien émettre : une route pointant vers un service ou un port inexistant, une route nommant une passerelle absente, une passerelle à laquelle rien ne se rattache, un hôte non résolu, TLS désactivé sous une règle stricte, une charge dirigée vers un waypoint absent. Désactivé par défaut, et séparé du module de maillage précisément pour que la lecture à l'échelle du cluster reste une décision explicite | Livré | v0.14 | | Le compte que les proxys tiennent eux-mêmes de leur trafic — 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à : aucun point d'entrée à saisir, et chaque proxy atteint exactement une fois. TLS mutuel ou clair par requête et par connexion, l'indicateur de réponse porté par un échec, la version de destination, le compte que ztunnel tient des charges qu'il transporte, et up par proxy pour que « personne ne collecte » se lise autrement que « les proxys ne répondent pas ». Activé par défaut sous le module de maillage (mesh.dataPlane.enabled=false pour garder l'écran sans la collecte) ; les installations sans le module ne sont pas touchées | Livré | v0.15 | | Le déclaré à côté de l'observé — un onglet Sécurité avec une ligne par charge de travail : le mode PeerAuthentication en vigueur avec la portée qui l'a décidé, la part de TLS mutuel observée, et un verdict parmi quatre — strict et tout en mTLS ; déclaré strict, observé en clair (un constat : la politique ne s'applique pas) ; permissif mais prêt à être resserré ; permissif avec des appelants en clair, nommés. Le trafic d'un espace de noms ambiant qu'aucun proxy n'a transporté est un constat à part. Aucun pourcentage tant que le plan de données n'a pas réellement été lu, et pas de colonne Déclaré quand le module de configuration est désactivé | Livré | v0.15 | | Chaque charge de travail que le cluster exécute, dans le maillage ou non — un onglet Charges de travail qui lit les pods (toujours get/list/watch, une douzaine de champs conservés par pod, plafonnés à part) : capturée, sidecar, déclarée, non inscrite ou hors maillage, avec le waypoint qui la lie et pourquoi, les politiques qui la couvrent, le mode mTLS déclaré avec la politique qui l'a décidé (sélecteurs compris), la part observée, son trafic et ses constats. Une page par charge avec ses pods ; une page de waypoint listant ce qu'il sert et si quelque chose l'exécute ; des lignes d'espace de noms qui disent d'où vient leur mode et combien de charges sont inscrites | Livré | v0.15 | | Dix-sept vérifications de configuration — les six de la v0.14 plus celles qui visent la configuration qui a l'air finie et ne l'est pas : une charge étiquetée ambiante jamais capturée, une politique ne correspondant à aucun pod ou ne nommant rien, un lien vers un waypoint que personne n'a déployé, des règles de niveau HTTP dans un espace de noms ambiant sans waypoint, un sidecar dans un espace de noms ambiant, une route vers un sous-ensemble non défini, deux règles revendiquant un même hôte, une passerelle qu'aucun pod ne sert, des écouteurs en conflit, une règle d'autorisation nommant un compte de service sous lequel rien ne tourne ; le conflit mTLS jugé par charge, dans les deux sens. Les cinq qui ont besoin des pods se taisent et le disent quand la liste des pods a été refusée ou coupée | Livré | v0.15 | | Les requêtes d'un proxy par issue — par indicateur de réponse avec la raison du proxy en toutes lettres (disjoncteur ouvert, relances épuisées, amont injoignable, aucune route), par version de destination, et par appelant avec son nombre de 5xx. Les compteurs par amont qu'un maillage par défaut n'expose pas sont nommés comme non collectés, avec le réglage qui les expose, jamais affichés à zéro. Les lignes ztunnel portent les charges transportées et celles encore en attente ; la carte du plan de contrôle ajoute les conflits d'écouteurs et le p95 de file d'attente | Livré | v0.15 | | Le graphe du maillage distingue ses proxys — une étoile pour le plan de contrôle, une étiquette pour une passerelle tournée vers l'intérieur et son miroir pour une tournée vers l'extérieur, un chevron pour ztunnel, un double anneau pour un waypoint, avec une légende qui ne nomme que les formes présentes — et chaque arête mesurée par un proxy de destination porte un marqueur côté appelant, sur la carte des services comme sur le graphe du maillage : un té pour tout en TLS mutuel, un cercle creux pour mixte, un cercle plein pour en clair. Une arête que personne n'a mesurée n'en porte aucun | Livré | v0.15 | | La page d'une charge de travail se lit comme la fiche que le cluster en tient — créée quand et par quel contrôleur (ou par son pod le plus ancien, et elle le précise), type, app et version, chaque étiquette, les annotations du contrôleur dans des bornes explicites, chaque pod avec le déploiement auquel il appartient, et un verdict de santé en un mot avec la raison qui l'a décidé. À côté des politiques qui sélectionnent la charge par étiquette, les routes et règles qui l'atteignent par ses Services — HTTPRoute, GRPCRoute, VirtualService, DestinationRule — chacune avec ses propres constats, si bien qu'une charge routée n'est jamais dite sans configuration. Rien de nouveau n'est lu : les objets étaient déjà observés | Livré | v0.16 | | Les journaux d'une charge de travail depuis ses trois sources, dans une seule table — ses propres lignes, les lignes de ztunnel nommant l'un de ses pods et les lignes du waypoint nommant son Service, en un seul flux ordonné sous un seul curseur, composé par le hub qui connaît les pods. Recherche, sévérité minimale et une case à cocher par source dans l'URL, les lignes de la charge elle-même par défaut et celles des proxys à un clic ; une ligne disant ce qui a réellement été demandé ; et quand les pods ne peuvent pas être connus, une reconnaissance par nom et espace de noms ensemble, avec la raison énoncée plutôt qu'une colonne vide. Nécessite le module de journaux ; mesh-config ne fait que le rendre précis | Livré | v0.16 | | Les journaux de conteneurs portent un niveau — l'agent de nœud le lit sur chaque ligne suivie (un champ JSON level, nommé ou numérique ; une paire level= ; le jeton en majuscules habituel) et renseigne la sévérité OTel, si bien que les filtres de sévérité et les problèmes d'erreur issus des journaux fonctionnent pour les applications qui n'écrivent que sur stdout ; les enregistrements qui portent déjà un niveau ne sont pas touchés. Désactivable avec sensor.agent.logs.parseSeverity=false | Livré | v0.17 | | L'écran Erreurs dit ce que sa liste de problèmes représente — problèmes correspondants, combien ont été vus pour la première fois dans la fenêtre, combien ont régressé, les occurrences produites avec un histogramme, et les services les plus bruyants comme filtres en un clic. Le bandeau agrège le même ensemble que les lignes en dessous, via la même requête SQL : les deux ne peuvent pas annoncer des totaux différents. La liste défile enfin, avec un en-tête fixe, et nomme le total réel quand un filtre dépasse les 200 problèmes chargés | Livré | v0.17 | | Les journaux d'un service, trouvés sous le nom que leur donne son pod — l'onglet Journaux d'un service rattache celui-ci à sa charge de travail (le k8s.deployment.name de ses spans, ou le Service Kubernetes placé devant lui) et lit les trois mêmes sources que la page de la charge : ses propres lignes sous l'un ou l'autre nom, et celles de ztunnel et du waypoint à une case à cocher. Quand aucune charge ne peut lui être rattachée, l'onglet affiche les propres lignes du service et une phrase nommant ce qu'il faut corriger. Seul le module de journaux est requis ; les sources des proxys demandent mesh-config | Livré | v0.17 | | Des journaux que l'on peut sortir de l'écran — chaque table de journaux copie toutes les lignes chargées, ou une sélection faite par plages au clic-maj, et télécharge ce qui est chargé dans un fichier .log, chaque commande indiquant combien de lignes elle prendra ; le bouton de copie de chaque ligne est accessible au clavier | Livré | v0.17 | | Explorer s'ouvre sur les connexions entre services — la carte des services est le point d'entrée de l'application ; sélectionner un nœud garde la carte visible et ouvre un inspecteur avec les appelants, les dépendances et des liens vers le détail du service, ses traces et ses journaux ; la sélection se partage dans l'URL et se fait au clavier, et un projet vide explique comment brancher eBPF et OTLP | Livré | v0.17 | | Cluster X-Ray — une vue isométrique interactive des Nodes, des Pods translucides et d'une couche d'infrastructure logique à côté de l'inventaire : orbiter, zoomer, séparer ou masquer les couches, filtrer les namespaces, inspecter le CPU, la mémoire et le placement d'un Pod, et suivre les connexions que vos traces ont enregistrées (GET /api/v1/infra/pod-connections : requêtes, erreurs et p95 par appelant, uniquement entre identités de Pods enregistrées). Se charge à la demande, annonce les limites de sa scène, et l'inventaire reste disponible au clavier et sans WebGL | Livré | v0.18 | | Un seul explorateur de logs pour plusieurs services et workloads — choisissez-les, sélectionnez les sources à lire (les lignes des applications, celles de ztunnel, celles des waypoints, tout le reste) et suivez-les en un flux fusionné du plus récent au plus ancien ou en un panneau par service, depuis Signaux → Logs et depuis Service Mesh → Logs ; sélection, sources et affichage vivent dans l'URL, et GET /api/v1/logs compose les sujets en une seule requête paginée sous un jeton de pagination signé | Livré | v0.19 | | Thème sombre ardoise — des surfaces ardoise et des actions bleu clair remplacent la forêt et le citron vert en mode sombre ; la carte des services et Cluster X-Ray suivent, le thème clair est inchangé, le vert ne signifie plus que « sain », et le texte secondaire est un vrai jeton qui atteint 4,5:1 sur chaque surface | Livré | v0.19 | | Le Service Mesh ne montre à un compte limité à des projets que les namespaces de ces projets — la liste des namespaces, celle des workloads, le navigateur de configuration, le détail d'un workload et d'un waypoint sont restreints aux namespaces que les projets de l'appelant atteignent, dérivés de la télémétrie de ce projet dans la fenêtre ; une identité autorisée sur tous les projets voit toujours le cluster entier | Livré | v0.19.1 |

À venir

Capacité	État	Cible
Plans de contrôle autres qu'Istio — la moitié « par proxy » fonctionne déjà partout ; la moitié « plan de contrôle » est aujourd'hui façonnée pour Istio	Prévu	prochaine
Coût joint au module vert — la même capacité réservée et inutilisée en Wh et gCO2e, sur une installation qui exécute les deux	Prévu	prochaine
Décisions typées — un classifieur qui répond par une probabilité calibrée, jamais par du texte, pour la sévérité qu'une règle n'a pas su lire, les erreurs qu'une empreinte a séparées et les alertes à trier ; au plus un module optionnel, par lots, n'envoyant que des charges structurées ou nettoyées, mesuré par un banc d'essai hors ligne avant qu'aucun module n'existe (note de conception)	Prévu	en évaluation

:::info La carte des services aujourd'hui Les arêtes de topologie sont dérivées des spans de traces (paires Client/Server inter-services) — et avec le DaemonSet sensor, chaque service HTTP/gRPC est tracé zéro-code : les applications non instrumentées apparaissent aussi. La fonctionnalité network intégrée d'OBI enrichit encore la carte avec les arêtes non instrumentées et la santé réseau par arête lorsqu'elle est activée. L'anneau d'un nœud est lu depuis la consolidation service-health, jamais recalculé sur la carte — un service hors de la couverture de cette consolidation s'affiche unknown, jamais healthy. :::