En un sistema distribuido moderno, una petición de usuario puede atravesar veinte microservicios, tres colas de mensajería y dos bases de datos antes de devolver una respuesta. Cuando esa petición falla o tarda demasiado, el equipo de operaciones necesita responder en minutos, no en horas. La observabilidad es la disciplina que hace posible esa respuesta: la capacidad de entender el estado interno de un sistema a partir de las señales que emite hacia el exterior. Este artículo desarrolla los tres pilares de la observabilidad (logs, métricas y trazas), las herramientas de referencia para implementarlos y los errores que separan un sistema instrumentado de uno realmente observable.
El término procede de la teoría de control: un sistema es observable si su estado interno puede deducirse a partir de sus salidas. Trasladado al software, significa que ante un comportamiento inesperado deberíamos poder explicar la causa sin necesidad de añadir instrumentación nueva ni reproducir el problema en un entorno controlado. Esa es la diferencia clave frente a la depuración tradicional, que asume que el fallo puede reproducirse a voluntad: en producción distribuida, muchos incidentes son irrepetibles y solo dejan rastro en la telemetría que se capturó en el momento exacto en que ocurrieron.
Los tres pilares de la observabilidad
Conviene distinguir monitorización de observabilidad. La monitorización clásica responde a preguntas que ya sabías formular: ¿está la CPU por encima del 80 %? ¿hay errores HTTP 500? La observabilidad va más allá y permite responder a preguntas que nunca anticipaste durante el diseño, explorando los datos telemétricos sin tener que desplegar código nuevo. Esa propiedad se sostiene sobre tres tipos de señales complementarias.
Las métricas son valores numéricos agregados en el tiempo (peticiones por segundo, latencia del percentil 99, uso de memoria). Son baratas de almacenar y permiten alertas en tiempo real, pero pierden el detalle de cada evento individual. Los logs son registros discretos de eventos, idealmente estructurados en JSON con campos consultables; ofrecen el máximo detalle pero su volumen y coste crecen rápido. Las trazas distribuidas siguen el recorrido completo de una petición a través de todos los servicios, asignando un trace_id común y midiendo el tiempo consumido en cada tramo o span. La combinación de los tres permite pasar de "algo va mal" (métrica) a "esta petición concreta falló aquí" (traza) y "este es el mensaje de error exacto" (log).
Stack de logs: la familia Elastic (ELK)
El ELK Stack sigue siendo la referencia para la gestión centralizada de logs. Lo componen Elasticsearch (motor de búsqueda y almacenamiento basado en índices invertidos), Logstash o los más ligeros agentes Beats para la ingesta, y Kibana para la visualización. Un patrón habitual envía los logs de cada contenedor mediante Filebeat hacia un pipeline de Logstash que los parsea con expresiones grok, normaliza marcas de tiempo y enriquece con metadatos (nombre del servicio, versión, entorno) antes de indexarlos.
La clave de un buen sistema de logs es el logging estructurado. Un log de texto plano como Error procesando pedido 4521 es difícil de consultar; el equivalente estructurado {"level":"error","event":"order_failed","order_id":4521,"service":"checkout"} permite filtrar, agregar y correlacionar. Conviene definir niveles coherentes (DEBUG, INFO, WARN, ERROR), aplicar políticas de retención por índice mediante Index Lifecycle Management (datos calientes en SSD los primeros días, datos fríos en almacenamiento barato después) y, sobre todo, evitar registrar datos personales en claro: el Reglamento General de Protección de Datos exige minimización y seudonimización, y los logs son una de las fugas de datos personales más frecuentes y olvidadas.
Métricas y alertas con Prometheus
Prometheus domina el espacio de métricas en entornos cloud-native. Su modelo es de tipo pull: el servidor consulta periódicamente endpoints HTTP /metrics expuestos por cada servicio. Almacena series temporales identificadas por un nombre y un conjunto de etiquetas clave-valor, y se consultan con PromQL, un lenguaje pensado para agregaciones temporales. Una expresión como histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) devuelve la latencia del percentil 99 en los últimos cinco minutos.
La visualización se delega habitualmente en Grafana, que combina datos de Prometheus, Elasticsearch y otras fuentes en cuadros de mando unificados. Las alertas se gestionan con Alertmanager, que agrupa, silencia y enruta las notificaciones para evitar la fatiga de alertas: el fenómeno por el que un equipo recibe tantos avisos irrelevantes que termina ignorando también los importantes. Una buena regla de alerta no se basa en umbrales arbitrarios de CPU, sino en síntomas que el usuario percibe, formalizados como SLO (Service Level Objectives) y su consumo de error budget, según la práctica de ingeniería de fiabilidad descrita en el cuerpo de conocimiento SRE de Google.
Trazabilidad distribuida y el estándar OpenTelemetry
La pieza que cierra el círculo es la traza distribuida, y aquí el estándar de facto es OpenTelemetry (OTel), proyecto de la Cloud Native Computing Foundation. OpenTelemetry unifica la instrumentación de logs, métricas y trazas bajo una única API y un protocolo común (OTLP), de modo que el código de la aplicación no queda atado a un proveedor concreto. Backends como Jaeger, Tempo o soluciones comerciales consumen esa telemetría sin que haya que reinstrumentar. Esta neutralidad es estratégica: cambiar de proveedor de observabilidad sin OpenTelemetry implica reescribir la instrumentación de cientos de servicios; con OpenTelemetry basta con reapuntar el exportador.
El concepto central es la propagación de contexto: cuando el servicio A llama al servicio B, transmite el trace_id en las cabeceras (estándar W3C Trace Context). Así, el backend puede reconstruir el árbol completo de spans y mostrar exactamente dónde se consumió el tiempo. Esto convierte la depuración de latencia en sistemas con decenas de servicios en una tarea visual en lugar de una arqueología de logs. Una buena instrumentación añade además atributos semánticos a cada span (código de respuesta, identificador de usuario seudonimizado, versión de despliegue), lo que permite filtrar y comparar trazas por características de negocio y no solo por servicio.
Cardinalidad, volumen y control de costes
El error operativo que más facturas dispara en observabilidad es la explosión de cardinalidad. En Prometheus, cada combinación única de etiquetas crea una serie temporal independiente; añadir como etiqueta un identificador de alta variabilidad (el ID de usuario, una URL con parámetros, un UUID) puede generar millones de series y tumbar el servidor. La regla práctica es reservar las etiquetas para dimensiones de baja cardinalidad y acotadas (servicio, entorno, código de estado, región) y dejar la información de alta variabilidad para logs o trazas, donde se almacena de otra forma.
En logs ocurre el equivalente con el volumen bruto: registrar en nivel DEBUG en producción o volcar cuerpos de petición completos puede multiplicar por diez la ingesta y el coste de indexación. Las palancas para controlarlo son el muestreo (conservar el 100 % de los errores pero solo una fracción de los eventos normales), las políticas de retención escalonadas por antigüedad y la separación entre el almacenamiento de logs accesibles para búsqueda y el archivo frío barato para cumplimiento. Medir el coste por servicio y por gigabyte ingerido, y revisarlo periódicamente, evita la sorpresa de una factura cloud que crece más rápido que el propio sistema.
Tabla comparativa de los tres pilares
| Dimensión | Métricas | Logs | Trazas |
|---|---|---|---|
| Pregunta que responde | ¿Qué está pasando? | ¿Por qué pasó? | ¿Dónde pasó? |
| Coste de almacenamiento | Bajo | Alto | Medio (con muestreo) |
| Granularidad | Agregada | Por evento | Por petición |
| Idónea para alertas | Sí | Limitada | No directamente |
| Herramienta de referencia | Prometheus + Grafana | ELK Stack | Jaeger / Tempo + OTel |
Implementación por fases
Un despliegue ordenado evita la trampa habitual de instrumentar todo a la vez y ahogarse en datos. Una secuencia razonable es: (1) centralizar los logs estructurados de todos los servicios en un único destino consultable; (2) exponer las cuatro métricas doradas (latencia, tráfico, errores y saturación) en cada servicio; (3) definir SLO realistas a partir de datos reales y configurar alertas basadas en error budget; (4) instrumentar trazas con OpenTelemetry en los flujos críticos de negocio; y (5) correlacionar los tres pilares mediante identificadores comunes para poder saltar de una métrica anómala a la traza y al log exacto en dos clics.
Errores comunes que conviene evitar
El primero es alertar sobre causas en vez de síntomas: una alerta de CPU al 90 % no significa nada si el usuario sigue recibiendo respuestas rápidas, y satura al equipo de guardia. El segundo es el logging sin estructura ni retención, que dispara la factura de almacenamiento y deja datos personales expuestos. El tercero es instrumentar sin muestreo en trazas de alto volumen, lo que genera costes y ruido; el muestreo basado en colas, que conserva siempre las trazas con errores o latencia alta, resuelve el problema. El cuarto es confiar en cuadros de mando que nadie mira: la observabilidad solo aporta valor si está integrada en los runbooks de incidentes y en la cultura del equipo.
Preguntas frecuentes
¿Cuál es la diferencia entre monitorización y observabilidad?
La monitorización comprueba condiciones predefinidas (umbrales, comprobaciones de salud). La observabilidad permite explorar el sistema y responder a preguntas nuevas sin desplegar código, gracias a la riqueza de logs, métricas y trazas correlacionados.
¿Necesito Prometheus y ELK a la vez, o puedo elegir solo uno?
Resuelven problemas distintos: Prometheus para métricas y alertas en tiempo real, ELK para análisis detallado de logs. En la mayoría de arquitecturas serias conviven, normalmente unidos por Grafana como capa de visualización común.
¿Qué son las "cuatro métricas doradas"?
Latencia, tráfico, tasa de errores y saturación. Son el conjunto mínimo recomendado por la ingeniería de fiabilidad para entender la salud de cualquier servicio orientado a usuarios.
¿OpenTelemetry sustituye a Prometheus y al ELK Stack?
No los sustituye, los unifica en la capa de instrumentación. OpenTelemetry recoge las señales de forma neutral y las envía a los backends que prefieras (Prometheus, Tempo, Elasticsearch), evitando el bloqueo con un proveedor concreto.
Conclusión
La observabilidad no es un panel bonito ni una herramienta que se compra: es una propiedad del sistema que se diseña desde el primer commit. Un equipo con logs estructurados, métricas alineadas con SLO y trazas distribuidas con OpenTelemetry reduce drásticamente el tiempo medio de detección y resolución de incidentes (MTTD y MTTR), que son las métricas que de verdad determinan la fiabilidad percibida. La inversión no se justifica por el ahorro genérico, sino por algo concreto: cuando ocurre el incidente a las tres de la mañana, la diferencia entre cinco minutos y cinco horas de diagnóstico la marca haber instrumentado bien antes de necesitarlo. En Summum Marketing diseñamos arquitecturas de observabilidad partiendo de los flujos de negocio críticos, no del catálogo de herramientas, para que cada señal que se recoge tenga una pregunta concreta que responder.