OpenTelemetry OTel Trazas Observabilidad
La instrumentación con OpenTelemetry unifica trazas, métricas y logs bajo un único estándar abierto y elimina la dependencia de agentes propietarios que encarece los costes cada vez que se cambia de backend. Instrumentamos servicios escritos en Go, Java, Python, Node.js y .NET con SDK de OTel, configuramos el pipeline del Collector para el enmascaramiento de PII y el muestreo tail-based, y exportamos las señales a cualquier backend (Prometheus, Tempo, Jaeger o Datadog) para clientes de EE. UU. y la UE en sectores regulados.
La instrumentación con OpenTelemetry unifica trazas, métricas y logs bajo un único estándar abierto y elimina la dependencia de agentes propietarios que encarece los costes cada vez que se cambia de backend. Instrumentamos servicios escritos en Go, Java, Python, Node.js y .NET con SDK de OTel, configuramos el pipeline del Collector para el enmascaramiento de PII y el muestreo tail-based, y exportamos las señales a cualquier backend (Prometheus, Tempo, Jaeger o Datadog) para clientes de EE. UU. y la UE en sectores regulados.
Retos
Los desarrolladores instrumentan spans con parámetros de solicitud, ID de usuario o campos de la carga útil sin darse cuenta de que esos valores contienen datos personales regulados. Una vez en el backend, la PII es difícil de purgar y puede infringir los requisitos de tratamiento de datos del RGPD o de HIPAA.
Instrumentar sin criterio cada llamada a función o crear spans de alta cardinalidad (etiquetas por usuario o por ID de solicitud) infla el uso de memoria, CPU y red. Un muestreo mal ajustado deja pasar el 100 % de las trazas y satura el Collector y el almacenamiento del backend.
El muestreo head-based decide al inicio de la traza si se registra, así que pierde las rutas de error raras pero importantes. El muestreo tail-based almacena en buffer la traza completa antes de decidir, lo que añade latencia y presión de memoria en el Collector. Elegir mal la estrategia deja sin trazas críticas o dispara los costes de almacenamiento.
Una cabecera W3C TraceContext ausente o corrupta rompe la traza en la primera frontera entre servicios y produce spans desconectados que no se pueden correlacionar. Los stacks políglotas (gateway en Go, servicio en Java, worker de ML en Python) requieren cada uno una configuración de propagación específica del lenguaje.
Los agentes propietarios (agente de Datadog, New Relic APM) incrustan APIs específicas del proveedor en el código de la aplicación. Cambiar de backend exige cambios en el código, y el propio binario del agente puede introducir complejidad de licencias, seguridad y gestión de dependencias.
El Collector admite receivers, processors y exporters en pipelines componibles, pero un orden de processors mal configurado (por ejemplo, agrupar antes de filtrar) causa pérdida de datos o un uso excesivo de memoria. El fan-out a varios backends y el enrutamiento por entorno añaden más superficie de configuración.
Soluciones
Instrumentamos los servicios con los SDK oficiales de OTel y agentes de autoinstrumentación, emitiendo trazas, métricas y logs en formato OTLP sin ninguna API propietaria en el código de la aplicación: los backends se pueden intercambiar sin cambiar el código.
Diseñamos pipelines del OTel Collector con reglas del attribute processor que enmascaran, aplican hash o descartan los campos regulados antes de exportar, de modo que la telemetría esté limpia para el RGPD y los requisitos de datos regulados en todos los backends posteriores.
Configuramos en el Collector políticas de muestreo tail-based que registran el 100 % de las trazas con errores o lentas y reducen el muestreo del tráfico rutinario: se captura cada anomalía sin desbordar los presupuestos de almacenamiento.
La autoinstrumentación cubre de serie los frameworks (HTTP, gRPC, bases de datos, mensajería); añadimos spans manuales selectivos en las rutas de código críticas para el negocio (flujos de pago, llamadas de inferencia de ML, eventos regulatorios) donde el trazado a nivel de framework no basta.
Configuramos la propagación de W3C TraceContext y Baggage en cada runtime de lenguaje, probamos la propagación de extremo a extremo en el pipeline de CI y validamos la continuidad de las trazas entre fronteras de servicio con escenarios de prueba distribuidos sintéticos.
Los exporters OTLP del Collector distribuyen las señales a uno o varios backends a la vez. Los clientes pueden ejecutar Jaeger o Tempo on-premise para los datos regulados y replicar las métricas no sensibles en Datadog, sin cambiar la instrumentación.
Stack
SDK de OpenTelemetry (Go, Java, Python, Node.js, .NET), OTel Collector, OTLP, agentes de autoinstrumentación, instrumentación manual de spans, propagación de contexto (W3C TraceContext / Baggage), convenciones semánticas, exporters (Prometheus, Grafana Tempo, Jaeger, Datadog, OTLP/gRPC), muestreo tail-based, processors del Collector (enmascaramiento de PII, filtrado de atributos, batch), políticas de muestreo.
Cumplimiento
PII fuera de la telemetría · exportación neutral respecto al proveedor · traza de auditoría · observabilidad de extremo a extremo para NIS2
Casos
Refactorización y reconstrucción en Android e iOS para un operador alemán de logística de última milla: planificación de rutas multipunto, seguimiento de conductores en tiempo real y facturación en la app, en producción en la UE.
Plataforma social en producción, en App Store y Google Play, activa en EE. UU. y la UE, con Radar geolocalizado, mensajería cifrada y economía virtual.
Plataforma de transporte con conductor con tres apps (conductor, pasajero y despachador), con GPS en tiempo real, verificación de documentos y doble método de pago en efectivo y con tarjeta.
Por qué YuSMP
Cada span y cada métrica se emite mediante la API abierta de OTel. Pasar de Datadog a Grafana Tempo o añadir un segundo backend es un cambio de configuración del Collector, no un sprint de refactorización en decenas de servicios.
El diseño de nuestro pipeline del Collector trata el enmascaramiento de PII como una prioridad de primer orden, no como un añadido posterior. Los campos regulados se eliminan o se les aplica hash antes de que cualquier señal llegue a un backend externo, de modo que su telemetría sea conforme con el RGPD y marcos similares.
Instrumentamos los tres tipos de señal y configuramos exemplars que enlazan las métricas de Prometheus con las trazas subyacentes, de modo que los ingenieros saltan de un pico de latencia en un dashboard directamente a la traza responsable, sin cambiar de contexto.
Preguntas frecuentes
OpenTelemetry es un proyecto de la CNCF que define una API, un SDK y un protocolo de red (OTLP) neutrales respecto al proveedor para trazas, métricas y logs. A diferencia de los agentes propietarios (Datadog APM, New Relic, Dynatrace), no incrusta código específico de ningún proveedor en su aplicación. Se instrumenta una sola vez con la API abierta de OTel y se enrutan las señales a cualquier backend compatible mediante el Collector. Cambiar de backend solo requiere configurar los exporters del Collector, no cambiar el código de la aplicación.
Las trazas registran el recorrido de extremo a extremo de una solicitud a través de los servicios: cada operación es un span con su duración, sus atributos y su estado. Las métricas son agregaciones numéricas en el tiempo (tasa de solicitudes, tasa de errores, percentiles de latencia) adecuadas para dashboards y alertas. Los logs son texto con marca de tiempo o eventos estructurados de componentes individuales. OTel unifica los tres bajo un mismo SDK y protocolo de red, y los exemplars enlazan los puntos de datos de las métricas directamente con las trazas que los generaron.
OTel en sí no enmascara la PII: es responsabilidad del pipeline. Configuramos el attribute processor y el transform processor del OTel Collector para eliminar, aplicar hash o enmascarar los atributos de spans y los campos de logs que puedan contener datos regulados (correos, ID de usuario, números de tarjeta, números de la seguridad social de EE. UU.) antes de que las señales lleguen a cualquier backend. Así la telemetría se mantiene conforme con el RGPD y marcos similares sin cambios de instrumentación en la aplicación.
El muestreo head-based decide al inicio de la traza si se registra: es rápido y eficiente en memoria, pero descarta las trazas de error raras con la misma probabilidad que las rutinarias. El muestreo tail-based almacena en buffer la traza completa en el Collector antes de decidir, lo que permite políticas como «conservar siempre las trazas con errores o con latencia superior a 1 s». Configuramos el muestreo tail-based en los sistemas de producción donde perder trazas de error cuesta más que la memoria y la CPU adicionales del Collector.
El OTel Collector es un agente independiente del proveedor que recibe OTLP (u otros formatos), procesa las señales (agrupación, filtrado, transformación de atributos, enmascaramiento de PII, muestreo tail-based) y las exporta a uno o varios backends a la vez. Se puede exportar directamente desde los SDK a un backend, pero el Collector desacopla la instrumentación de la elección del backend, centraliza el tratamiento de los datos sensibles (enmascaramiento de PII) y permite el fan-out a varios backends sin cambios en la aplicación. Lo recomendamos en cualquier despliegue de producción.
La sobrecarga depende de la tasa de muestreo y de la cardinalidad. Con muestreo head-based al 10 % y atributos de spans bien ajustados (sin etiquetas de alta cardinalidad como el ID de usuario por span), la sobrecarga de CPU suele ser inferior al 2 % y el impacto en memoria es mínimo. Los agentes de autoinstrumentación añaden coste de carga de bibliotecas en el arranque. El muestreo tail-based en el Collector añade memoria proporcional a la ventana del buffer. Perfilamos los servicios instrumentados antes y después del despliegue y ajustamos las políticas de muestreo para mantener la sobrecarga dentro de los SLO acordados.
La migración es incremental. Empezamos ejecutando el OTel Collector junto al agente existente y enrutando un flujo OTLP duplicado a un backend de prueba compatible con OTel mientras el agente propietario sigue en producción. Una vez confirmada la paridad de señales (cobertura de trazas, cardinalidad de métricas, fidelidad de las alertas), retiramos la autoinstrumentación del agente propietario y dejamos solo los SDK de OTel en la aplicación. El Collector puede seguir exportando a Datadog mediante su exporter OTLP si Datadog se mantiene como backend, de modo que no hay un cutover brusco.
Respuesta en 1 día hábil. NDA a petición.
Cuéntenos algunos detalles y un consultor sénior le responderá en un día hábil.