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.
La idea central
Una traza resulta útil cuando conserva el contexto entre servicios y permite responder una pregunta operativa concreta, con un costo de captura sostenible.
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.
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.
Caso didáctico
El pago terminó, pero la confirmación nunca llegó
En un checkout, la API acepta la compra, publica un mensaje y un worker genera la confirmación. El usuario ve una espera interminable. Si solo observas el tiempo de respuesta de la API, la operación parece saludable. El recorrido real termina cuando la confirmación está disponible para la persona.
Instrumenta la recepción, publicación, procesamiento y resultado del trabajo. Transporta el contexto en los metadatos del mensaje y represéntalo con relaciones entre spans o enlaces cuando corresponda, especialmente en lotes. Un log de error con contexto de traza permite llegar al recorrido; una métrica de antigüedad de la cola permite ver si el problema afecta a más usuarios.
Define qué se conserva antes de activar sampling. El muestreo al inicio de la traza no conoce su desenlace; el muestreo al final puede considerar duración o errores, pero requiere memoria y reunir los spans. Si descartaste una traza antes de que llegue al Collector, este no puede recuperarla. Tampoco todos los backends o despliegues tienen el mismo presupuesto para procesar cada señal.
Qué elegir y qué implica
| Situación | Decisión | Límite a considerar |
|---|---|---|
| Saber cuánto falla el recorrido | Métrica agregada con dimensiones acotadas. | No contiene el detalle de cada ejecución. |
| Localizar una dependencia lenta | Traza con contexto entre los límites. | El muestreo puede dejar recorridos sin capturar. |
| Explicar un fallo concreto | Log estructurado correlacionado con la traza. | Filtrar secretos y evitar payloads completos. |
Desliza la tabla para comparar las tres columnas.
Llévalo a la práctica
Ensaya una investigación de extremo a extremo
- Retrasa el worker de un entorno de pruebas.
- Desde la señal de degradación, localiza un recorrido y su dependencia.
- Interrumpe el destino de exportación y observa colas, descartes y recuperación del Collector.
Qué comprobar: Puedes explicar dónde se detuvo el recorrido y también detectar cuándo la propia telemetría perdió datos.
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.
Para seguir leyendo
Cloud y plataforma
La plataforma interna ahora sirve a equipos y agentes
Golden paths, autoservicio y políticas para una organización donde humanos y agentes consumen la misma plataforma.
Cloud y plataforma
FinOps en Azure: pasar del costo mensual al valor del producto
Un ciclo operativo para asignar gasto, detectar desperdicio y tomar decisiones técnicas con contexto de negocio.