Logs, métricas y trazas: qué responde cada señal

Cuando una organización decide "tener observabilidad", lo habitual es empezar por la herramienta: se compra una plataforma, se instalan agentes y se activan paneles. Pocas veces se empieza por la pregunta más útil: ¿qué necesitamos saber cuando algo falla? Logs, métricas y trazas no son tres formas de guardar lo mismo. Son tres instrumentos que responden preguntas distintas, con costos y límites distintos. Usar el instrumento equivocado para una pregunta produce paneles llenos y diagnósticos lentos.

Este artículo propone una forma práctica de pensar las tres señales: qué pregunta responde cada una, cuánto cuesta producirla y conservarla, cuándo es la herramienta correcta y por qué el verdadero valor aparece cuando las tres están correlacionadas.

Tres señales, tres preguntas

Una forma sencilla de ordenar la conversación es asociar cada señal a la pregunta que mejor responde durante un incidente:

• Métricas: ¿algo está mal, cuánto y desde cuándo?
• Trazas: ¿dónde, dentro del recorrido de una solicitud, se pierde el tiempo o aparece el error?
• Logs: ¿qué pasó exactamente en ese punto, con qué datos y por qué?

El orden no es casual. En un incidente típico, una métrica dispara la alerta (la latencia del servicio de pagos supera su umbral), una traza ubica el tramo responsable (la llamada al servicio de antifraude tarda cinco veces más de lo normal) y un log explica la causa (el servicio de antifraude reintenta contra una base de datos que rechaza conexiones). Si falta cualquiera de los tres pasos, el equipo vuelve a la búsqueda manual, que es justo lo que la observabilidad debería evitar.

Métricas: el pulso agregado

Una métrica es un valor numérico medido en el tiempo y agregado: solicitudes por segundo, porcentaje de errores, percentiles de latencia, uso de CPU, tamaño de una cola. Su fortaleza es la compresión. Un contador de solicitudes ocupa lo mismo si el servicio atendió diez solicitudes o diez millones en ese intervalo. Por eso las métricas son baratas de conservar durante meses, rápidas de consultar y la base natural de las alertas, los objetivos de nivel de servicio (SLO) y la planificación de capacidad.

Su debilidad es la misma compresión. Una métrica te dice, por ejemplo, que el 2 % de las solicitudes falla, pero no cuáles ni por qué. Puedes desagregarla con etiquetas (servicio, región, método, código de respuesta), y ahí aparece el límite que más conviene entender: la cardinalidad. Cada combinación distinta de valores de etiquetas genera una serie temporal nueva. Agregar una etiqueta con el identificador de cliente o de transacción multiplica las series hasta volver la métrica cara e inestable. Las métricas sirven para dimensiones acotadas y conocidas de antemano.

Un punto de partida probado son las cuatro señales doradas que describe el libro de SRE de Google (latencia, tráfico, errores y saturación), o su variante orientada a servicios (tasa, errores y duración). No cubren todo, pero obligan a medir primero lo que el usuario percibe.

Trazas: el recorrido de una solicitud

Una traza distribuida reconstruye el camino de una solicitud a través de los servicios que toca. Se compone de spans: cada span representa una operación (una llamada HTTP, una consulta a base de datos, el procesamiento de un mensaje) con su inicio, su duración, su resultado y sus atributos. Los spans comparten un identificador de traza y se encadenan por relaciones padre e hijo.

La traza responde la pregunta que ni las métricas ni los logs resuelven bien en arquitecturas distribuidas: ¿en qué tramo está el problema? Cuando una operación de negocio atraviesa una API, tres microservicios, una cola y dos bases de datos, la latencia total no dice nada sobre dónde se acumula. La traza sí.

El costo de las trazas está en el volumen: cada solicitud puede producir decenas de spans. Por eso casi todas las implementaciones usan muestreo. El muestreo en origen (decidir al inicio si se guarda la traza) es simple y barato, pero puede descartar justo la traza que fallaba. El muestreo en cola (decidir al final, con la traza completa) permite conservar todas las trazas con error o lentas, a cambio de más infraestructura para retenerlas mientras se decide. Elegir la estrategia de muestreo es una decisión de diagnóstico, no solo de presupuesto.

Logs: el detalle del evento

Un log es el registro de un evento discreto con contexto: qué ocurrió, cuándo, en qué componente y con qué datos. Es la señal más antigua y la más flexible, porque puede contener cualquier información que el desarrollador decida escribir. También es la más cara en volumen y la más fácil de usar mal.

El log responde el "por qué" que las otras señales solo insinúan: el mensaje de error del proveedor externo, la regla de negocio que rechazó la operación, el valor inesperado que llegó en un campo. Para que sea útil a escala, conviene que cumpla tres condiciones:

• Estructurado: en formato clave y valor (normalmente JSON), para que se pueda filtrar y agregar sin expresiones regulares frágiles.
• Con nivel y propósito: los niveles (error, advertencia, información, depuración) deben significar algo y usarse de forma consistente entre equipos.
• Correlacionado: cada línea debe llevar el identificador de traza y de span activos, para saltar del log a la traza y viceversa.

Un error frecuente es usar los logs como sustituto de las métricas: contar líneas de log para calcular tasas de error. Funciona, pero es caro y frágil, porque cualquier cambio en el texto del mensaje rompe el indicador. Si una cifra se consulta todos los días o dispara alertas, debe ser una métrica.

Cardinalidad, volumen y costo

Las tres señales tienen perfiles de costo muy distintos, y entenderlos evita sorpresas en la factura y en el rendimiento de la plataforma. La tabla resume los equilibrios principales.

Señal	Pregunta que responde	Cardinalidad tolerada	Costo principal	Retención típica
Métricas	¿Hay un problema, cuánto y desde cuándo?	Baja: etiquetas acotadas y conocidas	Número de series temporales	Larga (meses), con agregación
Trazas	¿En qué tramo está el problema?	Alta: atributos por solicitud	Número de spans almacenados	Corta o media, con muestreo
Logs	¿Qué pasó exactamente y por qué?	Muy alta: texto y campos libres	Volumen ingerido e indexado	Variable, según uso y exigencia regulatoria

De la tabla salen algunas reglas prácticas. Los datos de alta cardinalidad (identificador de cliente, de transacción, de sesión) van en atributos de spans y en campos de logs, no en etiquetas de métricas. Las métricas se diseñan pensando en las preguntas recurrentes; las trazas y los logs, en las preguntas que todavía no sabes que vas a hacer. Y la retención se define por señal: no tiene sentido conservar todos los logs de depuración el mismo tiempo que los registros que exige auditoría.

En sectores regulados, la retención de logs no es solo una decisión de costo. Algunos registros tienen exigencias de conservación e integridad propias, y conviene separarlos desde el diseño de los logs operativos, cuyo valor cae rápido después de unos días.

La correlación es lo que convierte señales en diagnóstico

Tener las tres señales no garantiza nada si viven en silos. El escenario que más tiempo consume en un incidente es el de un equipo que ve la alerta en un panel, busca en otra herramienta los logs del mismo minuto, filtra por servidor y trata de adivinar cuáles corresponden a las solicitudes afectadas. La correlación elimina esa adivinanza.

Correlacionar significa que las señales comparten identificadores y contexto:

• Los logs llevan trace_id y span_id, así que desde una traza lenta se llega a los logs exactos de esa solicitud.
• Las métricas y las trazas comparten los mismos atributos de recurso (nombre del servicio, versión, entorno, host), así que desde un pico en un panel se llega a trazas de ejemplo de ese mismo servicio y momento.
• El contexto de traza se propaga entre servicios (por ejemplo, con el estándar W3C Trace Context en las cabeceras HTTP), así que la traza no se corta en cada salto.

OpenTelemetry, el proyecto abierto de la Cloud Native Computing Foundation, se diseñó con esta idea: un modelo común de contexto y de atributos de recurso para las tres señales, con convenciones semánticas que fijan cómo nombrar atributos frecuentes. Por eso conviene adoptarlo como base de la instrumentación aunque la plataforma de análisis sea otra.

Una señal aislada describe un síntoma. Tres señales correlacionadas describen un incidente.

Cómo decidir qué señal usar

Para cada necesidad de visibilidad, recomendamos recorrer estas preguntas en orden:

1. ¿La pregunta se repite y necesita alerta o tendencia? Usa una métrica, con etiquetas de baja cardinalidad.
2. ¿La pregunta es sobre dónde se va el tiempo o dónde nace un error en un flujo que cruza componentes? Usa trazas, con atributos que identifiquen la operación de negocio.
3. ¿Necesitas el detalle de un evento concreto, con sus datos y su causa? Usa un log estructurado, correlacionado con la traza activa.
4. ¿Necesitas saltar de una señal a otra? Verifica que compartan identificadores y atributos de recurso. Si no, corrige eso antes de agregar más datos.
5. ¿El dato es sensible o de alta cardinalidad? Decide dónde vive, cuánto tiempo se conserva y quién lo ve, antes de emitirlo.

Este recorrido evita los dos extremos habituales: instrumentar todo "por si acaso", con costos que crecen sin control, o instrumentar solo lo que la plataforma captura sola, con huecos justo donde están las reglas de negocio. El objetivo no es acumular telemetría, sino reducir el tiempo entre "algo está mal" y "sabemos por qué".