15 сентября 2026 года JetBrains опубликовала техническое объяснение принципа работы функции Service Map в плагине OpenTelemetry — функции, которая отображает фактические связи между микросервисами во время работы приложения в среде разработки. Материал подготовили Nikita Dukin и Egor Klimov в рамках сотрудничества между командами Rider Execution и Software Engineering Research.
Идея исходит из известной практической проблемы: схема архитектуры может выглядеть упорядоченной, но отражать состояние системы несколько месяцев назад и не показывать новый сервис или очередь сообщений, документация о которой не была обновлена. JetBrains считает, что одного статического анализа кода не всегда достаточно, поскольку он описывает то, что может произойти в исходном коде, а не то, что фактически происходит между сервисами во время работы.
Трассировки — источник карты
Плагин использует данные OpenTelemetry, которая собирает логи, метрики и трассировки. Если логи показывают, что произошло, а метрики — масштаб явления, то трассировки раскрывают путь запроса через систему. Каждая трассировка состоит из рабочих единиц, называемых spans, для которых OpenTelemetry предоставляет унифицированные семантические соглашения, например для трассировок HTTP Client и HTTP Server.
Плагин использует эти трассировки, чтобы понять рабочую структуру без привязки алгоритма к конкретному фреймворку или языку. Если приложения и библиотеки отправляют трассировки в соответствии с ожиданиями OpenTelemetry, функция может визуализировать соединения независимо от используемой технологии. JetBrains отмечает, что та же логика может работать с приложениями на JVM, .NET, Python, Go и других платформах, а также использоваться в IntelliJ IDEA, GoLand, PyCharm, WebStorm и Rider.
Как карта строится внутри среды разработки?
При запуске среды разработки с активированным плагином OpenTelemetry плагин запускает лёгкий локальный сервер, принимающий телеметрические данные. При запуске приложения плагин устанавливает стандартные переменные окружения OpenTelemetry, чтобы приложение отправляло трассировки на этот локальный сервер.
Сервер асинхронно обрабатывает поступающие трассировки, строит внутреннюю модель архитектуры и постоянно обновляет её. При открытии вкладки Service Map плагин получает последнюю структурную модель и отображает её в виде визуальной схемы. Таким образом, карта не является статичным документом, создаваемым вручную, а представляет собой непосредственный результат соединений, зафиксированных системой во время работы.
Проблема заключается не в рисовании, а в интерпретации данных
Трассировки поступают независимо друг от друга, и порядок их доставки не гарантируется. Трассировка дочернего сервиса может прийти раньше трассировки родительского сервиса, а сама трассировка не сообщает окончательный момент завершения, который гарантировал бы отсутствие запоздалой трассировки. Кроме того, OpenTelemetry не предоставляет отдельный строгий тип для каждой трассировки: трассировки содержат карту пар ключ-значение, описывающих семантику операции.
Поэтому JetBrains классифицировала восстановление структуры как алгоритм обработки потока данных. Плагин не ждёт завершения трассировки, а проверяет каждую трассировку сразу после её поступления. Он использует такие атрибуты, как http.request.method и http.response.status_code, чтобы определить, является ли операция HTTP-соединением, тогда как другие атрибуты указывают на запрос к базе данных или взаимодействие с системой обмена сообщениями.
После классификации трассировки алгоритм определяет сервис, который её создал. Если сервис новый, он добавляется на карту; если он уже существует, новые данные объединяются с ним, а его статистика обновляется. В HTTP-соединениях плагин ищет связь между трассировкой CLIENT, созданной вызывающим сервисом, и трассировкой SERVER, возникшей в принимающем сервисе. Контекст трассировки передаётся вместе с запросом, поэтому трассировка SERVER становится дочерней для трассировки CLIENT. Если другая сторона уже существует, связь рисуется сразу; если нет, трассировка сохраняется в памяти до поступления соответствующих данных.
Для других зависимостей используются иные правила. Обычно вызов базы данных представлен одной трассировкой CLIENT, на основании которой плагин выводит узел базы данных, используя семантические атрибуты. Системы обмена сообщениями требуют большей гибкости, поскольку связь между производителем и потребителем может проявляться через связь родителя и ребёнка или через ссылки на трассировки — в зависимости от системы обмена сообщениями и способа используемой инструментализации.
Почему это важно на практике?
Основная ценность заключается в том, что карта показывает наблюдаемое поведение, а не только ожидаемую структуру. Если во время разработки система показывает несколько HTTP-соединений или запросов к базе данных, хотя ожидалось одно соединение, это можно обнаружить до выпуска. Карта также помогает понять зависимости, которые не были задокументированы или изменились со временем.
Однако точность результата по-прежнему зависит от качества телеметрии. Алгоритму нужны корректные трассировки, передача контекста трассировки между сервисами и использование ожидаемых семантических атрибутов. Поэтому Service Map не предоставляет автоматически полную картину любой системы только потому, что плагин установлен: то, что инструменты измерения не отправляют или что поступает без контекста, может не появиться среди выведенных связей. В материале также объясняется, что модель развивается по мере поступления новых свидетельств, превращая карту в обновляемое рабочее представление, а не в окончательную оценку архитектурного дизайна.