Eran las 2 de la mañana en el NOC y el checkout de un cliente de retail se estaba cayendo a pedazos. El dashboard mostraba un pico de latencia enorme, pero el pico no te dice dónde ni por qué. Esa noche aprendí, otra vez, la misma lección de siempre: una sola señal nunca alcanza. Necesitas las tres. La métrica nos gritó que algo dolía, el log nos susurró el error exacto y la traza nos señaló con el dedo al servicio culpable. Ese trío –métricas, logs y trazas– es la columna vertebral de la observabilidad moderna. En este artículo te explico qué es cada uno, cuándo usarlo y cómo se complementan, con un caso real del NOC de por medio.
🔑 Lo esencial en 20 segundos
- Métricas: números agregados en el tiempo. Te dicen que algo va mal y qué tan mal. Baratas y rápidas.
- Logs: eventos con contexto. Te dicen qué pasó exactamente en un momento dado.
- Trazas: el viaje de una petición entre servicios. Te dicen dónde se fue el tiempo.
- Las tres son las señales que OpenTelemetry define como pilares de la telemetría. Ninguna sola te da el cuadro completo.
¿Qué son las métricas, los logs y las trazas?
Son las tres señales de telemetría que un sistema emite para que puedas entender qué está haciendo por dentro. El modelo lo popularizó Peter Bourgon en 2017, cuando describió métricas, trazas y logging como pilares con propiedades distintas. Hoy OpenTelemetry las formaliza como señales: cada una responde una pregunta diferente sobre el mismo sistema.
Piénsalo con una analogía de campo. Cuando llega un ticket de “la app está lenta”, yo hago tres preguntas en orden. Primero: ¿qué tan lenta y desde cuándo? Eso lo contesta una métrica. Segundo: ¿qué dice el sistema que falló? Eso está en los logs. Tercero: ¿en qué parte del recorrido se atoró la petición? Para eso existe la traza. Son capas de zoom sobre el mismo problema.
Las tres señales no compiten, se turnan. La métrica te despierta, el log te explica, la traza te ubica. Un buen sistema de observabilidad no te obliga a elegir: te deja saltar de una a otra sin perder el contexto. Ese salto, y no la cantidad de dashboards, es lo que separa monitorear de observar de verdad.
Métricas: los números que vigilan sin dormir
Una métrica es un valor numérico medido a lo largo del tiempo: latencia p99, peticiones por segundo, uso de CPU, tasa de errores. Su superpoder es la agregación barata. Puedes guardar años de una métrica sin que la factura explote, porque solo almacenas números resumidos, no cada evento individual.
El SRE Book de Google insiste en medir lo que le importa al usuario, no lo que es fácil de medir. Por eso yo priorizo las llamadas señales doradas: latencia, tráfico, errores y saturación. Una métrica es perfecta para alertar y para ver tendencias, pero es ciega al detalle. Te dice que la tasa de error subió a 4%, jamás te dirá cuál error fue.
Logs: el diario de a bordo del sistema
Un log es un registro de un evento puntual, casi siempre con marca de tiempo y contexto. Es la señal más antigua y la más intuitiva: cualquiera que haya hecho tail -f en un servidor a las 3 a.m. ya trabajó con logs. Su fuerza es el detalle: capturan el mensaje de error crudo, el stack trace, el ID del pedido que falló.
El problema clásico del log es el volumen. Un servicio con tráfico alto genera millones de líneas, y buscar entre ellas sin estructura es una tortura. Por eso hoy insistimos en logs estructurados: en lugar de texto libre, cada log es un objeto con campos consultables. Así se ve una línea de log estructurado real, simplificada:
{"ts":"2026-07-17T02:14:33Z","level":"error","service":"payments-api",
"trace_id":"a1b2c3d4e5f6","order_id":"MX-88213","msg":"upstream timeout",
"upstream":"fraud-check","latency_ms":9800,"http_status":504}Fíjate en el campo trace_id. Ese pequeño detalle es lo que después nos permitirá saltar del log a la traza completa. Un log sin trace_id es una isla; uno con él es una puerta.
Trazas: el mapa del viaje de una petición
Una traza reconstruye el recorrido completo de una petición a través de todos los servicios que tocó. Se compone de spans: cada span es un tramo de trabajo (una llamada a la base de datos, una petición a otro microservicio) con su duración. Encadenados, los spans forman una línea de tiempo que muestra exactamente dónde se gastó cada milisegundo.
En arquitecturas de microservicios, la traza es indispensable. Una petición de checkout puede pasar por ocho o diez servicios; sin trazas, saber cuál de ellos se comió el tiempo es adivinar. La traza convierte esa adivinanza en una respuesta visual: ves la barra larga y sabes quién es el culpable.
¿Cómo se ve un mismo incidente contado por las tres señales?
Se ve como una investigación en tres actos, y el checkout de aquella madrugada es el ejemplo perfecto. La métrica detectó el problema, el log lo nombró y la traza lo localizó. Ninguna de las tres, por sí sola, nos habría dado el diagnóstico en menos de una hora. Juntas, lo cerramos en minutos. Te lo cuento tal cual pasó.
Acto 1, la métrica nos despertó. A las 2:14 saltó la alerta: la latencia p99 del endpoint /checkout pasó de 400 ms a más de 9 segundos. El dashboard mostraba una pared vertical roja. Eso es lo que hace bien una métrica: te avisa rápido y te dice la magnitud del dolor, sin ambigüedad. Pero ahí se agota. La curva subía y no explicaba nada más. ¿Base de datos? ¿Red? ¿Un despliegue reciente? La métrica encoge de hombros.
Acto 2, el log nos dio el nombre. Filtramos los logs del servicio payments-api por level:error en esa ventana de tiempo. Ahí estaba, repetido cientos de veces: "upstream timeout" contra el servicio fraud-check, con http_status: 504. Es exactamente la línea que te mostré arriba. El log convirtió “algo está lento” en “las llamadas a verificación de fraude están expirando”. Enorme avance. Pero el log tampoco cerraba el caso: fraud-check a su vez llama a otros componentes. ¿El timeout era de fraud-check mismo o de algo detrás de él?
Acto 3, la traza nos señaló al culpable. Tomamos el trace_id de uno de esos logs y abrimos la traza completa. La línea de tiempo era clarísima: el span de payments-api esperaba, el de fraud-check esperaba, y casi todo ese tiempo colgaba de un solo span hijo: una consulta a una base de datos de listas de riesgo que se había quedado sin conexiones libres en el pool. El 96% de los 9 segundos vivía ahí. Reiniciamos el pool, subimos el límite de conexiones y la p99 volvió a bajar. Caso cerrado.
trace_id hasta tus logs desde el día uno. Sin ese hilo, saltar de un log a su traza es imposible y vuelves a la arqueología manual. En mis años de NOC, el 80% del tiempo perdido en un incidente no era arreglarlo: era encontrarlo. Ese campo compartido es lo que borra ese tiempo muerto.
La moraleja es incómoda pero honesta: si esa noche solo hubiéramos tenido métricas, sabríamos que dolía pero no dónde. Solo con logs, sabríamos el error pero no que colgaba de un pool de conexiones dos saltos más abajo. Solo con trazas -si no supiéramos qué buscar- estaríamos nadando en spans. Las tres señales se necesitan porque cada una empieza donde la otra se queda muda.
¿Cuándo usar cada señal? Tabla comparativa
Usa la métrica para vigilar y alertar, el log para investigar el detalle de un evento y la traza para localizar cuellos de botella entre servicios. Esa es la regla de dedo que aplico en el NOC. Cada señal tiene una granularidad, un costo y un caso de uso natural distintos, y forzar una a hacer el trabajo de otra sale caro. Esta tabla resume cómo las reparto en la práctica.
| Señal | Qué pregunta responde | Granularidad | Costo / cardinalidad | Cuándo usarla |
|---|---|---|---|---|
| Métrica | ¿Qué tan mal va y desde cuándo? | Agregada en el tiempo (series numéricas) | Barata por defecto; se dispara con alta cardinalidad de etiquetas | Alertas, dashboards, tendencias de largo plazo |
| Log | ¿Qué pasó exactamente en este evento? | Por evento individual, con contexto | Media a alta; el volumen crece con el tráfico | Investigar errores, auditoría, detalle forense |
| Traza | ¿Dónde se fue el tiempo entre servicios? | Por petición, dividida en spans | Media; suele muestrearse para controlar volumen | Latencia en sistemas distribuidos, cuellos de botella |
¿Qué es la cardinalidad y por qué dispara tu factura?
La cardinalidad es la cantidad de combinaciones únicas de etiquetas que tiene una métrica, y es el factor que más silenciosamente infla el costo de la observabilidad. Cada etiqueta con muchos valores posibles multiplica el número de series temporales que tu plataforma debe almacenar e indexar. Es el error de novato que más veces vi convertir una factura razonable en una pesadilla presupuestal.
El mecanismo es sencillo de entender con un ejemplo. Imagina una métrica de latencia con una etiqueta región que tiene 5 valores: son 5 series. Ahora agrégale endpoint con 20 valores: ya son 100 series. Todavía manejable. Pero si a alguien se le ocurre etiquetar por user_id o por trace_id, con millones de valores posibles, la explosión de cardinalidad puede multiplicar tu costo por miles sin darte más información útil. Cada usuario único crea su propia serie temporal eterna.
La regla que sigo es directa: los identificadores de altísima cardinalidad (IDs de usuario, de pedido, de sesión) viven en los logs y las trazas, no en las etiquetas de las métricas. Las métricas son para dimensiones acotadas y estables. Esta división de responsabilidades es también una razón práctica por la que existen las tres señales: cada una absorbe el tipo de dato que le sale barato manejar. Si necesitas comparar dónde duele más ese costo, lo abordo en el artículo sobre observabilidad en nube frente a on-premise.
Un detalle que la gente pasa por alto: la cardinalidad no solo encarece, también degrada el rendimiento de las consultas. Un backend de métricas ahogado en series basura responde lento justo cuando más lo necesitas, en plena guerra de guardia. Controlar la cardinalidad no es tacañería, es higiene operativa.
¿Por qué ninguna señal basta por sí sola?
Porque cada señal está diseñada para responder una pregunta distinta, y un incidente real casi siempre exige las tres respuestas. El SRE Book de Google advierte sobre lo frágil que es depender de una sola fuente de verdad en sistemas distribuidos. La observabilidad efectiva no es acumular datos, es poder correlacionarlos.
La correlación es la verdadera magia, y es lo que separa una plataforma moderna de tres herramientas sueltas. El trace_id que viaja del log a la traza es el ejemplo canónico. Cuando puedes hacer clic desde un pico en un gráfico hasta los logs de esa ventana, y de ahí a la traza exacta de una petición fallida, el tiempo de diagnóstico se desploma. Ese salto fluido es, medido en horas de guardia, lo que reduce el MTTR de un equipo SRE.
Aquí va una opinión de campo que no siempre cae bien: muchos equipos compran las tres señales pero las usan como silos. Métricas en una herramienta, logs en otra, trazas en una tercera, sin hilos que las conecten. Eso es tener tres pilares sin techo. La pregunta correcta al evaluar tu observabilidad no es “¿tengo las tres señales?”, sino “¿puedo saltar de una a otra sin copiar y pegar timestamps a mano?”. Si la respuesta es no, tienes datos, no observabilidad.
¿Cómo empiezo a instrumentar las tres señales?
El punto de partida más sensato hoy es OpenTelemetry, el estándar abierto que unifica la generación de las tres señales bajo una sola especificación. Es un proyecto graduado de la CNCF, lo que en la práctica significa que es maduro, tiene comunidad enorme y no te amarra a un solo proveedor. Es, además, uno de los proyectos más activos de todo el ecosistema cloud native.
La gran ventaja de OpenTelemetry es que instrumentas tu código una vez y decides después a dónde mandas los datos. Métricas, logs y trazas salen con un formato común y un contexto compartido, que es justo lo que hace posible la correlación de la que hablamos. Evitas quedar atrapado con un vendor y puedes cambiar de backend sin re-instrumentar todo. Si quieres el recorrido completo sin tecnicismos innecesarios, lo desmenuzo en OpenTelemetry explicado sin drama.
Mi recomendación para arrancar, sin sobreingeniería: empieza por las métricas de las señales doradas para tener alertas útiles ya. Agrega logs estructurados con trace_id en tus servicios críticos. Y activa trazas en el flujo que más te duela cuando falla -para muchos, el checkout o el login-. No tienes que instrumentarlo todo el día uno. Instrumenta donde el dolor de guardia sea más caro.
¿Estás armando tu estrategia de observabilidad desde cero? Empieza por entender qué es la observabilidad y en qué se diferencia del monitoreo tradicional, y luego vuelve aquí para instrumentar las tres señales con criterio. Suscríbete para recibir los siguientes artículos de la serie fundacional. 🚀
Preguntas frecuentes
¿Cuál es la diferencia entre métricas, logs y trazas?
Las métricas son números agregados en el tiempo que te dicen qué tan mal va algo y desde cuándo. Los logs son registros de eventos individuales con contexto que te dicen qué pasó exactamente. Las trazas siguen el recorrido de una petición entre servicios y te dicen dónde se fue el tiempo. Cada una responde una pregunta distinta y se complementan.
¿Necesito las tres señales o puedo empezar con una?
Puedes empezar con métricas para tener alertas rápidas, y en la práctica muchos equipos arrancan ahí. Pero para diagnosticar incidentes reales en sistemas distribuidos vas a necesitar las tres, porque una sola no te da el cuadro completo. Mi recomendación es sumar logs estructurados y trazas en tus flujos más críticos lo antes posible.
¿Qué es la cardinalidad y por qué importa?
La cardinalidad es el número de combinaciones únicas de etiquetas de una métrica. Importa porque cada combinación crea una serie temporal que hay que almacenar e indexar. Etiquetar métricas con identificadores de altísima cardinalidad, como IDs de usuario, dispara el costo y degrada el rendimiento de las consultas. Esos identificadores deben ir en logs y trazas, no en métricas.
¿OpenTelemetry sirve para las tres señales?
Sí. OpenTelemetry es un estándar abierto, proyecto graduado de la CNCF, que unifica la generación de métricas, logs y trazas bajo una sola especificación. Instrumentas tu código una vez y decides después a qué backend enviar los datos, con un contexto compartido que facilita correlacionar las señales entre sí sin quedar atado a un proveedor.
✍️ Creado por Ethel Méndez — Senior Product Manager en observabilidad, con más de 20 años entre NOC, managed services y producto B2B para LATAM. Escribo sobre lo que aprendí de guardia, no de manual. 🐱☕
Imagen destacada generada con inteligencia artificial.
Que los sistemas estén con ustedes. ✦
Ethel Méndez
Senior Product Manager en observabilidad y redes B2B, con 20 años de campo, NOC y servicios administrados en LATAM. Escribo lo que aprendí operando sistemas de verdad, no en un curso.
Suscríbete y no te pierdas ninguna historia 📬
Historias de observabilidad, producto y mujeres que hicieron historia — directo en tu correo. Sin spam. ✦