Cloud y plataforma
OpenTelemetry: observabilidad que no depende del proveedor
Cómo unir trazas, métricas y logs alrededor de preguntas operativas y no de un tablero decorativo.
Observabilidad es poder explicar el estado interno de un sistema a partir de sus señales. OpenTelemetry aporta una forma neutral de instrumentar, recolectar y exportar trazas, métricas y logs, pero no sustituye el backend que almacena y consulta esos datos.
La adopción funciona mejor cuando parte de recorridos críticos: iniciar sesión, pagar, generar un reporte o procesar un archivo. Propagar contexto entre servicios permite relacionar una solicitud con dependencias, errores y latencia sin reconstruir la historia manualmente.
Visual editorial
Ruta de una señal observable
01
Aplicación
Trazas, métricas y logs
02
Collector
Procesa, filtra y muestrea
03
Backend
Almacena y consulta
04
Respuesta
SLO, alerta e investigación
El Collector desacopla aplicaciones y destinos. Puede recibir señales, enriquecerlas, filtrar datos sensibles, aplicar muestreo y exportar a más de un backend. Esa frontera reduce dependencia de proveedor y evita instalar lógica distinta en cada servicio.
Instrumentar todo sin criterio eleva costo y ruido. Conviene definir convenciones de nombres, límites de cardinalidad, políticas de retención y objetivos de servicio antes de llenar tableros. La telemetría debe responder decisiones operativas concretas.
Empezar por preguntas operativas
Antes de instrumentar conviene escribir las preguntas: qué porcentaje de pagos termina, dónde se acumula la latencia, qué dependencia explica un error y qué versión introdujo la regresión. Esas preguntas definen atributos, eventos y métricas; instrumentar primero suele producir datos caros que nadie sabe consultar.
Propagar contexto de extremo a extremo
El identificador de traza debe atravesar HTTP, mensajería y trabajos asíncronos. Los spans necesitan nombres estables y atributos con cardinalidad controlada. Identificadores únicos, correos o payloads completos no son buenas dimensiones para métricas y pueden filtrar información sensible.
Usar el Collector como frontera operativa
Un despliegue por nodo o un gateway central permiten enriquecer señales, eliminar secretos, aplicar sampling y enrutar por entorno. La topología depende del volumen y la tolerancia a fallos. El Collector también necesita métricas propias: colas, descartes, latencia de exportación y presión de memoria.
Controlar costo y ruido
El muestreo debe conservar errores, operaciones lentas y recorridos de alto valor, no simplemente un porcentaje uniforme. Retención y resolución cambian según la señal. Una alerta útil se vincula a un objetivo de servicio y trae suficiente contexto para empezar a investigar sin abrir cinco tableros.
Neutralidad con propósito
OpenTelemetry reduce dependencia en la instrumentación, no elimina decisiones de producto. El éxito se mide por el tiempo que tarda el equipo en explicar un incidente y comprobar una mejora, no por la cantidad de señales almacenadas.