JetBrains veröffentlichte am 15. September 2026 eine technische Erläuterung dazu, wie die Service Map-Funktion der OpenTelemetry-Erweiterung arbeitet. Die Funktion stellt die tatsächlichen Beziehungen zwischen Mikroservices dar, während die Anwendung innerhalb der Entwicklungsumgebung ausgeführt wird. Die Erläuterung wurde von Nikita Dukin und Egor Klimov im Rahmen einer Zusammenarbeit zwischen dem Rider-Execution-Team und dem Team für Software-Engineering-Forschung erstellt.
Ausgangspunkt ist ein bekanntes praktisches Problem: Ein Architekturdiagramm kann geordnet wirken, möglicherweise aber den Zustand des Systems von vor Monaten widerspiegeln und weder einen neuen Service noch eine Nachrichtenwarteschlange zeigen, deren Dokumentation nicht aktualisiert wurde. JetBrains ist der Ansicht, dass eine statische Codeanalyse nicht immer ausreicht, weil sie beschreibt, was im Quellcode geschehen könnte, und nicht, was während des Betriebs tatsächlich zwischen den Services geschieht.
Traces sind die Quelle der Karte
Die Erweiterung stützt sich auf OpenTelemetry-Daten, die Logs, Metriken und Traces erfassen. Während Logs erklären, was geschehen ist, und Metriken das Ausmaß eines Phänomens zeigen, machen Traces den Weg einer Anfrage durch das System sichtbar. Jeder Trace besteht aus Arbeitseinheiten, die als Spans bezeichnet werden. OpenTelemetry stellt dafür einheitliche semantische Konventionen bereit, etwa für HTTP-Client- und HTTP-Server-Spans.
Die Erweiterung verwendet diese Traces, um die Laufzeitarchitektur zu verstehen, ohne die Algorithmen an ein bestimmtes Framework oder eine bestimmte Sprache zu binden. Wenn Anwendungen und Bibliotheken Traces entsprechend den Erwartungen von OpenTelemetry senden, kann die Funktion die Verbindungen unabhängig von der verwendeten Technologie darstellen. JetBrains zufolge kann dieselbe Logik mit JVM-, .NET-, Python-, Go- und anderen Anwendungen arbeiten. Sie kann außerdem in IntelliJ IDEA, GoLand, PyCharm, WebStorm und Rider eingesetzt werden.
Wie wird die Karte innerhalb der Entwicklungsumgebung erstellt?
Wenn die Entwicklungsumgebung mit aktivierter OpenTelemetry-Erweiterung ausgeführt wird, startet die Erweiterung einen schlanken lokalen Server, der Telemetriedaten empfängt. Beim Starten der Anwendung setzt die Erweiterung die standardisierten OpenTelemetry-Umgebungsvariablen so, dass die Anwendung ihre Traces an diesen lokalen Server sendet.
Der Server verarbeitet die eingehenden Traces asynchron, erstellt ein internes Modell der Architektur und aktualisiert es fortlaufend. Beim Öffnen des Service-Map-Tabs ruft die Erweiterung das aktuellste Strukturmodell ab und zeigt es als visuelles Diagramm an. Die Karte ist somit kein manuell erstelltes statisches Dokument, sondern das direkte Ergebnis der Verbindungen, die das System während des Betriebs beobachtet hat.
Die Herausforderung ist nicht das Zeichnen, sondern die Interpretation der Daten
Die Traces treffen unabhängig voneinander ein, und ihre Reihenfolge ist nicht garantiert. Ein Trace des untergeordneten Services kann vor dem Trace des übergeordneten Services eintreffen. Außerdem signalisiert ein Trace keinen endgültigen Abschlusszeitpunkt, der das Eintreffen eines verspäteten Traces ausschließen würde. Darüber hinaus stellt OpenTelemetry keinen streng getrennten Typ für jeden Trace bereit; vielmehr enthalten Traces eine Map aus Schlüssel-Wert-Paaren, die die Semantik der Operation beschreiben.
JetBrains ordnete die Rekonstruktion der Architektur daher als Algorithmus zur Verarbeitung eines Datenstroms ein. Die Erweiterung wartet nicht auf die Vollständigkeit eines Traces, sondern untersucht jeden Trace unmittelbar nach seinem Eintreffen. Sie verwendet Attribute wie http.request.method und http.response.status_code, um festzustellen, ob es sich bei der Operation um eine HTTP-Verbindung handelt. Andere Attribute weisen auf eine Datenbankabfrage oder eine Interaktion mit einem Nachrichtensystem hin.
Nach der Klassifizierung des Traces bestimmt der Algorithmus den Service, der ihn ausgegeben hat. Ist der Service neu, wird er zur Karte hinzugefügt. Ist er bereits vorhanden, werden die neuen Daten mit ihm zusammengeführt und seine Statistiken aktualisiert. Bei HTTP-Verbindungen sucht die Erweiterung nach der Beziehung zwischen dem vom aufrufenden Service ausgegebenen CLIENT-Span und dem im empfangenden Service erzeugten SERVER-Span. Der Trace-Kontext wird mit der Anfrage weitergegeben, wodurch der SERVER-Span zum Kind des CLIENT-Spans wird. Ist die andere Seite vorhanden, wird die Beziehung sofort gezeichnet. Andernfalls wird der Span im Speicher gehalten, bis die entsprechenden Daten eintreffen.
Für andere Abhängigkeiten gelten andere Regeln. Ein Datenbankaufruf wird üblicherweise durch einen einzelnen CLIENT-Span dargestellt, aus dem die Erweiterung anhand semantischer Attribute einen Datenbankknoten ableitet. Nachrichtensysteme erfordern dagegen mehr Flexibilität, weil die Beziehung zwischen Produzent und Konsument je nach Nachrichtensystem und verwendeter Instrumentierung über eine Eltern-Kind-Beziehung oder über Trace-Links sichtbar werden kann.
Warum ist das in der Praxis wichtig?
Der wichtigste Wert besteht darin, dass die Karte das beobachtete Verhalten und nicht nur die erwartete Architektur sichtbar macht. Wenn das System während der Entwicklung mehrere HTTP-Verbindungen oder Datenbankabfragen zeigt, obwohl eine Verbindung erwartet wurde, kann dies vor der Veröffentlichung erkannt werden. Die Karte hilft außerdem dabei, nicht dokumentierte oder im Laufe der Zeit veränderte Abhängigkeiten zu verstehen.
Die Genauigkeit des Ergebnisses bleibt jedoch an die Qualität der Telemetrie gebunden. Der Algorithmus benötigt korrekte Traces, die Weitergabe des Trace-Kontexts zwischen den Services und die Verwendung der erwarteten semantischen Attribute. Daher liefert die Service Map nicht allein durch die Installation der Erweiterung automatisch ein vollständiges Bild jedes Systems. Was die Instrumentierungswerkzeuge nicht senden oder was ohne Kontext eintrifft, erscheint möglicherweise nicht in den abgeleiteten Beziehungen. Der Artikel erklärt außerdem, dass sich das Modell mit dem Eintreffen neuer Belege weiterentwickelt. Die Karte ist damit eine fortlaufend aktualisierte Darstellung des Betriebs und kein endgültiges Urteil über den Architekturentwurf.