OpenTelemetry: instrumentar una vez, elegir el backend libremente

Durante tres años, cada traza pasaba por el agente de un único proveedor: cómodo y caro. Luego llegó la factura, el equipo quiso cambiar a otro backend y se dio cuenta: cada span individual estaba pegada al SDK del fabricante. Quien quiere cambiar la observabilidad, tiene que reconstruirla desde cero. Exactamente este callejón sin salida es el que resuelve OpenTelemetry, separando la medición del análisis.

Lo más importante en resumen

Relacionado:OpenTofu vs. Terraform: qué herramienta IaC aguanta de verdad  /  Coolify a prueba: self-hosting en lugar de Vercel y Heroku

Por qué la factura de observabilidad acaba convirtiéndose en una toma de rehenes

El patrón se repite en casi todos los stacks que he visto por dentro en los últimos años. Al principio hay un agente. Se instala, unas pocas líneas de configuración, y de repente las trazas, las métricas y los logs aparecen en un bonito dashboard. El proveedor lo hace deliberadamente fácil, porque cada servicio instrumentado es un servicio que no abandonará su backend en mucho tiempo.

La fricción llega más tarde. El volumen de datos crece más rápido de lo previsto, la factura sigue al volumen y, en algún momento, surge la pregunta de si otra herramienta no sería más económica o simplemente mejor. Solo entonces se revela lo profundo que está el anzuelo. Los spans llevan los nombres de clase del SDK del proveedor, las métricas siguen su esquema de nomenclatura, la lógica de sampling está dentro de su agente. Un cambio no es un trabajo de configuración, sino una refactorización transversal a toda la base de código.

Esto no es un reproche a ningún fabricante en concreto. Es la consecuencia lógica de tener la medición y el análisis encapsulados en el mismo paquete propietario. OpenTelemetry traza exactamente aquí la línea divisoria.

Lo que hace OpenTelemetry cuando se prescinde de las diapositivas

¿Qué es OpenTelemetry? OpenTelemetry es un estándar abierto para generar y transportar datos de telemetría en sistemas distribuidos. Define interfaces y bibliotecas neutras respecto al proveedor para los tres tipos de señal estables -trazas, métricas y logs-, así como un protocolo unificado llamado OTLP a través del cual estos datos se envían a cualquier backend.

El núcleo práctico es ese desacoplamiento. La instrumentación vive en el código y en el estándar, no en el agente de un proveedor. Un span recibe el nombre que el equipo le asigna, no el que impone un SDK. El destino final de los datos lo decide una línea de configuración, no una intervención en el código.

El proyecto nació de la fusión de dos enfoques anteriores, OpenTracing y OpenCensus, que durante años resolvieron en paralelo el mismo problema. Hoy, OpenTelemetry es un proyecto graduado de la Cloud Native Computing Foundation y el segundo con mayor actividad allí, solo por detrás de Kubernetes. Incluso los proveedores comerciales cuyo lock-in rompe el estándar aceptan ya OTLP de forma nativa. La instrumentación neutra respecto al proveedor se ha convertido así en la norma.

Auto o manual: dónde encuentra sus límites el arranque rápido

Existen dos formas de entrar en OpenTelemetry, y ambas tienen su razón de ser. La instrumentación automática se conecta mediante un agente o una biblioteca a los frameworks y drivers más habituales, y proporciona trazas para llamadas HTTP, accesos a bases de datos y colas de mensajes sin modificar el código. Este es el camino con el que se obtiene una primera imagen de trazas en una pausa del mediodía.

La instrumentación manual requiere más trabajo, pero proporciona el contexto que realmente importa. Una llamada como tracer.start_as_current_span(…) marca exactamente la operación de negocio que interesa en un incidente: el checkout, la comprobación de riesgo, el proceso por lotes. La instrumentación automática dice que la base de datos era lenta. La manual dice que la base de datos era lenta durante el tercer reintento de una autorización de pago. Esa es la diferencia entre un número y una explicación.

En la práctica se combinan ambos enfoques. La instrumentación automática como ruido de fondo, y los spans manuales allí donde haya dinero, riesgo o frustración del cliente en juego. Si se construye todo manualmente, nunca se termina. Si se deja todo en manos del agente, al final se tienen muchos datos y pocas respuestas.

El Collector es la pieza que la mayoría subestima

Las bibliotecas acaparan la atención, pero el OpenTelemetry Collector hace el trabajo real. Es un proceso independiente que recibe la telemetría de los servicios, la procesa y la reenvía a uno o varios backends. Precisamente este componente convierte la teoría de la intercambiabilidad en una realidad operativa, porque el enrutamiento de datos ocurre aquí, no en el código de la aplicación.

Esta configuración concisa ilustra el principio. Un receiver recibe OTLP, un procesador de lotes agrupa los datos, y dos pipelines independientes envían trazas y métricas a destinos distintos. Si el equipo quiere cambiar el backend de trazas mañana, se modifica exactamente una línea del exporter; ningún servicio necesita volver a desplegarse.

La fricción se esconde en el sampling. Con volúmenes moderados se puede conservar todo, pero con tráfico serio eso se vuelve caro y difícil de gestionar rápidamente. El tail-based sampling, es decir, la decisión tomada una vez completada la traza, retiene selectivamente las operaciones lentas y las erróneas, y descarta el caso de éxito uniforme. Es una técnica potente, pero consume memoria en el Collector y requiere varias iteraciones hasta que las reglas funcionan bien. Yo mismo he tardado demasiadas veces en tomarlo en serio.

Lo que aporta el cambio, y dónde no resuelve nada

La ventaja concreta de OpenTelemetry es la libertad de elección. La instrumentación se convierte en una inversión duradera en lugar de una apuesta por un proveedor concreto. Los backends pueden compararse, combinarse o sustituirse sin tener que tocar el código cada vez. Para los equipos que luchan con los costes de telemetría o con la dependencia de una herramienta, este es el factor decisivo.

OpenTelemetry no es un producto de observabilidad listo para usar. El estándar genera y transporta datos, pero no los almacena, visualiza ni genera alertas. El backend sigue siendo una decisión propia con sus propios costes, ya sea autoalojado con Grafana y Prometheus o como servicio contratado. Y el Collector es infraestructura que alguien debe operar, escalar y monitorizar. Observabilidad que también quiere ser observada.

Para un equipo pequeño con un monolito manejable y una herramienta que funciona, la migración inmediata no tiene sentido por sí misma. OpenTelemetry resulta realmente rentable cuando coinciden varios servicios, varios lenguajes o una frustración seria con los costes y el lock-in. En ese momento la pregunta ya no es si se hace el cambio, sino únicamente cuánto tardará en agotarse la instrumentación antigua.

Preguntas frecuentes

Fuente de la imagen: Rashed Paykary / Pexels