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

Qué es

La observabilidad (observability) se apoya en tres tipos de señales que OpenTelemetry define de forma unificada. Un log es un registro con marca de tiempo sobre un evento, con campos arbitrarios; el modelo de datos de OpenTelemetry prevé, entre otros, los campos TraceId y SpanId, de modo que una entrada de log pueda asignarse a la solicitud en la que se originó. Una métrica es una serie temporal numérica; la documentación distingue instrumentos como Counter (solo aumenta, como un cuentakilómetros), UpDownCounter (sube y baja, por ejemplo la longitud de una cola), Gauge (valor actual en el momento de la lectura) e Histogram (distribución, por ejemplo de los tiempos de respuesta). Una traza representa una solicitud como un árbol de spans, cada uno con inicio, duración, atributos y span padre, y la Context Propagation transmite el identificador de traza mediante cabeceras a los servicios posteriores.

Por qué importa

Cada señal responde a una pregunta distinta y ninguna sustituye a las demás. Las métricas son baratas de almacenar y consultar, y sirven para las alertas: «tasa de errores superior al dos por ciento durante los últimos cinco minutos». Pero no dicen qué solicitud se vio afectada. Las trazas muestran, para una solicitud concreta, dónde se fue el tiempo: la base de datos, un servicio externo o una llamada secuencial que podría ser paralela. Los logs contienen el texto exacto del error y los valores que lo provocaron. Solo el identificador compartido convierte tres herramientas en una investigación: de la alerta a una solicitud de ejemplo y de ahí a la entrada de log.

Cómo aplicarlo

• Empezar por la pregunta, no por la herramienta: para «¿está sano el servicio?» bastan unas pocas métricas (solicitudes, errores, duración, saturación); para «¿por qué es lenta esta solicitud?» se necesitan trazas; para «¿qué contenía la entrada?» hacen falta logs.
• Instrumentar primero las fronteras: solicitudes HTTP entrantes, llamadas salientes y accesos a la base de datos; las bibliotecas suelen proporcionarlo automáticamente.
• Limitar las etiquetas (labels) de las métricas a pocos valores (endpoint, clase de estado) y nunca usar identificadores de usuario u objeto: cada combinación es una serie temporal propia.
• Escribir el identificador de traza en cada registro de log y propagarlo a los servicios posteriores; sin propagación, la traza termina en el primer límite entre servicios.
• Con un volumen alto, conservar las trazas mediante muestreo: si se decide al principio, el muestreo es barato; si se decide una vez finalizada la traza, se pueden conservar completas las solicitudes erróneas y lentas.
• Definir la retención por señal: las métricas, durante mucho tiempo y agregadas; los logs, durante menos tiempo, y las trazas, durante el menor tiempo.

Trampas

Usar logs de alta frecuencia como sustituto de las métricas («una línea por solicitud y luego contamos») no escala y cuesta dinero en cada consulta. Un histograma que solo exporta promedios pierde los valores atípicos que los usuarios sí perciben. Las trazas sin atributos (código de estado, número de filas, acierto de cache) solo responden al «dónde», no al «por qué». Recopilarlo todo sin tener una pregunta genera costes, no conocimiento.