El Modelo de Correlación de Observabilidad
Cada página de esta sección puede parecer una lista de compras de herramientas: structlog para logs, prometheus_client para métricas, OpenTelemetry para trazas, Sentry para errores, cada una con su propia biblioteca y sus propios pasos de configuración.
Conceptos Básicos de Observabilidad ya recorre esa sintaxis en los cuatro pilares.
Lo que los une en una práctica coherente en lugar de cuatro integraciones no relacionadas es un modelo: los mismos eventos subyacentes se observan desde diferentes ángulos, correlacionados por identificadores compartidos, y cada ángulo tiene su propia estructura de costos que decide cuánto de ello puedes permitirte conservar.
Comprender ese modelo cambia el pilar al que recurres primero cuando algo falla, y por qué "simplemente registrar todo" o "simplemente rastrear todo" eventualmente dejan de funcionar como estrategia.
Resumen
- Los logs, métricas y trazas son tres vistas diferentes de la misma solicitud o trabajo, unidas por identificadores de correlación compartidos, no tres fuentes de verdad independientes.
- Por Qué Importa: Sin un identificador compartido que atraviese los tres, la investigación de un incidente degenera en adivinar qué líneas de log, qué pico en el dashboard y qué traza lenta pertenecen al mismo evento.
- Conceptos Clave: ID de correlación, cardinalidad, señal vs. ruido, vitalidad vs. preparación, las tres preguntas (qué sucedió, con qué frecuencia y cuán rápido, dónde se fue el tiempo).
- Cuándo Usar Este Modelo: Para decidir a qué pilar añadir instrumentación, diseñar qué debe contener una línea de log o un atributo de span, y estructurar un runbook de respuesta a incidentes.
- Limitaciones / Compensaciones: Cada pilar tiene un costo real: los logs cuestan almacenamiento y tiempo de consulta, las métricas cuestan cardinalidad, las trazas cuestan decisiones de muestreo, por lo que "instrumentar todo" no es una estrategia gratuita a ninguna escala no trivial.
- Temas Relacionados: logging estructurado, métodos RED y USE, tracing distribuido, sondas de salud y preparación.
Fundamentos
Una pregunta inicial útil no es "¿qué herramienta de observabilidad debo usar?" sino "¿qué pregunta estoy tratando de responder realmente?".
Los Logs responden "¿qué sucedió específicamente?" - un evento discreto y con marca de tiempo con detalles arbitrarios, como "el pedido 4821 falló la validación: falta dirección de envío".
Las Métricas responden "¿con qué frecuencia y cuán rápido, en agregado?" - un número rastreado a lo largo del tiempo, como un recuento de solicitudes o una latencia p99, sin el detalle específico de una sola solicitud.
Las Trazas responden "¿dónde se fue realmente el tiempo, para esta solicitud, a través de todos los servicios que tocó?" - la ruta causal y jerárquica de una operación.
Un cuarto pilar, más pequeño: las verificaciones de estado (health checks), responde a un tipo de pregunta completamente diferente: no "¿qué sucedió?" sino "¿puede esta instancia servir tráfico ahora mismo?", una pregunta operativa en tiempo presente que los otros tres no responden directamente.
Ninguno de estos cuatro es un reemplazo del otro; una métrica puede decirte que la tasa de error aumentó a las 14:02, pero solo un log o traza correlacionado puede decirte por qué sucedió ese pico específico.
Mecánicas e Interacciones
El mecanismo que convierte cuatro señales separadas en una investigación coherente es el identificador de correlación, comúnmente un request_id generado en el borde de una solicitud y un trace_id propagado por un sistema de tracing.
from contextvars import ContextVar
request_id: ContextVar[str] = ContextVar("request_id", default="-")
# cada línea de log emitida durante esta solicitud incluye request_id,
# por lo que una búsqueda de log para un ID reconstruye la historia completa de la solicitudUna vez que ese identificador se adjunta a cada línea de log de una solicitud, se presenta como un atributo en los spans de traza relevantes, y está disponible como una etiqueta (con cuidado, dadas las limitaciones de cardinalidad a continuación) para al menos las métricas de nivel de error, una respuesta a incidentes sigue un camino predecible: una alerta de métrica dice que algo está mal y aproximadamente cuándo, una búsqueda de log limitada a la ventana de tiempo afectada y request_id dice específicamente qué sucedió, y una traza para el mismo ID dice dónde ocurrió realmente el tiempo o la falla entre servicios.
La cardinalidad es la palanca de costos más importante en los tres pilares, y es fácil razonar erróneamente sobre ella.
Una etiqueta de métrica con valores ilimitados —un ID de usuario crudo, una URL completa con parámetros de consulta, un UUID— multiplica el número de series temporales distintas que un backend de métricas debe almacenar, a menudo convirtiendo un contador barato en un problema de almacenamiento y consulta; la misma lógica se aplica a los atributos de span en un backend de tracing.
Es por eso que las métricas estilo Prometheus usan un conjunto pequeño y acotado de valores de etiqueta (method, status_code, endpoint) en lugar de identificadores por solicitud, y por qué el detalle de alta cardinalidad pertenece en logs y atributos de traza en su lugar, donde se espera y se le pone un precio diferente.
El muestreo existe por la misma razón subyacente en el lado del tracing: registrar cada span para cada solicitud con tráfico de producción real es costoso de almacenar y consultar, por lo que la mayoría de las configuraciones de tracing solo conservan una fracción de las trazas, generalmente sesgadas hacia las que fallaron o fueron lentas.
Consideraciones y Aplicaciones Avanzadas
Los métodos RED (Rate, Errors, Duration - Tasa, Errores, Duración) y USE (Utilization, Saturation, Errors - Utilización, Saturación, Errores) son dos lentes comunes para decidir qué métricas rastrear realmente, y elegir el incorrecto para un componente dado produce dashboards que parecen ocupados pero no responden a preguntas operativas.
RED se adapta bien a servicios impulsados por solicitudes, ya que la tasa, la tasa de error y la duración por endpoint se mapean directamente a lo que experimenta un llamador.
USE se adapta mejor a recursos como pools de conexiones, colas y workers, ya que la utilización y la saturación detectan problemas (un pool al 95% de capacidad) antes de que se manifiesten como errores.
Las verificaciones de estado interactúan con los otros tres pilares principalmente en el límite de un orquestador, no dentro de una investigación de incidentes: una sonda de preparación fallida es a menudo la primera señal similar a una métrica (tasa de fallos de la sonda) que desencadena una investigación más profunda de logs y trazas; consulta Salud y Preparación para la distinción entre vitalidad y preparación en la que esto se basa.
Las herramientas de seguimiento de errores como Sentry se encuentran en una intersección interesante de logs y métricas: agregan eventos de excepción (similares a logs, con detalles completos) en problemas agrupados con recuentos de ocurrencias y tendencias (similares a métricas), es por eso que tienden a convertirse en el primer lugar donde los ingenieros buscan después de que se dispara una alerta de métrica, antes de la búsqueda de logs crudos.
A medida que un sistema escala más allá de un puñado de servicios, el modelo de correlación en sí mismo se convierte en algo en lo que vale la pena invertir deliberadamente: un nombre de campo consistente para el ID de correlación en cada servicio, formateador de logs y biblioteca de tracing, decidido una vez, ahorra mucho más tiempo de incidentes que cualquier elección de herramienta individual.
| Señal | Fortaleza | Debilidad | Mejor Ajuste |
|---|---|---|---|
| Logs | Detalle arbitrario, barato de añadir por evento | Caro de buscar a escala, logs no estructurados resisten la correlación | Raíz de un evento específico conocido |
| Métricas | Barato de almacenar y alertar en agregado, genial para dashboards | Sin detalle por solicitud, la cardinalidad limita lo que puede ser una etiqueta | Detectar que algo está mal y aproximadamente cuánto |
| Trazas | Muestra la ruta causal y el tiempo exactos entre servicios | El muestreo significa que algunas solicitudes nunca se capturan; necesita propagación en todas partes | Encontrar dónde ocurrió el tiempo o la falla en una llamada distribuida |
Conceptos Erróneos Comunes
- "Más logging siempre es mejor observabilidad." Más allá de un punto, los logs no estructurados de alto volumen se vuelven caros de almacenar y lentos de buscar, ocultando activamente la señal que te llevó a añadir más logging en primer lugar.
- "Las métricas y las trazas son redundantes una vez que tienes una de ellas." Una métrica te muestra una tendencia en todas las solicitudes; una traza te muestra el camino específico de una solicitud; ninguna sustituye a la otra, responden preguntas diferentes con diferente granularidad.
- "Una verificación de estado y un dashboard de métricas te dicen lo mismo." Una verificación de estado es un sí/no en tiempo presente sobre una instancia específica ahora mismo; un dashboard de métricas agrega tendencias a lo largo del tiempo en todas las instancias, es por eso que una instancia puede estar "no saludable" durante segundos antes de que cualquier tendencia del dashboard lo refleje.
- "El muestreo de trazas significa que te perderás incidentes importantes." Un muestreo bien diseñado mantiene deliberadamente una fracción mayor de trazas erróneas o lentas que las de rutina, por lo que las trazas más útiles durante un incidente son exactamente las menos propensas a ser descartadas.
- "La cardinalidad solo importa para las métricas." El mismo problema de etiquetas ilimitadas infla el costo en los backends de tracing también: un atributo de span que contiene un ID de usuario crudo o un cuerpo de solicitud completo tiene el mismo costo de cardinalidad que tendría una etiqueta de métrica.
Preguntas Frecuentes
¿Qué pregunta responde realmente cada pilar de observabilidad?
- Logs: qué sucedió específicamente, con detalle arbitrario
- Métricas: con qué frecuencia y cuán rápido, en agregado, a lo largo del tiempo
- Trazas: dónde se fue el tiempo, para una solicitud, a través de cada servicio
- Verificaciones de estado: ¿puede esta instancia servir tráfico ahora mismo?
¿Por qué los IDs de correlación son tan importantes para la respuesta a incidentes?
Sin un identificador compartido que conecte una línea de log, una traza y un pico de métrica, no hay forma confiable de confirmar que describen el mismo evento subyacente en lugar de una coincidencia no relacionada en la misma ventana de tiempo.
¿Qué es la cardinalidad, en términos sencillos?
El número de combinaciones distintas de valores de etiqueta o atributo que una métrica o traza puede tener; una etiqueta con valores ilimitados (como un ID de usuario crudo) multiplica ese número y aumenta el costo de almacenamiento y consulta mucho más rápido de lo que lo haría el mismo dato añadido como campo de log.
¿Por qué no puedo simplemente poner un request_id en cada etiqueta de métrica?
Una etiqueta de métrica está destinada a tener un conjunto pequeño y acotado de valores posibles para que un backend pueda pre-agregar eficientemente; un request_id no tiene límites, lo que convierte un contador barato en una serie temporal por solicitud y anula el propósito de una métrica.
¿Cómo difieren RED y USE, y cuándo uso cada uno?
RED (Tasa, Errores, Duración) se adapta a servicios impulsados por solicitudes donde la experiencia de un llamador se mapea directamente a estos tres números; USE (Utilización, Saturación, Errores) se adapta a recursos como pools, colas y workers, detectando la saturación antes de que se convierta en errores visibles.
¿Es el muestreo en tracing la misma idea que el muestreo en logging?
Resuelven un problema de costo similar pero generalmente de manera diferente: el muestreo de tracing decide qué trazas completas mantener (a menudo sesgado hacia errores y alta latencia), mientras que el muestreo de logs, cuando se usa, generalmente solo reduce el volumen de líneas de log de rutina y de bajo valor.
¿Por qué una verificación de estado necesita ser separada de un dashboard de métricas?
Una verificación de estado responde a una pregunta en tiempo presente sobre una instancia específica para la decisión de enrutamiento inmediato de un orquestador, mientras que un dashboard de métricas agrega tendencias en todas las instancias a lo largo del tiempo, útil para humanos que investigan, no para un balanceador de carga que decide si enviar la próxima solicitud.
¿Cuándo debería añadir una nueva métrica en lugar de un nuevo campo de log?
Añada una métrica cuando necesite agregación y alertas baratas y siempre activas sobre muchos eventos; añada un campo de log cuando el valor sea de alta cardinalidad o solo útil al investigar un evento específico conocido.
¿Por qué los rastreadores de errores como Sentry se sienten diferentes tanto de los logs como de las métricas?
Agregan eventos de excepción individuales (detalle similar a logs) en problemas agrupados con tendencias de ocurrencia (marco similar a métricas), es por eso que a menudo se convierten en la primera parada después de una alerta de métrica, antes de la búsqueda de logs crudos.
¿Adoptar tracing distribuido hace innecesario el logging estructurado?
No: las trazas muestran bien la estructura de tiempo y causalidad, pero los logs todavía transportan el detalle de negocio arbitrario ("qué campo falló la validación") que los spans estructurados de una traza no están diseñados para contener.
¿Cuál es el mayor error que cometen los equipos al escalar la observabilidad?
Instrumentar más de todo sin acordar primero un identificador de correlación y un nombre de campo consistentes en cada servicio, lo que dificulta la conexión real de las señales una vez que hay suficientes para que importe.
¿Existe tal cosa como demasiada instrumentación?
Sí: más allá de un punto, el volumen excesivo de logs, la cardinalidad de métricas o la creación de spans agregan costos reales de almacenamiento y consulta sin un aumento proporcional en lo que realmente puedes aprender de un incidente.
Relacionados
- Conceptos Básicos de Observabilidad - ejemplos prácticos en logs, métricas, trazas y salud
- Logging Estructurado - la implementación del lado del log de los identificadores de correlación
- Métricas - métricas RED/USE y los límites de cardinalidad que describe esta página
- Tracing Distribuido - propagación de trazas y muestreo en profundidad
- Salud y Preparación - la pregunta de vitalidad versus preparación que esta página separa de los otros tres pilares
- Mejores Prácticas de Observabilidad - la lista de verificación de señales accionables destilada de este modelo
Versiones de Stack: Esta página es conceptual y no está ligada a una versión específica de stack.