Mapa de lecturaDe la señal a una decisión operativa
  1. 01Entender
  2. 02Priorizar
  3. 03Actuar

OpenTelemetry se convirtió en el estándar abierto para generar y mover telemetría, pero instalar un agente no crea observabilidad por sí solo. Una implementación sin convenciones, filtros ni presupuesto puede producir spans imposibles de buscar y una factura que crece con cada request.

Esta guía resume cómo llevar OpenTelemetry a producción con una arquitectura controlable.

Qué resuelve OpenTelemetry

OpenTelemetry —OTel— ofrece APIs, SDKs, instrumentación, protocolo y Collector para trabajar con trazas, métricas y logs. Es neutral respecto del backend: puede exportar hacia Grafana, Datadog, Dynatrace, New Relic, Jaeger, Prometheus u otros destinos.

No almacena telemetría ni reemplaza la experiencia de análisis. Su función es desacoplar el modo en que las aplicaciones producen datos del lugar donde se consultan.

En mayo de 2026 OpenTelemetry alcanzó el nivel Graduated de CNCF. La encuesta anual 2025 de CNCF reportó 49 % de uso en producción y 26 % de organizaciones evaluándolo, una señal de estandarización relevante para decisiones de arquitectura.

Arquitectura recomendada

Aplicaciones → OTLP → Collector gateway → backend(s)
                    ↳ filtros
                    ↳ redacción
                    ↳ muestreo
                    ↳ enriquecimiento

Los SDKs generan telemetría y la envían mediante OTLP. El Collector recibe, procesa y exporta. En entornos grandes puede combinarse un Collector agente cerca del workload con gateways centralizados.

Paso 1: definir el caso de uso

Antes de instrumentar, elegí una pregunta concreta:

  • ¿Por qué el checkout supera su SLO?
  • ¿Qué dependencia genera errores intermitentes?
  • ¿Qué versión introdujo una regresión?
  • ¿Qué transacciones fallan sólo en una región?

El caso de uso determina los servicios, atributos y nivel de muestreo. “Capturar todo para verlo después” no es una estrategia.

Paso 2: normalizar recursos

Cada señal debe identificar consistentemente:

  • service.name
  • service.namespace
  • service.version
  • deployment.environment.name
  • región, clúster o tenant cuando corresponda
  • propietario del servicio mediante un atributo o catálogo asociado

Si producción aparece como prod, production y prd, las consultas, costos y alertas se fragmentan.

Paso 3: combinar auto y manual instrumentation

La autoinstrumentación cubre frameworks, HTTP, bases de datos y librerías conocidas con poco cambio de código. Es ideal para descubrir la topología inicial.

La instrumentación manual agrega significado de negocio: tipo de operación, resultado de una orden o etapa de un proceso. Debe evitar datos personales, secretos e identificadores con cardinalidad ilimitada.

Paso 4: propagar contexto

La propagación transporta trace_id y span_id entre procesos. Sin ella, cada servicio crea una traza aislada y se pierde el recorrido.

También permite correlacionar logs con la traza activa. La validación debe incluir HTTP, mensajería, jobs asíncronos y protocolos internos; los cortes suelen aparecer en librerías o gateways no instrumentados.

Paso 5: diseñar el Collector

El Collector puede:

  • Recibir OTLP y formatos existentes.
  • Agregar atributos de infraestructura.
  • Eliminar campos sensibles.
  • Limitar memoria y procesar lotes.
  • Filtrar telemetría sin valor.
  • Aplicar muestreo.
  • Enviar a uno o varios backends.

Debe monitorearse como un componente crítico. Colas llenas, rechazos, reinicios o errores de exportación pueden crear puntos ciegos aunque la aplicación funcione.

Patrones de despliegue del Collector

El patrón agent ejecuta un Collector cerca de cada host o workload. Facilita recoger logs y metadatos locales, y distribuye carga. El patrón gateway centraliza credenciales, procesamiento y exportación. Muchas empresas combinan ambos.

Para elegir, evaluá límites de red, aislamiento, volumen y dominio de falla. Un único gateway simplifica gobierno, pero puede concentrar capacidad y riesgo. Múltiples gateways necesitan balanceo, configuración consistente y una estrategia para colas.

La configuración debería versionarse, probarse con telemetría sintética y desplegarse progresivamente. Medí recepción, exportación, datos rechazados, uso de memoria y longitud de colas. Si el Collector cambia atributos o elimina señales, ese comportamiento debe tener tests igual que una API.

Paso 6: controlar cardinalidad

Un atributo con valores casi únicos —request ID, URL sin parametrizar, timestamp o correo— multiplica series y consultas. Las rutas deben normalizarse: /clientes/{id} en lugar de /clientes/728491.

Separá atributos útiles para buscar de campos que sólo generan volumen. La cardinalidad debe revisarse antes y después de cada nueva instrumentación.

Paso 7: definir muestreo

Guardar todas las trazas puede ser válido en bajo volumen, pero rara vez escala. Existen dos enfoques:

  • Head sampling: decide al inicio; es simple y barato, pero todavía no conoce el resultado.
  • Tail sampling: decide al finalizar; puede conservar errores, alta latencia o servicios críticos, pero requiere más memoria y operación.

Una política combinada puede conservar el 100 % de errores y transacciones críticas, mientras toma una muestra representativa del tráfico saludable.

Paso 8: validar calidad, no sólo llegada

La prueba debe comprobar:

  • Continuidad de trazas entre servicios.
  • Nombres estables y comprensibles.
  • Versiones y entornos correctos.
  • Logs correlacionados.
  • Ausencia de secretos y datos personales.
  • Pérdida, latencia y reintentos del pipeline.
  • Volumen diario y proyección de costo.

Ver spans en un dashboard no confirma que sean útiles durante un incidente.

Estrategia de adopción

  1. Un flujo crítico y tres a cinco servicios.
  2. Convenciones y Collector como código.
  3. Pruebas de falla y de carga.
  4. Presupuesto de telemetría por equipo.
  5. Plantillas reutilizables para nuevos servicios.
  6. Revisión mensual de calidad y costo.

El objetivo es una plataforma interna que facilite hacer lo correcto, no una colección de configuraciones diferentes.

Definí además un proceso de excepción. Un servicio puede necesitar atributos o retención especiales, pero debe justificarlo, estimar volumen y fijar fecha de revisión. Sin ese mecanismo, las convenciones se rompen silenciosamente y el pipeline común deja de ser confiable.

Próximo paso

CTL implementa OpenTelemetry en Argentina y Latinoamérica, desde pruebas de concepto hasta pipelines empresariales multi-backend. Agendá una reunión técnica.

Preguntas frecuentes

¿OTLP cifra los datos?

OTLP puede transportarse por gRPC o HTTP con TLS. Además deben definirse autenticación, rotación de credenciales, segmentación y políticas de red.

¿OpenTelemetry reduce el vendor lock-in?

Reduce el acoplamiento de instrumentación y transporte, pero no elimina la dependencia de consultas, dashboards, retención y funciones propietarias del backend.

¿Conviene migrar toda la telemetría al mismo tiempo?

No. Conviene comenzar por un flujo medible, comparar datos y costo, documentar convenciones y ampliar progresivamente.

Fuentes verificables