Carte des services

La carte est la page d'accueil du produit : ce qui tourne, qui parle à qui, et ce qui va mal — dessiné à partir de télémétrie qui arrive d'elle-même. Installez le chart et générez du trafic vers les workloads pris en charge. La découverte dépend du noyau, des protocoles et des permissions de collecte. Le seuil de cinq minutes est un objectif vérifié en CI Kubernetes, pas une garantie pour tous les clusters.

Le graphe est dérivé de la télémétrie observée.

Capture du produit ; services, disposition et mesures disponibles varient selon votre environnement.

Essayer une investigation complète

Le guide du checkout lent fournit un jeu de données synthétiques. Suivez une dépendance PostgreSQL, ses spans et un log corrélé, sans installer de base de données.

D'où vient l'image

Trois sources, fusionnées en un seul graphe :

Source	Ce qu'elle apporte
Spans de trace	Le span client de l'appelant et le span serveur de l'appelé forment une arête, avec le volume d'appels, le taux d'erreur et la latence vue par l'appelant.
Flux réseau noyau (eBPF)	Les connexions que personne n'a instrumentées — les services sans SDK apparaissent quand même, et les octets échangés avec.
Spans de sortie	Les bases de données, caches et brokers qui n'émettent aucune télémétrie. Voir dépendances.

Une arête issue des seuls flux est en pointillés : le noyau a vu la connexion, mais aucun appel tracé ne la sous-tend, donc il n'y a ni débit ni latence à annoncer. Zéro serait un mensonge — ce chemin n'a pas été mesuré, il n'est pas inactif.

Lire la carte

La carte consacre chaque canal visuel à un fait différent, si bien qu'un nœud peut en dire plusieurs à la fois sans qu'aucun n'en écrase un autre :

Canal	Signification
Couleur de l'anneau	état de santé — vert sain, ambre dégradé, rouge en panne, gris inactif ou non mesuré
Taille	débit de requêtes
Remplissage	identité — un nœud applicatif ordinaire
Forme	la nature du nœud (voir ci-dessous)
Épaisseur d'arête	volume d'appels
Couleur d'arête	neutre, ambre en tirets pour un problème réseau, rouge pour des erreurs applicatives
Halo	gCO₂e, sous la loupe carbone

Un anneau n'est jamais vert par défaut. Un service que le calcul de santé n'a pas mesuré reste gris : un service non observé ne doit pas se lire comme un service en bonne santé.

Les formes disent ce qu'est un nœud

• Hexagone — une application.
• Tonneau en tirets — une base de données, un cache ou un broker.
• Losange — un proxy de service mesh ou une passerelle. Masqué par défaut ; voir les sauts de mesh.
• Contour vide — un pair vu dans le trafic qui n'a jamais rien émis.

La forme est un canal distinct de la couleur, volontairement : ajouter une nature de nœud ne coûte jamais à la carte une couleur qu'elle utilisait déjà.

Des dépendances qui ne parlent jamais

PostgreSQL, Redis et Kafka n'embarquent ni SDK ni sonde. Sans rien faire, un service qui passe l'essentiel de sa latence dans une base est dessiné comme un hexagone isolé que rien n'explique — et quatre services partageant un même cache forment un rayon de souffle que personne ne voit.

Avuru Obs les déduit des spans de sortie des services qui les appellent. Lorsque la capture du protocole est prise en charge, eBPF peut fournir ces spans. Sinon, instrumentez le client de base avec OpenTelemetry. Une connexion réseau seule ne mesure pas une opération de base.

Chaque nœud de dépendance est nommé comme une URI — postgresql://orders-db, redis://session-cache, kafka://broker-0 — et ses arêtes portent le volume d'appels, le taux d'erreur et la latence mesurée par l'appelant. Un broker est dessiné des deux côtés, pour qu'une file ne soit jamais une impasse : producteur → broker → consommateur.

:::note Ce que l'on sait, et ce que l'on ignore Une dépendance déduite ne reçoit aucun verdict de santé : on ne la voit qu'à travers ses appelants. Quand les appels échouent, c'est l'arête qui passe au rouge — ce qui est exactement ce que l'on a observé. Cliquer dessus ne fait rien : elle n'a pas de traces à ouvrir.

Les appels HTTP vers des API tierces ne sont volontairement pas dessinés. Les admettre tous mettrait chaque CDN, fournisseur d'identité et endpoint de métriques sur la carte d'un coup, ce qui la rendrait moins lisible, pas plus. :::

Un saut de mesh n'est pas une dépendance

Un sidecar de service mesh, un waypoint ou une passerelle d'entrée émet des spans et échange des octets exactement comme une application. Sans rien faire, chaque appel app → proxy → app est dessiné comme deux dépendances, ce qui affirme une relation entre des services qui ne se parlent jamais.

Avuru Obs classe ces charges de travail comme du transport et les masque par défaut. Afficher mesh et passerelles les ramène — le hub les rapporte toujours, donc la bascule ne coûte aucune requête, et un mesh qu'on ne peut pas voir est un mesh qu'on ne peut pas déboguer. Le maillage dispose aussi de son propre écran, où les proxys sont le sujet plutôt que le bruit.

Comment un proxy est reconnu

De deux façons, et la seconde ne fait jamais qu'ajouter à la première.

Par les labels que votre maillage écrit. Une passerelle, un waypoint ou un composant de plan de contrôle créé via la Gateway API ou par Istio porte un label qui le dit, et le sensor transporte un petit ensemble fixe de ces labels sur les spans qu'il collecte déjà. Une passerelle que vous avez appelée public-edge est reconnue grâce à ce label, sans que vous ayez rien à configurer.

Par le nom, pour tout le reste. La liste intégrée est volontairement étroite — rien de générique comme *-gateway ou *-proxy, car un faux positif efface un vrai service de la carte, ce qui est pire que le bruit supprimé. Ajoutez vos propres motifs via la configuration topology du hub.

Un label ne peut que promouvoir une charge de travail en transport, jamais la rétrograder. Avec un sidecar, il n'y a aucun label à lire : le proxy est un conteneur dans le pod de l'application et porte les labels de l'application — l'absence ne prouve donc rien, et le nom reste la réponse dans ce cas. Enfin, la liste applications de votre configuration topology l'emporte toujours sur les deux : un contournement qu'un signal pourrait défaire n'en serait pas un.

La dépendance en dessous

Masquer le saut supprime la fausse affirmation. Cela ne rétablit pas pour autant la vraie : les proxys disparus, un parc entièrement maillé n'est plus qu'un ensemble de nœuds isolés.

Le hub lit donc la chaîne de parenté propre à chaque trace — le span de l'appelé, son parent, puis le parent de celui-ci — en enjambant les proxys jusqu'à atteindre l'application qui a réellement passé l'appel. Cette arête est dessinée comme n'importe quelle dépendance, et la survoler nomme le proxy traversé (via istio-proxy). La ligne de comptage indique combien d'arêtes ont été reconstituées ainsi.

C'est la parenté par trace qui rend l'opération sûre. Apparier en agrégat les arêtes entrantes d'un proxy avec ses arêtes sortantes inventerait un produit croisé d'appels qui n'ont jamais eu lieu — un proxy avec quatre appelants et cinq backends offre vingt paires possibles, sans moyen de savoir lesquelles se sont produites. Remonter les parents d'un span donne exactement un appelant par appel.

:::info Une requête, dessinée une fois Une arête app → app reconstituée et les deux sauts dont elle provient décrivent les mêmes requêtes. La bascule échange donc les représentations au lieu de les empiler : mesh masqué, on voit la dépendance ; mesh affiché, on voit les sauts. Jamais les deux, et le trafic n'est jamais compté deux fois. :::

Frontières

Grouper par dessine un conteneur étiqueté autour de chaque namespace ou de chaque groupe de services. Au-delà d'une quarantaine de nœuds, un graphe non groupé est une pelote, et vous connaissez votre parc par namespaces ou par groupes — pas comme un nuage indifférencié.

Les namespaces proviennent de la même résolution que l'auto-groupement du tableau de santé : une boîte sur la carte et un groupe sur le tableau ne peuvent donc jamais se contredire sur l'endroit où vit un service. Un service qui n'en déclare aucun est dessiné hors de toute frontière, plutôt que rangé dans un « autre » inventé.

Les pairs que vous n'avez pas encore instrumentés

Une arête dont l'extrémité n'a jamais émis de télémétrie était jetée — un graphe a besoin de deux nœuds, et un seul existait. Ces extrémités sont désormais dessinées en contour vide, comptées à part des services, et sans aucune métrique, puisqu'il n'y en a pas.

C'est souvent ce qu'il y a de plus intéressant à l'écran : c'est la partie de votre parc que rien d'autre ne voit. Chacune est une candidate pour la prochaine chose à instrumenter.

:::note Pas étiquetés « externes » Nommer l'extrémité d'une connexion qui sort du cluster demanderait un attribut d'adresse sur la métrique de flux, que la sonde ne collecte volontairement pas — la cardinalité par paire d'IP coûte cher et a été un vrai défaut que nous avons corrigé. La carte dit donc non détecté, ce que l'on sait, plutôt qu'externe, ce qui serait une supposition. :::

Manipuler la carte

• Survolez un nœud pour focaliser son voisinage : tout le reste s'estompe, ses arêtes s'épaississent et révèlent rpm, p95, taux d'erreur et RTT, avec une flèche à mi-arête pour le sens.
• Survolez une arête pour l'infobulle complète — connexions échouées et octets de flux.
• Volume des arêtes étiquette toutes les arêtes d'un coup, quand la question est lequel de ces chemins porte le trafic.
• Cliquez un service pour ouvrir ses traces.
• Filtrez par nom, par groupe, ou sur les seuls problèmes.
• Relancez la disposition pour défaire un enchevêtrement ; zoomez et ajustez, avec le pourcentage affiché à côté.

Chaque filtre et chaque bascule vit dans l'URL. Une carte qui montre exactement ce que vous regardez est un lien que vous pouvez coller à un collègue — c'est une fonctionnalité, pas un hasard.

Limites

• La reconstitution suit au plus trois proxys enchaînés. Un maillage à sidecars interpose deux spans de proxy, le mode ambient jusqu'à trois ; une chaîne plus profonde n'est pas suivie, et ses sauts restent masqués au lieu d'être dessinés comme des dépendances.
• Les arêtes issues des flux portent des octets, pas des débits. Aucun appel tracé à mesurer : elles affichent un volume et aucune latence.
• Les dépendances déduites sont regroupées par cible, pas par destination. Tous les topics d'un même broker forment un nœud : le sujet de la carte est la dépendance, et le détail par topic revient à un écran qui a la place.

Voir aussi

• Santé réseau — RTT et connexions échouées par arête, sur ces mêmes arêtes.
• Santé des services — d'où viennent les anneaux d'état.
• Concepts clés — comment les signaux s'articulent.