Observabilidad: logs, métricas y trazas

Monitorización y observabilidad

La monitorización consiste en recoger mediciones y comprobaciones predefinidas y dar la alarma cuando cruzan un umbral: disco lleno al 90%, tasa de errores por encima del 1%, comprobación de estado que falla. Responde a preguntas que sabías de antemano que había que hacer. La observabilidad es una propiedad del sistema: lo bien que puedes entender su estado interno, incluidos estados que nadie predijo, a partir de la telemetría que ya emite, sin desplegar código nuevo para averiguarlo. La palabra viene de la teoría de control, donde Rudolf Kálmán la definió en 1960 como la capacidad de inferir el estado interno de un sistema a partir de sus salidas.

La distinción importa porque los sistemas distribuidos fallan sobre todo de formas nuevas. Un pedido de reparto de comida puede ir lento porque la app de tableta de un restaurante reintenta de forma agresiva, porque el endpoint de un proveedor de pagos en una región está degradado, o porque una nueva funcionalidad de la carta hace que una consulta sea lenta solo para los restaurantes con más de 500 platos. Nadie creó un panel para ninguno de estos casos. La monitorización te dice que el proceso de pago va lento; la observabilidad te permite preguntar para quién, dónde y por qué, segmentando la telemetría por cualquier atributo hasta que aparece el patrón.

Los profesionales no se ponen de acuerdo sobre hasta dónde llega la distinción. Una visión, común entre los proveedores de herramientas, trata la observabilidad como un paraguas sobre tres pilares: logs, métricas y trazas. Charity Majors, Liz Fong-Jones y George Miranda (Observability Engineering, O'Reilly, 2022) sostienen que el enfoque de los pilares pierde de vista lo esencial, y que la observabilidad requiere eventos estructurados, ricos y de alta cardinalidad que puedan consultarse en combinaciones arbitrarias. Ambos bandos coinciden en la consecuencia arquitectónica: la observabilidad es un atributo de calidad que debe incorporarse desde el diseño, mediante una instrumentación coherente, identificadores compartidos y propagación de contexto, porque no se puede añadir a posteriori en mitad de un incidente.

Logging estructurado (structured logging)

Una línea de log como Payment failed for order 81F3 after 3001ms es fácil de escribir y difícil de usar: cada consulta necesita una expresión regular frágil, y cada desarrollador redacta las cosas de forma distinta. El logging estructurado escribe cada entrada como campos clave-valor, normalmente en JSON, con nombres acordados: marca de tiempo, nivel, servicio, nombre del evento, identificadores de negocio (pedido, restaurante, repartidor), resultado, duración y los identificadores de traza y de span que enlazan la línea con su traza. Las consultas se vuelven precisas (todos los eventos card_authorisation_failed del proveedor cardco en la última hora, agrupados por http_status), y los logs de distintos servicios pueden combinarse.

Unas pocas reglas mantienen los logs útiles y asequibles. Registra eventos, no prosa; usa un nombre de evento fijo para cada tipo de evento. Usa los niveles de forma coherente, y no registres con nivel de error condiciones sobre las que nadie necesita actuar. Nunca registres secretos, tokens, números de tarjeta completos ni datos personales innecesarios; los pipelines de telemetría se copian, se envían a terceros y se conservan durante meses, así que son una fuente habitual de fugas de datos, y los datos personales en los logs están sujetos al RGPD (GDPR) como cualquier otra copia (Sección 8.7). El logging y la detección de seguridad, un propósito relacionado pero distinto, con sus propias necesidades de retención e integridad, se tratan en la Sección 8.8.

traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
             version-trace id (16 bytes)-parent span id (8 bytes)-flags (01 = sampled)

{"ts": "2026-10-22T12:31:07.412Z", "level": "error",
 "service": "payment-service", "event": "card_authorisation_failed",
 "order_id": "ord_81F3", "provider": "cardco", "http_status": 504,
 "duration_ms": 3001, "attempt": 2,
 "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736", "span_id": "00f067aa0ba902b7"}

Las métricas y por qué los percentiles no pueden promediarse

La mayoría de los sistemas de métricas, como Prometheus (un proyecto graduado de la CNCF) y el modelo de métricas de OpenTelemetry, ofrecen los mismos pocos tipos. Un contador (counter) solo aumenta, como el total de solicitudes atendidas; se lee como una tasa (solicitudes por segundo durante los últimos cinco minutos), lo que además sobrevive a los reinicios. Un gauge (indicador) es un valor actual que sube y baja: longitud de la cola, conexiones en uso, memoria. Un histograma cuenta las observaciones en buckets (por ejemplo, solicitudes de menos de 50 ms, de menos de 100 ms, de menos de 250 ms, etc.) más un recuento total y una suma, a partir de los cuales se estiman los percentiles. Prometheus también tiene un tipo summary (resumen) que calcula cuantiles dentro de cada proceso.

La distinción entre histogramas y summaries no es un detalle. Como señaló la Sección 2.4, un percentil es una propiedad de toda una distribución, y el percentil de una distribución combinada no puede calcularse a partir de los percentiles de sus partes. Promediar valores p99 entre servidores, o entre minutos, produce un número que no es el percentil de nada. Los recuentos de los buckets, en cambio, pueden simplemente sumarse: se suma cada bucket en todos los servidores y luego se estima el percentil a partir del histograma combinado. Por eso los SLI de latencia de toda la flota deben construirse sobre histogramas (o sobre recuentos de solicitudes por debajo de un umbral, como en la Sección 9.5), nunca sobre summaries por instancia.

Qué medir: RED, USE y las señales doradas

Tres listas de comprobación breves cubren la mayor parte de lo que un servicio debe exponer. El método RED, propuesto por Tom Wilkie en 2015, se aplica a todo lo que atiende solicitudes: Rate (tasa: solicitudes por segundo), Errors (errores: solicitudes fallidas por segundo) y Duration (duración: la distribución de los tiempos de respuesta). El método USE, de Brendan Gregg, se aplica a los recursos: para cada CPU, disco, enlace de red, pool de conexiones y cola, comprueba la Utilisation (utilización: lo ocupado que está), la Saturation (saturación: cuánto trabajo espera) y los Errors (errores). Las cuatro señales doradas del capítulo del libro de SRE de Google sobre la monitorización de sistemas distribuidos son la latencia, el tráfico, los errores y la saturación: en la práctica, RED más saturación.

En la práctica, RED describe lo que experimentan los usuarios y USE explica por qué. Si sube la duración del servicio de pagos (RED), USE aplicado a sus recursos podría mostrar un pool de conexiones al 100% de utilización con 40 solicitudes esperando (saturación), lo que a su vez apunta al lento proveedor de tarjetas que mantiene las conexiones abiertas. Mide la latencia por separado para los éxitos y los fallos: un error rápido no es buena latencia, y un timeout es a la vez un error y una respuesta lenta.

Trazado distribuido

En un monolito, una traza de pila (stack trace) muestra dónde pasó su tiempo una solicitud lenta. Entre servicios no hay una única pila. El trazado distribuido reconstruye una: cada solicitud recibe un identificador de traza en el borde, cada unidad de trabajo se convierte en un span (con un nombre, una hora de inicio, una duración, un estado, atributos y el identificador de su span padre), y un backend de trazado ensambla los spans en un árbol. El artículo de Google sobre Dapper (Sigelman y colaboradores, 2010) describió el enfoque a escala: baja sobrecarga, instrumentación en bibliotecas compartidas en lugar de en el código de la aplicación, y muestreo para que solo se registre una fracción de las solicitudes.

El trazado depende por completo de la propagación de contexto: cada servicio debe pasar el contexto de traza al siguiente. La especificación W3C Trace Context (Recomendación del W3C desde 2020) lo estandariza para HTTP con una cabecera traceparent que contiene una versión, un ID de traza de 16 bytes, el ID de 8 bytes del span que llama y flags como si la traza está muestreada, más una cabecera opcional tracestate para datos del proveedor. En la mensajería, los mismos valores viajan en las cabeceras de los mensajes, y el span del consumidor hace referencia al del productor. Un solo servicio que pierda la cabecera (una biblioteca antigua, un cliente HTTP escrito a mano, un trabajo por lotes) rompe todas las trazas que pasan por él, y por eso la propagación corresponde a las bibliotecas compartidas de la plataforma, no al código de cada equipo.

Registrar cada span de cada solicitud es caro a escala, así que las trazas se muestrean. El muestreo al inicio (head-based sampling) decide al comienzo de la solicitud (conservar 1 de cada 100) y es barato, pero descarta la mayoría de las solicitudes lentas y fallidas, poco frecuentes, que te interesan. El muestreo al final (tail-based sampling) guarda los spans en un búfer hasta que la solicitud termina y luego conserva todos los errores, todas las solicitudes más lentas que un umbral y una pequeña fracción del resto; necesita más memoria en el collector, pero conserva las trazas interesantes.

OpenTelemetry: un estándar para la instrumentación

Hasta aproximadamente 2019, cada proveedor de trazado y monitorización tenía sus propios agentes y bibliotecas, así que cambiar de proveedor significaba volver a instrumentar todos los servicios. OpenTelemetry (OTel) se formó en 2019 al fusionar dos proyectos de código abierto anteriores, OpenTracing y OpenCensus, bajo la Cloud Native Computing Foundation (CNCF), y se graduó como proyecto de la CNCF en mayo de 2026. Proporciona API y SDK para los distintos lenguajes, instrumentación automática para frameworks y clientes habituales, el protocolo de transmisión OTLP, el Collector y unas convenciones semánticas que fijan nombres de atributos como http.request.method y http.response.status_code para que la telemetría de distintos equipos y lenguajes encaje. Las trazas, las métricas y los logs son estables; los perfiles se añadieron como cuarta señal y entraron en alfa pública en 2026.

El valor arquitectónico está en separar la instrumentación del backend. Los servicios emiten OTLP a un Collector, que normalmente se ejecuta junto a cada nodo o como gateway central; el Collector agrupa en lotes, muestrea, elimina atributos sensibles, añade metadatos como la versión desplegada y exporta a los almacenes que use la organización. Cambiar de proveedor, o enviar los mismos datos a dos backends durante una migración, pasa a ser un cambio de configuración del Collector en lugar de un cambio de código en doscientos servicios. Un equipo de plataforma suele proporcionar la configuración del SDK, la propagación y el Collector como un camino pavimentado (paved road), para que los equipos de producto solo añadan atributos de negocio.

from opentelemetry import trace
import structlog

tracer = trace.get_tracer("order-service")
log = structlog.get_logger()

def place_order(order):
    with tracer.start_as_current_span("place_order") as span:
        span.set_attribute("restaurant.id", order.restaurant_id)
        span.set_attribute("order.item_count", len(order.items))
        quote = pricing.quote(order)       # instrumented HTTP client adds
        payment.authorise(order, quote)    # the traceparent header itself
        log.info("order_placed", order_id=order.id,
                 total_pence=quote.total_pence)
        return order.id

Cardinalidad y costo

La telemetría puede costar fácilmente más que el sistema que observa. En las métricas, el factor principal es la cardinalidad: cada combinación distinta de valores de etiqueta es una serie temporal separada que hay que almacenar e indexar. Las etiquetas con pocos valores (método HTTP, clase de estado, región) no son problema. Las etiquetas con valores no acotados (ID de usuario, ID de pedido, URL completa con identificadores, texto del mensaje de error) multiplican las series sin límite y pueden tumbar un sistema de métricas.

Otras palancas de costo son muestrear las trazas (el muestreo al final conserva las útiles), una retención más corta para los datos detallados y más larga para los agregados, descartar por defecto los logs de depuración en producción, e imputar el costo de la telemetría a los equipos que la generan para que sea visible. Trata el volumen de telemetría como un parámetro de diseño con un presupuesto, como cualquier otro recurso.

Alertar sobre síntomas, no sobre causas

La pauta del libro de SRE es que los avisos a la persona de guardia deben referirse a síntomas que notan los usuarios, no a las muchas causas posibles. Una CPU alta, un disco lleno en una réplica o un contenedor reiniciado son causas: a menudo inofensivas, a veces ya resueltas por la automatización, y nunca una lista completa de lo que puede fallar. Un SLO que se consume, procesos de pago que fallan o un pipeline de posiciones de repartidores detenido son síntomas: importan sea cual sea su causa. Las alertas basadas en síntomas son menos, rara vez son falsas y cubren fallos que nadie predijo; las señales basadas en causas corresponden a paneles que ayudan a diagnosticar un síntoma una vez que se ha avisado de él.

Cada aviso debe ser urgente, accionable y real. La fatiga de alertas es en sí misma un riesgo para la fiabilidad: los ingenieros de guardia a los que despiertan alertas sin sentido aprenden a descartarlas y pasan por alto la que importa. Una regla práctica es avisar por las tasas de consumo del SLO (Sección 9.5), enviar los consumos más lentos y las advertencias sobre recursos a una cola de tickets, y enlazar cada aviso con un runbook (manual de operaciones) y un panel.

Paneles que responden preguntas

Un muro de cincuenta gráficos no responde rápido a ninguna pregunta. Los buenos paneles se diseñan como cualquier interfaz de usuario: para un público concreto y una pregunta específica. Una vista general del servicio responde a ¿está sano este servicio? con sus SLO, el presupuesto de errores restante y las métricas RED arriba, y las métricas USE de sus recursos clave debajo. Un panel de recorrido para la puesta a la venta responde a ¿están consiguiendo entradas los fans? con las admisiones, las reservas de asientos, los pagos y los fallos por minuto de extremo a extremo. A los paneles de diagnóstico se llega profundizando; no se muestran primero.

Guarda los paneles en el control de versiones como código, asigna a cada uno un propietario, muestra los despliegues y los cambios de feature flags como anotaciones en los gráficos (la mayoría de los incidentes siguen a un cambio) y elimina los paneles que nadie ha abierto en meses. Durante un incidente, la primera vista útil suele ser el recorrido orientado al usuario, la segunda la traza de una solicitud que falla, y solo después las métricas de recursos.