El 15 de septiembre de 2026, JetBrains publicó una explicación técnica sobre el funcionamiento de la funcionalidad Service Map de la extensión OpenTelemetry, que representa las relaciones reales entre microservicios mientras la aplicación se ejecuta dentro del entorno de desarrollo. La explicación fue elaborada por Nikita Dukin y Egor Klimov, como parte de una colaboración entre el equipo Rider Execution y el equipo Software Engineering Research.
La idea parte de un problema práctico conocido: el diagrama de la arquitectura puede parecer ordenado, pero quizá refleje el estado del sistema de hace meses y no muestre un servicio nuevo o una cola de mensajes cuya documentación no se haya actualizado. JetBrains considera que el análisis estático del código no siempre es suficiente, porque describe lo que podría ocurrir en el código fuente, no lo que sucede realmente entre los servicios durante la ejecución.
Las trazas son la fuente del mapa
La extensión utiliza datos de OpenTelemetry, que recopilan registros, métricas y trazas. Mientras que los registros explican qué ocurrió y las métricas muestran la magnitud del fenómeno, las trazas revelan el recorrido de una solicitud por el sistema. Cada seguimiento está compuesto por unidades de trabajo denominadas spans, para las que OpenTelemetry proporciona convenciones semánticas uniformes, como las trazas HTTP Client y HTTP Server.
La extensión utiliza estas trazas para comprender la arquitectura operativa sin vincular el algoritmo a un framework o lenguaje concreto. Si las aplicaciones y bibliotecas envían trazas conforme a las expectativas de OpenTelemetry, la funcionalidad puede representar las comunicaciones independientemente de la tecnología utilizada. JetBrains señala que la misma lógica puede funcionar con aplicaciones JVM, .NET, Python, Go y otras, y que también puede utilizarse en IntelliJ IDEA, GoLand, PyCharm, WebStorm y Rider.
¿Cómo se construye el mapa dentro del entorno de desarrollo?
Cuando se ejecuta el entorno de desarrollo con la extensión OpenTelemetry activada, la extensión inicia un servidor local ligero que recibe datos de telemetría. Al ejecutar la aplicación, la extensión configura las variables de entorno estándar de OpenTelemetry para que la aplicación envíe sus trazas a ese servidor local.
El servidor procesa las trazas entrantes de forma asíncrona, construye un modelo interno de la arquitectura y lo actualiza continuamente. Al abrir la pestaña Service Map, la extensión recupera el modelo estructural más reciente y lo muestra en forma de diagrama visual. De este modo, el mapa no es un documento estático creado manualmente, sino el resultado directo de las comunicaciones observadas por el sistema durante su ejecución.
El reto no es dibujar, sino interpretar los datos
Las trazas llegan de forma independiente y no existe ninguna garantía sobre el orden en que se reciben. Una traza del servicio hijo puede llegar antes que la del servicio padre, y el seguimiento no anuncia un momento de finalización definitivo que garantice que no llegará una traza retrasada. Además, OpenTelemetry no proporciona un tipo estricto separado para cada traza; las trazas contienen un mapa de pares clave-valor que describe la semántica de la operación.
Por ello, JetBrains clasificó la reconstrucción de la arquitectura como un algoritmo de procesamiento de flujos de datos. La extensión no espera a que el seguimiento se complete, sino que examina cada traza en cuanto llega. Utiliza atributos como http.request.method y http.response.status_code para determinar si la operación es una comunicación HTTP, mientras que otros atributos indican una consulta a una base de datos o una interacción con un sistema de mensajería.
Después de clasificar la traza, el algoritmo determina qué servicio la emitió. Si el servicio es nuevo, se añade al mapa; si ya existe, los nuevos datos se integran con él y sus estadísticas se actualizan. En las comunicaciones HTTP, la extensión busca la relación entre la traza CLIENT emitida por el servicio que realiza la llamada y la traza SERVER generada en el servicio receptor. El contexto del seguimiento viaja con la solicitud, lo que convierte la traza SERVER en hija de la traza CLIENT. Si el otro extremo ya existe, la relación se dibuja de inmediato; si no existe, la traza se conserva en memoria hasta que lleguen los datos correspondientes.
Las demás dependencias utilizan reglas diferentes. Normalmente, una llamada a una base de datos está representada por una única traza CLIENT, a partir de la cual la extensión deduce el nodo de la base de datos basándose en los atributos semánticos. Los sistemas de mensajería requieren más flexibilidad, porque la relación entre productor y consumidor puede aparecer mediante una relación padre-hijo o a través de enlaces entre trazas, según el sistema de mensajería y el método de instrumentación utilizado.
¿Por qué es importante en la práctica?
El valor principal reside en que el mapa revela el comportamiento observado, no solo la arquitectura esperada. Si durante el desarrollo el sistema muestra varias comunicaciones HTTP o consultas a una base de datos cuando se esperaba una sola, esto puede detectarse antes del lanzamiento. El mapa también ayuda a comprender dependencias que no se documentaron o que cambiaron con el tiempo.
Sin embargo, la precisión del resultado sigue vinculada a la calidad de la telemetría. El algoritmo necesita trazas correctas, la propagación del contexto de seguimiento entre servicios y el uso de los atributos semánticos esperados. Por tanto, Service Map no ofrece automáticamente una imagen completa de cualquier sistema por el mero hecho de instalar la extensión; aquello que las herramientas de instrumentación no envían o que llega sin contexto puede no aparecer en las relaciones inferidas. El artículo también explica que el modelo evoluciona a medida que llegan nuevas evidencias, lo que convierte el mapa en una representación operativa actualizada, no en un juicio definitivo sobre el diseño arquitectónico.