OpenTelemetry ha ganado la guerra de la observabilidad — ¿y ahora qué?

El problema del lock-in está resuelto

Durante la mayor parte de la década de 2010, elegir un vendor de observabilidad significaba casarse con su biblioteca de instrumentación. Los agents de Datadog, los SDK de New Relic, las beelines propietarias de Honeycomb — cada uno bloqueaba tu código de aplicación a un backend específico. Cambiar de vendor implicaba reinstrumentar cada servicio. Esa era ha terminado.

OpenTelemetry es ahora el estándar de facto para trazado distribuido, métricas y logs. AWS, GCP, Azure, Datadog, Honeycomb, Grafana, New Relic, Dynatrace y todas las plataformas importantes de observabilidad lo soportan de forma nativa. Instrumentas una vez. Enrutas a cualquier lugar.

Qué es realmente OpenTelemetry

OpenTelemetry es un proyecto de la CNCF — graduado en 2021 — nacido de la fusión de dos estándares competidores: OpenCensus (Google) y OpenTracing (CNCF). Esa fusión importa porque acabó con la fragmentación. Antes de OpenTelemetry, tenías que elegir bando; ahora solo hay un estándar.

El proyecto define tres señales de observabilidad:

• Traces: Flujos de peticiones distribuidas a través de los límites del servicio, representados como un árbol de spans con tiempos y atributos.
• Metrics: Mediciones numéricas agregadas — counters, gauges, histogramas — para dashboards y alertas.
• Logs: Registros de eventos estructurados que pueden correlacionarse con traces y métricas mediante contexto compartido (trace IDs, span IDs).

La arquitectura tiene dos componentes principales: el SDK (incrustado en tu aplicación) y el Collector (un binario independiente que recibe, procesa y exporta telemetría). Entender la separación entre ambos es la clave que la mayoría de equipos pasan por alto.

La especificación vs. el SDK: por qué importa la separación

OpenTelemetry define una API specification separada de la implementación del SDK. Esto es deliberado. Los autores de librerías pueden instrumentar su código contra la API sin depender rígidamente de ningún SDK concreto. Cuando tu aplicación se ejecuta sin un SDK configurado, esas llamadas a la API se convierten en no-ops. Cero overhead.

Cuando sí configuras un SDK, este se conecta a la API y comienza a exportar. El SDK gestiona batch, lógica de reintento, sampling y propagación de contexto. La especificación define el contrato; el SDK proporciona la implementación. Esta arquitectura es la razón por la que OpenTelemetry puede afirmar una instrumentación sin overhead para despliegues no instrumentados — una afirmación que importa a los autores de librerías que distribuyen a una amplia base de usuarios.

La implicación práctica: instrumenta tus librerías contra la API de OTel. Instrumenta tus aplicaciones contra el SDK. Nunca permitas que una librería tome una dependencia rígida del SDK.

Auto-instrumentación vs. spans manuales

OpenTelemetry proporciona auto-instrumentación específica para cada lenguaje que parchea frameworks y librerías populares sin cambios de código:

• Java: Un Java agent (-javaagent:opentelemetry-javaagent.jar) que instrumenta Spring, Tomcat, gRPC, JDBC y docenas de otras librerías mediante manipulación de bytecode al arrancar.
• Python: opentelemetry-instrument python app.py — instrumenta Django, Flask, FastAPI, SQLAlchemy, clientes Redis y más de forma automática.
• Node.js: Requiere el paquete @opentelemetry/auto-instrumentations-node y se engancha a Express, HTTP, gRPC, MySQL, Postgres y otros mediante parcheo de módulos.

La auto-instrumentación te da visibilidad a nivel de infraestructura de inmediato. Verás duraciones de peticiones HTTP, latencia de consultas a bases de datos, llamadas a API externas — toda la plomería mecánica — sin tocar código de aplicación.

Pero la auto-instrumentación no sabe lo que significa tu código. No puede decirte que el servicio de checkout es lento debido a una regla concreta de validación de códigos promocionales. Para visibilidad de lógica de negocio, necesitas manual spans:

• Envuelve cualquier operación que pueda fallar o sea sensible a latencia en un span personalizado.
• Añade atributos semánticos: user ID, order ID, variante de experimento, valores de feature flags.
• Registra excepciones explícitamente con span.recordException(err) y span.setStatus({code: ERROR}).

El enfoque correcto: usa auto-instrumentación como línea base, añade spans manuales en cada punto de decisión que importe a tu negocio. Empieza con auto, añade manual de forma incremental según aprendas qué preguntas no puedes responder.

El Collector es el eje arquitectónico

La mayoría de equipos empiezan enviando telemetría directamente desde el SDK de su aplicación a un backend. Esto funciona pero renuncia a la característica más valiosa de la arquitectura OTel: el pipeline del Collector.

El OTel Collector es un proxy agnóstico de vendor que se sitúa entre tus aplicaciones y tus backends. Configúralo con receivers (OTLP, Jaeger, Prometheus, Zipkin), processors (sampling, manipulación de atributos, sanitización de PII) y exporters (Datadog, Honeycomb, Tempo, CloudWatch — cualquier combinación).

Por qué esto importa en la práctica:

• Fan-out: Envía traces a Honeycomb para exploración Y a Grafana Tempo para retención a largo plazo simultáneamente. Sin necesidad de cambios en la aplicación.
• Sanitización de PII: Elimina o hashea atributos sensibles (direcciones de email, IPs, tokens de sesión) antes de que salgan de tu perímetro de red — antes de que ningún dato llegue a un vendor.
• Decisiones de sampling: Aplica tail-based sampling a nivel del Collector, conservando errores y traces lentos, descartando los rápidos y sanos.
• Migración de backend: Cambia de Datadog a Grafana modificando un archivo de configuración del Collector. Tu instrumentación de aplicación queda intacta.

Despliega el Collector como sidecar en Kubernetes o como DaemonSet. Para entornos de alto tráfico, despliega una arquitectura en capas: Collectors sidecar por pod que reenvíen a Collectors gateway que manejan tail sampling sobre toda la población de peticiones.

Estrategias de sampling: head-based vs. tail-based

Trazar cada petición con fidelidad completa es caro. A 10.000 peticiones por segundo, almacenar cada trace cuesta dinero real. El sampling no es opcional a escala — pero la estrategia de sampling determina qué puedes realmente depurar.

Head-based sampling toma la decisión de mantener/descartar al inicio de una petición, antes de que se creen spans descendentes. Es simple de implementar y tiene overhead mínimo. El problema: no puedes samplear basándote en resultados que aún no conoces. Podrías descartar la única petición que falló. Con un sampling head del 1%, rutinariamente no tendrás trace para tus bugs más interesantes.

Tail-based sampling almacena en buffer todos los spans de un trace y toma la decisión solo después de que el trace completo esté terminado. Esto te permite:

• Mantener el 100% de los traces que contengan algún span de error.
• Mantener el 100% de los traces que excedan un umbral de latencia (ej. P99 > 2 segundos).
• Mantener un porcentaje configurable de traces rápidos y sanos (ej. 1% de línea base).

El processor tailsampling del OTel Collector implementa esto. Configura políticas en YAML: combina políticas de estado de error con políticas de latencia y una línea base probabilística. El resultado es un corpus de traces compuesto desproporcionadamente por los casos interesantes que realmente quieres depurar.

El coste operacional: el tail-based sampling requiere almacenar en buffer los spans en vuelo en la memoria del Collector. Para decisiones significativas, necesitas que todos los spans de un trace dado lleguen a la misma instancia del Collector — típicamente mediante balanceo de carga basado en trace ID frente a un pool de Collectors. Esto es más infraestructura que operar, pero la mejora en depurabilidad no es marginal. Es la diferencia entre ver cada error y no ver ninguno.

Estado actual de las tres señales

Las señales de OpenTelemetry han madurado a ritmos diferentes:

• Traces: GA y estable desde 2021. La señal más madura. Las semantic conventions para HTTP, gRPC, bases de datos, sistemas de mensajería están bien establecidas y son estables. Úsala primero.
• Metrics: GA y estable desde 2022. El protocolo OTLP para métricas está listo para producción. Las semantic conventions cubren métricas de servidor y cliente HTTP, métricas de runtime (JVM, Python runtime) y métricas de sistema.
• Logs: Estable desde 2023. El modelo de datos de logs y el protocolo OTLP para logs permiten que los logs estructurados lleven contexto de trace (trace ID, span ID), posibilitando la correlación entre logs y traces en backends que lo soporten. Grafana Loki + Tempo es la implementación más madura hoy.

Las semantic conventions son lo que hace que la correlación entre señales funcione realmente. Cuando tu span HTTP y tu métrica HTTP usan los mismos nombres de atributo (http.request.method, http.response.status_code, server.address), los backends pueden unirlos. Adhiérete a las semantic conventions publicadas — no inventes tus propios nombres de atributo para operaciones estándar.

Panorama de vendors en 2026

Con la instrumentación ahora neutral respecto al vendor, la elección de backend se basa en modelo de consulta, coste y preferencia operativa:

• Honeycomb: El producto más opinado y probablemente el mejor para exploración de traces. BubbleUp para descubrimiento automático de correlaciones, soporte para columnas de alta cardinalidad y un modelo de consulta construido alrededor de eventos de ancho arbitrario. Mejor para equipos que quieren hacer análisis sofisticados de traces y están dispuestos a pagar por un producto gestionado.
• Stack Grafana (LGTM): Loki (logs) + Grafana (dashboards) + Tempo (traces) + Mimir (métricas). Completamente open source, auto-alojable o disponible gestionado via Grafana Cloud. El stack LGTM es la opción adecuada para equipos que quieren ser dueños de su infraestructura y evitar completamente el vendor lock-in. Las correlaciones trace-to-logs y trace-to-metrics de Tempo funcionan bien cuando todo usa las semantic conventions de OTel.
• Datadog: Excelente soporte de ingesta OTel a través del agent de Datadog (que habla OTLP). Mejor para equipos que ya están en Datadog para APM y monitorización de infraestructura y quieren estandarizar en instrumentación OTel manteniendo la UI y alertas de Datadog. El coste escala de forma pronunciada con el volumen de datos.
• AWS CloudWatch: AWS Distro for OpenTelemetry (ADOT) proporciona Collectors OTel gestionados por AWS y una integración profunda con CloudWatch, X-Ray y Amazon Managed Grafana. Opción práctica para equipos principalmente en AWS que quieren minimizar la superficie operativa. La visualización de traces de X-Ray es funcional pero no tan expresiva como Honeycomb o Tempo.

Qué sigue siendo difícil

OpenTelemetry no lo ha resuelto todo. Sé honesto sobre lo que aún es áspero:

• Señal de profiling: La especificación de profiling (profiling continuo de CPU y memoria correlacionado con traces) está en desarrollo pero aún no estable a mediados de 2026. Se espera que llegue a GA en 2026 o 2027. Hasta entonces, el profiling sigue siendo específico del vendor.
• Correlación de métricas de negocio: Conectar una consulta lenta a base de datos con el impacto en ingresos requiere unir datos de observabilidad con datos de eventos de negocio. OpenTelemetry no define cómo hacer esto. Necesitas añadir atributos de negocio a tus spans (valor del pedido, nivel de usuario, ruta generadora de ingresos) y construir el análisis tú mismo en tu backend.
• Complejidad de configuración del Collector: Una configuración de Collector OTel en producción con tail sampling, múltiples exporters, sanitización de PII y transformaciones de atributos puede convertirse en cientos de líneas de YAML. El Collector tiene un modelo de pipeline extenso, pero la curva de aprendizaje para configuraciones complejas es real. Usa el OTel Collector Builder y prueba configuraciones localmente con el exporter file antes de desplegar.

Cómo empezar: instrumenta un servicio en 5 pasos

Para un servicio Node.js (mismo patrón aplica a Python con paquetes equivalentes):

• Paso 1 — Instalar paquetes: npm install @opentelemetry/sdk-node @opentelemetry/auto-instrumentations-node @opentelemetry/exporter-otlp-http
• Paso 2 — Crear un archivo de instrumentación (tracing.js): Inicializa el NodeSDK con el nombre de tu servicio, el plugin de auto-instrumentaciones y un exporter OTLP HTTP apuntando al endpoint de tu Collector o directamente a la URL de ingesta OTLP de un vendor.
• Paso 3 — Iniciar el SDK antes que tu app: En tu punto de entrada, llama a sdk.start() antes de requerir cualquier otro módulo. Para Node.js, usa --require ./tracing.js en tu comando de arranque.
• Paso 4 — Añadir spans manuales para lógica de negocio: Envuelve checkout, procesamiento de pagos, consultas de recomendación — cualquier cosa con significado de negocio — en spans personalizados. Añade atributos para order ID, segmento de usuario y flags de experimento.
• Paso 5 — Desplegar un sidecar Collector: Ejecuta el OTel Collector junto a tu servicio, configurado para recibir OTLP en localhost:4318 y exportar a tu backend elegido. Esto desacopla la configuración del backend del despliegue de la aplicación.

Marco de decisión accionable

Así es como tomar las decisiones clave sin sobrepensarlas:

• Prioridad de señales: Implementa traces primero, luego métricas, luego logs. Los traces te dan el mayor apalancamiento de depuración por unidad de esfuerzo de instrumentación. Los logs son valiosos pero probablemente ya los tienes — enfócate en conectarlos a los traces mediante la inyección de contexto de trace.
• Selección de backend: Si te auto-alojas, usa el stack LGTM de Grafana. Si quieres algo gestionado con excelente UX para análisis de traces, usa Honeycomb. Si ya estás en Datadog para monitorización de infraestructura, estandariza en instrumentación OTel y mantén Datadog como backend. No optimices la elección de backend demasiado pronto — el punto de OTel es que puedes cambiar de opinión.
• Collector desde el día uno: Incluso si solo tienes un backend hoy, despliega el Collector. El coste es mínimo; la recompensa en flexibilidad cuando añadas un segundo backend o necesites cambiar de vendor es significativa.
• Política de sampling: Empieza con head-based sampling al 10–20% si necesitas controlar costes inmediatamente. Planifica migrar a tail-based sampling una vez que tengas un pool de Collectors — la mejora en visibilidad de errores vale la complejidad operativa.
• Semantic conventions: Impón su cumplimiento. Añade un paso de lint o un chequeo en CI que valide los nombres de tus atributos personalizados de span contra el registro de semantic conventions de OTel. Consistencia ahora significa correlación entre señales después, y significa que cualquier nuevo backend que adoptes entenderá tus datos sin transformación.

Las guerras de vendors de observabilidad han terminado. El problema de instrumentación está resuelto. Lo que queda es la disciplina operativa de desplegarlo correctamente, configurar tu pipeline para coste y fidelidad, y construir los hábitos organizativos alrededor de la depuración guiada por traces. Esos hábitos — ir a traces primero cuando algo es lento, anotar los despliegues como atributos de trace, escribir runbooks que referencien atributos específicos de span — son lo que separa a los equipos que obtienen valor de la observabilidad de los equipos que solo tienen dashboards.