Le 15 septembre 2026, JetBrains a publié une explication technique du fonctionnement de la fonctionnalité Service Map de l’extension OpenTelemetry. Cette fonctionnalité représente les relations réelles entre les microservices pendant l’exécution de l’application dans l’environnement de développement. L’explication a été préparée par Nikita Dukin et Egor Klimov, dans le cadre d’une collaboration entre l’équipe Rider Execution et l’équipe Software Engineering Research.
L’idée part d’un problème pratique bien connu : un schéma de l’architecture peut sembler organisé, mais refléter l’état du système d’il y a plusieurs mois et ne pas montrer un nouveau service ou une file de messages dont la documentation n’a pas été mise à jour. JetBrains estime que l’analyse statique du code ne suffit pas toujours, car elle décrit ce qui peut se produire dans le code source, et non ce qui se produit réellement entre les services pendant l’exécution.
Les traces sont la source de la carte
L’extension s’appuie sur les données OpenTelemetry, qui recueillent les journaux, les métriques et les traces. Alors que les journaux indiquent ce qui s’est produit et que les métriques montrent l’ampleur du phénomène, les traces révèlent le parcours d’une requête à travers le système. Chaque trace se compose d’unités de travail appelées spans, pour lesquelles OpenTelemetry fournit des conventions sémantiques uniformes, comme les traces HTTP Client et HTTP Server.
L’extension utilise ces traces pour comprendre l’architecture opérationnelle sans lier l’algorithme à un framework ou à un langage particulier. Si les applications et les bibliothèques envoient des traces conformément aux attentes d’OpenTelemetry, la fonctionnalité peut représenter les communications quelle que soit la technologie utilisée. JetBrains précise que la même logique peut fonctionner avec des applications JVM, .NET, Python, Go et d’autres, et qu’elle peut être utilisée dans IntelliJ IDEA, GoLand, PyCharm, WebStorm et Rider.
Comment la carte est-elle construite dans l’environnement de développement ?
Lorsque l’environnement de développement est lancé avec l’extension OpenTelemetry activée, l’extension démarre un léger serveur local qui reçoit les données de télémétrie. Au lancement de l’application, l’extension configure les variables d’environnement OpenTelemetry standard afin que l’application envoie ses traces à ce serveur local.
Le serveur traite les traces reçues de manière asynchrone, construit un modèle interne de l’architecture et le met continuellement à jour. Lors de l’ouverture de l’onglet Service Map, l’extension récupère le modèle structurel le plus récent et l’affiche sous la forme d’un diagramme visuel. La carte n’est donc pas un document statique créé manuellement, mais le résultat direct des communications observées par le système pendant son exécution.
Le défi n’est pas de dessiner, mais d’interpréter les données
Les traces arrivent indépendamment les unes des autres et leur ordre d’arrivée n’est pas garanti. La trace du service enfant peut parvenir avant celle du service parent, et le suivi n’indique pas de moment final d’achèvement garantissant qu’aucune trace tardive n’arrivera. En outre, OpenTelemetry ne fournit pas de type strict distinct pour chaque trace : les traces contiennent une carte de paires clé-valeur décrivant la sémantique de l’opération.
JetBrains a donc classé la reconstruction de l’architecture comme un algorithme de traitement de flux de données. L’extension n’attend pas que la trace soit complète, mais examine chaque trace dès sa réception. Elle utilise des attributs tels que http.request.method et http.response.status_code pour déterminer si l’opération correspond à une communication HTTP, tandis que d’autres attributs signalent une requête de base de données ou une interaction avec un système de messagerie.
Après avoir classé la trace, l’algorithme détermine le service qui l’a émise. Si le service est nouveau, il est ajouté à la carte ; s’il existe déjà, les nouvelles données lui sont intégrées et ses statistiques sont mises à jour. Dans les communications HTTP, l’extension recherche la relation entre la trace CLIENT émise par le service appelant et la trace SERVER produite dans le service récepteur. Le contexte de suivi accompagne la requête, ce qui fait de la trace SERVER l’enfant de la trace CLIENT. Si l’autre partie existe, la relation est représentée immédiatement ; sinon, la trace est conservée en mémoire jusqu’à l’arrivée des données correspondantes.
Les autres dépendances utilisent des règles différentes. En général, un appel de base de données est représenté par une seule trace CLIENT, à partir de laquelle l’extension déduit un nœud de base de données en fonction des attributs sémantiques. Les systèmes de messagerie nécessitent davantage de souplesse, car la relation entre le producteur et le consommateur peut apparaître au moyen d’une relation parent-enfant ou par l’intermédiaire de liens entre traces, selon le système de messagerie et la méthode d’instrumentation utilisée.
Pourquoi est-ce important en pratique ?
La valeur essentielle réside dans le fait que la carte révèle le comportement observé, et pas seulement l’architecture attendue. Si le système montre pendant le développement plusieurs communications HTTP ou requêtes vers une base de données alors qu’une seule communication était prévue, cela peut être détecté avant la mise en production. La carte aide également à comprendre les dépendances qui n’ont pas été documentées ou qui ont évolué au fil du temps.
La précision du résultat reste toutefois liée à la qualité de la télémétrie. L’algorithme a besoin de traces correctes, de la propagation du contexte de suivi entre les services et de l’utilisation des attributs sémantiques attendus. Service Map ne fournit donc pas automatiquement une image complète de n’importe quel système simplement parce que l’extension est installée : ce que les outils de télémétrie n’envoient pas, ou ce qui arrive sans contexte, peut ne pas apparaître dans les relations déduites. L’article précise également que le modèle évolue à mesure que de nouveaux éléments sont reçus, ce qui fait de la carte une représentation opérationnelle actualisée, et non un jugement définitif sur la conception architecturale.