Observabilidad

Por qué no basta con monitorizar

La monitorización responde a preguntas que se conocían de antemano: ¿está arriba el servicio?, ¿cuánta CPU usa?, ¿cuántos errores por minuto hay? Se define un conjunto de comprobaciones y se avisa cuando una se sale de lo esperado. Funciona bien para los fallos que ya se han visto.

La observabilidad es la capacidad de entender el estado interno de un sistema a partir de lo que emite hacia fuera, incluidas las preguntas que no se habían previsto. Un sistema distribuido falla de maneras nuevas: un servicio lento que degrada a otro, un cliente concreto con un dato extraño, una combinación de versiones. Para investigarlo hace falta telemetría rica, con suficiente contexto como para filtrar y agrupar por cualquier dimensión.

Una complementa a la otra: se monitoriza lo conocido y se observa para poder entender lo demás.

Las señales de telemetría

Se suelen hablar de tres señales, y cada vez más de una cuarta.

Su valor real aparece al correlacionarlas: una alerta de una métrica lleva a una traza de ejemplo, y de ahí a los logs de ese mismo identificador de petición. Si hay que saltar entre herramientas copiando horas y nombres, la investigación se alarga.

Logs bien hechos

Un log útil es un evento estructurado, no una frase para leer a ojo. En JSON (o en otro formato con campos) se puede filtrar, agregar y correlacionar con facilidad.

{
  "timestamp": "2026-03-14T10:42:17.381Z",
  "level": "error",
  "service": "pedidos",
  "version": "2.8.1",
  "env": "produccion",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "span_id": "00f067aa0ba902b7",
  "request_id": "req-7f3a9c",
  "event": "pago_rechazado",
  "message": "El proveedor de pagos rechazó el cargo",
  "order_id": "ord-10293",
  "provider": "pasarela-a",
  "status_code": 402,
  "duration_ms": 812
}

Niveles

Reglas

• Una línea, un evento, con campos estables y nombres coherentes en todos los servicios.
• Incluir siempre identificadores de correlación (petición, traza) y contexto: servicio, versión, entorno.
• Loguear qué ha pasado y con qué datos relevantes, no «error» a secas.
• No registrar datos personales ni secretos: contraseñas, tokens, números de tarjeta. Enmascarar o excluir esos campos en origen.
• No usar logs como sustitutos de métricas: contar eventos buscando texto es caro y frágil.
• Escribir a la salida estándar y dejar que la plataforma recoja y envíe.
• Controlar el volumen y la retención: lo que no se consulta, se muestrea o se descarta.
• Registrar el error una vez, donde se gestiona, y no en cada capa por la que sube.

Métricas: tipos y cardinalidad

Una métrica es una serie temporal identificada por un nombre y un conjunto de etiquetas.

Cardinalidad

Cada combinación única de valores de etiquetas crea una serie nueva. Con etiquetas de valores acotados (método, código de estado, ruta con plantilla) el coste es controlado; con etiquetas de valores casi ilimitados (identificador de usuario, URL con parámetros, identificador de petición) el número de series se dispara y el almacén se degrada o se vuelve carísimo.

Qué medir: RED, USE y las cuatro señales de oro

Medir todo no sirve; hay que empezar por un marco.

Las cuatro señales de oro vienen del enfoque SRE: la latencia debe separar las peticiones correctas de las fallidas (un error rápido no es una respuesta buena); el tráfico mide la demanda; los errores incluyen fallos explícitos y también respuestas «correctas» con contenido erróneo; la saturación indica cuánto falta para agotar el recurso más limitante.

Percentiles frente a medias

La media oculta lo que sufren los usuarios. Si el 99 % de las peticiones tarda 100 ms y el 1 % tarda 10 segundos, la media parece aceptable mientras uno de cada cien usuarios tiene una experiencia pésima. Los percentiles (p50, p95, p99) describen la distribución: la mediana es la experiencia típica y las colas altas son la de los casos peores. Además:

• Los percentiles no se pueden promediar entre instancias; se agregan los histogramas y se calcula después.
• En servicios que hacen muchas llamadas por petición, las colas de los componentes se amplifican en el total.
• Los intervalos del histograma deben elegirse alrededor de los valores que importan, por ejemplo cerca del objetivo de latencia.

Trazas distribuidas

Una traza es el recorrido completo de una petición; está formada por spans, cada uno un tramo con su inicio, duración, atributos y relación padre-hijo. Para unir spans de servicios distintos hay que propagar el contexto: el identificador de traza y del span actual viajan en cabeceras (el estándar W3C Trace Context define traceparent) o en los mensajes de una cola.

• Permiten ver el camino crítico y qué llamada domina la latencia.
• Descubren bucles de consultas a la base de datos (el patrón N+1), llamadas en serie que podrían ir en paralelo y dependencias inesperadas.
• Los atributos del span (ruta, usuario anonimizado, versión, resultado) permiten filtrar y comparar.
• Los eventos y los errores se asocian al span donde ocurren.

Muestreo

Guardar todas las trazas suele ser inviable. El muestreo decide cuáles conservar:

Una política común es conservar todas las trazas con error o muy lentas y una fracción de las normales.

OpenTelemetry

OpenTelemetry (OTel) es el estándar abierto para generar y transportar telemetría, con independencia del proveedor. Sus piezas:

• API y SDK por lenguaje: la API es lo que usa el código; el SDK implementa la recogida y exportación.
• Instrumentación automática para librerías y frameworks habituales (HTTP, bases de datos, colas), más instrumentación manual para el negocio.
• Convenciones semánticas: nombres estándar de atributos (por ejemplo, para HTTP o bases de datos) que hacen las trazas comparables entre servicios.
• OTLP: el protocolo de transporte común para trazas, métricas y logs.
• Collector: un proceso intermedio que recibe, procesa (filtra, enriquece, muestrea, reduce cardinalidad) y reenvía a uno o varios destinos.

La ventaja estratégica es desacoplar el código del destino: se puede cambiar de proveedor o enviar a varios modificando la configuración del collector, sin tocar las aplicaciones.

Herramientas habituales por categoría

No hay que adoptar todo a la vez. Un punto de partida razonable es métricas con alertas, logs estructurados centralizados y un seguimiento de errores; las trazas se añaden cuando hay varios servicios que depurar.

SLI, SLO, SLA y presupuesto de error

La clave es que el 100 % no es un objetivo razonable: cuesta cada vez más y deja de ser perceptible para el usuario. El presupuesto convierte la fiabilidad en una decisión de producto: mientras queda presupuesto se puede arriesgar y lanzar cambios; si se agota, se prioriza la estabilidad sobre las funcionalidades nuevas.

Buenos SLI: disponibilidad (proporción de peticiones correctas), latencia (proporción más rápida que un umbral), calidad o frescura de datos, y éxito de recorridos de usuario clave. Se eligen pocos y significativos, medidos lo más cerca posible del usuario.

Alertas que valen la pena

Una alerta urgente es una interrupción a una persona, y por eso debe cumplir tres condiciones: ser accionable (hay algo que hacer ahora), urgente (no puede esperar a mañana) y relevante (afecta o va a afectar al usuario).

• Alertar por síntomas (los usuarios ven errores o lentitud) y no por causas (la CPU está alta). Las causas se consultan en el panel durante la investigación.
• Cada alerta enlaza a un runbook con qué comprobar y cómo mitigar.
• Lo no urgente va a un ticket o canal, no al teléfono de la guardia.

Burn rate (velocidad de consumo)

Alertar cuando el presupuesto de error se consume demasiado deprisa es más útil que un umbral fijo. El burn rate mide cuántas veces más rápido que lo sostenible se está gastando el presupuesto: un burn rate de 1 lo agotaría justo al final de la ventana. Un esquema habitual combina varias ventanas: una ventana corta y una larga con burn rate alto para avisar de incidentes graves a tiempo, y ventanas más largas con burn rate bajo para detectar degradaciones lentas. Exigir que ambas ventanas (larga y corta) se cumplan reduce los falsos positivos y el aviso se apaga solo al recuperarse.

Fatiga de alertas

Cuando casi todas las alertas son ruido, las personas dejan de reaccionar y se pierden las importantes. Para combatirla: revisar cada aviso tras cada guardia, eliminar o degradar los que no requirieron acción, agrupar alertas relacionadas, añadir duración mínima antes de disparar y evitar duplicados entre herramientas.

Paneles útiles

Un panel debe contar una historia y responder a una pregunta, no exhibir cuanto se puede dibujar.

• Estructura de arriba abajo: primero el estado general y los SLO, luego las señales de oro del servicio, después los detalles por componente y las dependencias.
• Mostrar percentiles y tasas, no solo medias y totales.
• Marcar despliegues y cambios como anotaciones sobre las gráficas: la mayoría de los incidentes empiezan con un cambio.
• Usar escalas y unidades claras, y una paleta que funcione para personas con daltonismo.
• Un panel por propósito: visión ejecutiva, servicio, infraestructura, depuración.
• Los paneles también se versionan como código, para que no dependan de quien los dibujó.

Comprobaciones de salud

Dos cuidados: la comprobación de liveness no debe depender de servicios externos, o una caída de la base de datos reiniciaría en cascada toda la flota; y la de readiness debe ser ligera y reflejar de verdad la capacidad de responder. Además de las sondas internas, las comprobaciones sintéticas externas ejecutan un recorrido de usuario desde fuera y detectan lo que ve el cliente real (DNS, certificados, balanceadores).

Gestión de incidentes

Un incidente es una desviación que afecta al servicio y exige respuesta coordinada. La regla de oro: mitigar antes de diagnosticar. Restablecer el servicio (volver a la versión anterior, apagar una bandera, escalar, desviar el tráfico) viene antes de comprender del todo la causa raíz, que se investiga después con calma.

Roles

En equipos pequeños una persona asume varios roles, pero conviene tenerlos nombrados, sobre todo el de coordinación y el de comunicación.

Pautas

• Declarar el incidente pronto; es más fácil cerrar uno innecesario que llegar tarde a uno real.
• Asignar una gravedad con criterios claros, que determina quién se involucra y qué comunicación se hace.
• Centralizar la conversación en un único canal.
• Comunicar con una cadencia fija, aunque la novedad sea «seguimos investigando».
• Cambios de uno en uno, y registrados.
• Traspasar el relevo de forma explícita para evitar el agotamiento.

Postmortem sin culpables

Tras un incidente significativo se escribe un análisis posterior cuyo objetivo es aprender y mejorar el sistema, no señalar a nadie. Parte de la premisa de que las personas actuaron con la información que tenían y que si un error era posible, el sistema lo permitía. Los castigos hacen que se oculte información, y sin información no hay aprendizaje.

Plantilla de referencia:

Un postmortem sin acciones ejecutadas es una redacción; el valor está en completar las mejoras.

Observabilidad de sistemas con LLM

Las aplicaciones que llaman a modelos de lenguaje añaden problemas propios: la salida no es determinista, el coste depende del uso y «funciona» no equivale a «responde bien».

Las evaluaciones se ejecutan tanto sin conexión (antes de publicar un cambio de prompt o modelo, con un conjunto fijo de casos) como en producción con muestras. Hay que tratar con cuidado los datos: los prompts y respuestas pueden contener información personal, por lo que se aplican las mismas reglas de enmascarado y retención que a los logs. Existen herramientas específicas de trazado y evaluación de LLM, y OpenTelemetry mantiene convenciones semánticas para IA generativa.

Lista de comprobación

• Los logs son estructurados, con identificadores de correlación y sin datos sensibles.
• Hay métricas RED por servicio y USE por recurso, sin etiquetas de cardinalidad ilimitada.
• La latencia se mide con histogramas y se analiza con percentiles.
• Las trazas se propagan entre todos los servicios y hay una política de muestreo.
• Cada servicio crítico tiene SLI, SLO y presupuesto de error.
• Las alertas urgentes son por síntoma, accionables y enlazan a un runbook.
• Hay sondas de liveness y readiness, y comprobaciones sintéticas externas.
• Los despliegues aparecen anotados en los paneles.
• Existe un proceso de incidentes con roles, gravedad y comunicación.
• Los postmortems terminan en acciones con responsable que se completan.
• En sistemas con LLM se registran coste, tokens, versión de prompt y calidad.

Antipatrones

• Panel de cientos de gráficas que nadie sabe leer.
• Alertar por todo: la guardia aprende a silenciar el teléfono.
• Alertas por causas (CPU al 80 %) que no se traducen en daño al usuario.
• Medias como única medida de latencia.
• Etiquetas con identificadores de usuario o de petición en las métricas.
• Logs de texto libre imposibles de consultar con precisión.
• Registrar datos personales o secretos en logs y trazas.
• Instrumentar tras el incidente, en lugar de antes.
• Postmortems que buscan culpables o que nunca cierran sus acciones.
• Monitorizar la infraestructura pero no la experiencia del usuario.
• Un SLO del 100 %, que paraliza los cambios y no se puede cumplir.
• Retención infinita de telemetría, con coste sin valor.