¿Cuáles son los tres pilares de la observabilidad — logs, métricas y trazas — y cómo se complementan?
Las métricas te dicen que algo anda mal y qué tan grave, las trazas te dicen dónde dentro del sistema, y los logs te dicen exactamente por qué — un único trace_id es lo que permite correlacionar los tres durante un incidente.
APRENDE HACIENDOPon a prueba tu intuición3 pasos
¿Cuáles son los tres pilares de la observabilidad — logs, métricas y trazas — y cómo se complementan?
Usa los ejemplos y la explicación de la lección para comprobar tu idea.
Reflexión personal. No se envía a ningún servicio de IA.#El monitoreo te dice que algo está roto. La observabilidad te deja preguntar por qué, sobre un sistema que nunca viste fallar así antes.
El modelo viejo de "vigilar" un sistema era un conjunto curado de dashboards y alertas construidos de antemano para modos de falla que alguien ya había anticipado. La observabilidad es la apuesta opuesta: instrumentar el sistema con la suficiente riqueza, de tres formas complementarias, para que cuando falle de una manera que nadie anticipó, igual puedas hacerle preguntas arbitrarias y obtener respuestas — sin tener que desplegar código nuevo primero. Los tres pilares —logs, métricas y trazas— no son tres herramientas compitiendo por el mismo trabajo. Cada uno responde una pregunta distinta, y un incidente normalmente recorre los tres, en orden.
#Métricas: si algo anda mal, y qué tan grave
Una métrica es una serie temporal numérica: un contador (http_requests_total, solo aumenta), un gauge (queue_depth, sube y baja), o un histograma (http_request_duration_seconds, baldes de cuánto tardaron las cosas). Las métricas son baratas de almacenar porque vienen preagregadas —un contador de Prometheus ocupa lo mismo represente 10 requests o 10 millones—, y eso es exactamente lo que las hace buenas para retención larga, dashboards y alertas sobre SLOs ("la latencia p99 de /checkout superó los 500ms durante 5 minutos"). Lo que no pueden decirte es cuál request fue lenta, ni por qué — la agregación es todo el punto, y agregar destruye el detalle por request en el camino.
#Trazas: adónde se fue realmente el tiempo dentro del sistema
Una traza representa el recorrido de una request a través de cada servicio que tocó, como un árbol de spans — cada span registra una unidad de trabajo (un handler, una llamada a base de datos, un RPC hacia otro servicio) con un tiempo de inicio, una duración, y un span padre bajo el cual está anidado. Reconstruir ese árbol te dice exactamente dónde gastó su tiempo una request lenta: 4ms en el gateway, 6ms creando un pedido, 290ms esperando una llamada de pago downstream que a su vez pasó la mayor parte del tiempo esperando al procesador de tarjetas. Las trazas son lo que hace siquiera manejable la depuración de latencia distribuida — sin ellas, "el endpoint de checkout está lento" no te da ninguna pista de cuál de los seis servicios que toca es el verdadero culpable. El costo es el volumen: capturar una traza completa de cada request no escala más allá de cierto tamaño, así que los sistemas en producción muestrean (guardan un porcentaje de las trazas, o específicamente guardan toda traza que dio error o fue inusualmente lenta vía sampling tail-based).
#Logs: qué pasó exactamente, en detalle
Un log es un evento discreto y con marca de tiempo, con el detalle que quieras adjuntarle — un stack trace, el payload de una request, un ID de usuario, un mensaje de error específico. Los logs son la señal de mayor cardinalidad y mayor detalle, y la más cara de almacenar y consultar a volumen, por eso casi nunca son donde empezás una investigación y casi siempre son donde la terminás, una vez que las métricas y las trazas ya redujeron la búsqueda a "esta request específica, en este servicio específico, en este momento específico".
#Una request, tres artefactos, en cada salto
La señal que une a los tres no es una herramienta, es un único identificador compartido — un trace_id— generado en el borde y propagado a cada llamada downstream vía un header (el estándar W3C traceparent). OpenTelemetry es el estándar de instrumentación neutral respecto al proveedor que emite los tres tipos de señal con ese identificador ya adjunto, por eso un stack moderno trata "agregar observabilidad" como una única integración, no tres.
Cada salto de esa única request emite los tres tipos de señal simultáneamente: una línea de log con el trace_id compartido como campo estructurado, un incremento de métrica que alimenta los dashboards agregados, y un span que pasa a formar parte de una traza ensamblada una vez recolectado. Ninguno es "el verdadero" — son tres vistas del mismo evento, en tres niveles distintos de detalle y costo.
#Correlacionar los tres durante un incidente real
Esta es la forma realista de casi todos los incidentes: una alerta basada en métricas te dice que algo empeoró y más o menos qué tan grave, porque las métricas son lo suficientemente baratas como para vigilarlas continuamente y alertar sobre ellas. Después abrís las trazas de ese servicio y esa ventana de tiempo para ver dónde gastó el tiempo la request — qué salto es el que realmente está lento, no solo que "checkout" en general está lento. Una vez que aislaste una traza representativa lenta o fallida, tomás su trace_id y buscás las líneas de log exactas de esa request puntual, en cada servicio que tocó, para ver el mensaje de error real, el payload o el stack trace que explica por qué. Saltar directo a los logs sin acotar antes con métricas y trazas significa buscar con grep en un océano de líneas sin ninguna idea de cuáles son siquiera relevantes.
#Comparando los tres pilares
| Métricas | Trazas | Logs | |
|---|---|---|---|
| Responde | Si algo anda mal, qué tan grave, desde cuándo | Adónde se fue el tiempo dentro del sistema | Por qué exactamente pasó esto |
| Cardinalidad | Baja (conjuntos de etiquetas fijos) | Media (por request, muestreada) | Alta (detalle arbitrario por evento) |
| Costo de almacenamiento | El más bajo, retención larga | Moderado, a menudo muestreado | El más caro a volumen completo |
| Herramientas típicas | Prometheus, Datadog, CloudWatch | Jaeger, Tempo, Zipkin | Loki, Elasticsearch/ELK, Splunk |
| Dónde se usa en un incidente | Primero — la alerta | Segundo — localizar el salto lento o roto | Tercero — la causa raíz real |
🧠 Check your understanding
0/3 · 0/3 answered1. Se dispara una alerta porque la latencia p99 de un endpoint superó su SLO. ¿Cuál es el siguiente paso más eficiente, antes de meterse en los logs?
2. ¿Por qué poner `user_id` como etiqueta de una métrica de Prometheus es un error común en producción?
3. ¿Cuál es el mecanismo que permite correlacionar una línea de log, un incremento de métrica y un span de traza de la misma request durante un incidente?