Observabilidad y monitorización: guía completa para equipos de ingeniería

Todo equipo de ingeniería monitoriza la producción. Pocos pueden responder a la pregunta «¿por qué se comporta así el sistema?» sin una larga sesión de depuración. La diferencia entre monitorización y observabilidad no es una decisión de herramientas: es una filosofía de diseño que determina con qué rapidez tu equipo entiende y responde a fallos que nadie había previsto.

La monitorización clásica da por hecho que sabes qué vigilar. Fijas umbrales de CPU, compruebas códigos de estado y avisas a alguien cuando el disco supera el 90%. Eso funciona con fallos conocidos. Pero los sistemas distribuidos modernos fallan de maneras que ningún panel anticipó: una regresión sutil de latencia en un servicio provoca un atasco en una cola, que se manifiesta como agotamiento del conjunto de conexiones a la base de datos y solo aflora en horas punta. Sin la capacidad de hacer preguntas arbitrarias sobre el estado interno, vuelas a ciegas.

La observabilidad es la propiedad de un sistema que permite inferir su estado interno a partir de sus salidas externas. La monitorización te dice que algo va mal; la observabilidad te deja depurar qué fue mal, incluso cuando nunca predijiste ese fallo concreto. La distinción es crucial: la monitorización está guiada por alertas y atada a paneles; la observabilidad está guiada por preguntas y es rica en datos.

Cuando tu sistema emite datos estructurados de alta cardinalidad en registros, métricas y trazas, puedes correlacionar eventos, descender hasta usuarios o peticiones concretas y descubrir la causa raíz de incidencias que ninguna alerta por umbral habría detectado. Los equipos que invierten en observabilidad reducen el tiempo medio de resolución en un orden de magnitud, porque dedican menos tiempo a adivinar y más a actuar sobre pruebas.

«La monitorización te dice si un sistema funciona. La observabilidad te deja preguntar por qué no funciona. Lo segundo es un requisito para operar sistemas que no entiendes del todo, que son todos los sistemas en producción.»

El ecosistema de la observabilidad se apoya en tres tipos de datos complementarios, cada uno con un propósito distinto. Tratarlos como una señal unificada en vez de compartimentos separados es la clave para depurar con eficacia.

Registros: constancia inmutable de los hechos

Los registros son anotaciones fechadas de eventos discretos. Son la señal más granular: capturan exactamente qué ocurrió en un instante concreto. Una línea de registro bien estructurada lleva suficiente contexto —identificador de petición, nombre del servicio, duración, detalle del error— para reconstruir el camino de ejecución sin tener que cruzar varias fuentes.

El error más común es tratar los registros como texto sin estructura. Buscar por archivos planos funcionaba con tres servidores; a escala, los registros sin estructura son ruido. Cada línea debe ser analizable, incluir metadatos estructurados y seguir un esquema uniforme en todos los servicios de tu arquitectura.

Métricas: mediciones agregadas en el tiempo

Las métricas son representaciones numéricas del estado del sistema medidas a intervalos. Están pensadas para almacenarse de forma eficiente y agregarse rápido. Responden a preguntas como «¿cuántas peticiones por segundo?» o «¿cuál es la latencia p99?». A diferencia de los registros, descartan el dato de cada petición: cambian granularidad por compresión y velocidad.

Los tipos habituales —contadores, medidores, histogramas y resúmenes— sirven a usos distintos. Los contadores siguen valores acumulados, como el total de peticiones. Los medidores registran valores puntuales, como el uso de memoria. Los histogramas reparten observaciones en cubos configurables para distribuciones de latencia. Elegir el tipo adecuado evita agregaciones engañosas y cardinalidad desperdiciada.

Trazas: el ciclo de vida completo de una petición

Las trazas distribuidas siguen una única petición a medida que atraviesa las fronteras entre servicios. Cada traza se compone de tramos: operaciones con nombre y marcas de inicio y fin que capturan el trabajo hecho por un servicio o una función. Las trazas son la única señal capaz de reconstruir el ciclo de vida completo de una petición en una arquitectura de microservicios.

Sin trazas, una página lenta podría achacarse a cualquiera de las decenas de servicios implicados. Con trazas, identificas que el cuello de botella es la consulta a la base de datos del servicio de usuarios, que tarda 800 milisegundos, mientras el resto de tramos termina por debajo de 50. Esa precisión es imposible solo con registros o métricas.

«Los registros te dicen qué pasó. Las métricas, cuántas veces pasó. Las trazas, cómo encaja todo. Necesitas las tres para atravesar una incidencia en producción sin hacer suposiciones.»

OpenTelemetry es el estándar del sector para generar, recoger y exportar telemetría. Ofrece un conjunto único de APIs y SDK en distintos lenguajes que emiten registros, métricas y trazas en un formato neutral respecto al proveedor. Adoptarlo elimina la dependencia de un fabricante y garantiza que tu instrumentación sirva tanto con una plataforma comercial como con una canalización propia.

Instrumentación automática y manual

La mayoría de los SDK admite instrumentación automática: enganches sin código a marcos y bibliotecas populares. Una sola llamada de inicialización puede instrumentar servidores HTTP, clientes de base de datos, colas de mensajes y llamadas gRPC. Lo automático cubre los caminos habituales, pero para código crítico del negocio, middleware propio y operaciones del dominio hace falta instrumentación manual.

import { NodeSDK } from "@opentelemetry/sdk-node";
import { OTLPTraceExporter } from "@opentelemetry/exporter-trace-otlp-grpc";
import { OTLPMetricExporter } from "@opentelemetry/exporter-metrics-otlp-grpc";
import { HttpInstrumentation } from "@opentelemetry/instrumentation-http";
import { ExpressInstrumentation } from "@opentelemetry/instrumentation-express";
import { PgInstrumentation } from "@opentelemetry/instrumentation-pg";
import { Resource } from "@opentelemetry/resources";
import { SEMRESATTRS_SERVICE_NAME } from "@opentelemetry/semantic-conventions";

const sdk = new NodeSDK({
  resource: new Resource({
    [SEMRESATTRS_SERVICE_NAME]: "payment-service",
  }),
  traceExporter: new OTLPTraceExporter({
    url: "http://otel-collector:4317",
  }),
  metricExporter: new OTLPMetricExporter({
    url: "http://otel-collector:4317",
  }),
  instrumentations: [
    new HttpInstrumentation(),
    new ExpressInstrumentation(),
    new PgInstrumentation(),
  ],
});

sdk.start();
process.on("SIGTERM", () => sdk.shutdown());

La arquitectura del recolector de OpenTelemetry

El recolector de OpenTelemetry es un intermediario neutral que recibe, procesa y exporta telemetría. Es la columna vertebral de cualquier canalización en producción. Desplegar un recolector por máquina o como conjunto en tu infraestructura de Kubernetes desacopla la instrumentación de la elección de destino y permite agrupar, filtrar, muestrear y transformar los datos antes de que lleguen a la plataforma.

Los recolectores pueden configurarse con procesadores que hacen muestreo al final: conservan trazas completas de peticiones lentas o con error y descartan la mayor parte del tráfico sano. Eso reduce drásticamente el coste de almacenamiento sin sacrificar la capacidad de depurar justo las peticiones que importan.

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:
    timeout: 1s
    send_batch_size: 1024
  memory_limiter:
    check_interval: 1s
    limit_mib: 512
  filter:
    error_mode: ignore
    traces:
      span:
        - 'attributes["http.target"] == "/healthz"'
        - 'attributes["http.target"] == "/metrics"'
  attributes:
    actions:
      - key: environment
        value: production
        action: upsert

exporters:
  otlp:
    endpoint: "collector.example.com:443"

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, filter, batch, attributes]
      exporters: [otlp]
    metrics:
      receivers: [otlp]
      processors: [memory_limiter, batch, attributes]
      exporters: [otlp]
    logs:
      receivers: [otlp]
      processors: [memory_limiter, batch, attributes]
      exporters: [otlp]

Registrar de forma estructurada significa emitir entradas en un formato legible por máquina —normalmente JSON— con nombres de campo uniformes entre servicios. Convierte los registros de un problema de búsqueda en un problema de consulta. Cuando todos los equipos usan las mismas convenciones para identificadores de petición, nombres de servicio, códigos de error y duraciones, puedes lanzar consultas puntuales sobre toda tu infraestructura sin escribir analizadores a medida.

Diseño del esquema de registros

Todo evento estructurado debería incluir un mínimo de atributos: marca de tiempo, nivel de severidad, nombre del servicio, identificador de traza, identificador de tramo y mensaje. Más allá de eso, añade campos del dominio, pero respeta las convenciones de nombres. Por ejemplo, usa siempre la misma grafía, antepón un prefijo común a los campos de usuario y guarda el detalle del error en un objeto anidado en vez de concatenarlo en el mensaje.

• Incluye siempre trace_id y span_id para correlacionar registros con trazas
• Usa un nivel de registro (debug, info, warn, error) que corresponda a señales accionables, no a la comodidad de quien programa
• No registres nunca datos sensibles —información personal, secretos o tokens—, ni siquiera en desarrollo
• Mantén los mensajes estáticos y pon los datos variables en campos estructurados para poder agregar
• Unifica el formato de marca de tiempo en todos los servicios, con RFC 3339 o milisegundos de Unix

Trampas frecuentes

El error más caro es registrar de más. Campos de alta cardinalidad como identificadores de usuario o direcciones IP pueden multiplicar el volumen por órdenes de magnitud. Usa muestreo para los registros de depuración voluminosos y reserva el detalle para trazas concretas o condiciones de error. El segundo error es la falta de uniformidad en los nombres: un servicio con user_id, otro con customerId y un tercero con user.id hace imposibles las consultas cruzadas sin capas de transformación.

«Una línea de registro que no se puede consultar es como si no existiera. El registro estructurado no va de legibilidad: va de convertir cada entrada en ciudadana de primera de tu plataforma de observabilidad.»

Las trazas distribuidas son la herramienta más eficaz para depurar arquitecturas de microservicios. Una traza que abarca veinte servicios te dice exactamente dónde se consume el tiempo, qué peticiones fallan y cómo se propagan los errores. Sin trazas, depurar un flujo de compra lento significa revisar registros en una docena de servicios y adivinar la causalidad.

Propagación del contexto de traza

El contexto de traza debe propagarse en cada frontera entre servicios: cabeceras HTTP, metadatos de colas de mensajes, metadatos gRPC e incluso a través de fronteras asíncronas como tareas programadas o procesos en segundo plano. OpenTelemetry lo gestiona solo si usas sus bibliotecas de instrumentación para HTTP, gRPC y mensajería. El identificador de traza fluye desde la puerta de entrada por cada servicio posterior, recogiendo tramos por el camino.

• Instrumenta todos los puntos de entrada: pasarelas de API, balanceadores, controladores de entrada
• Propaga el contexto por las colas de mensajes usando cabeceras o metadatos del mensaje
• Incluye el identificador de traza en la salida de registro para poder correlacionar registro y traza
• Usa estrategias de muestreo que preserven las trazas con errores o latencia alta
• Añade atributos propios a los tramos para el contexto de negocio: nivel de cliente, referencia de producto, región

Leer e interpretar trazas

Una traza bien anotada revela el camino crítico de una petición. Fíjate en el tramo de mayor duración: ese es tu cuello de botella. Busca tramos con eventos de error o con muchos atributos distintos. Compara trazas de peticiones correctas y fallidas para detectar patrones. Si las trazas muestran de forma sistemática que una llamada concreta agota su tiempo de espera, tienes un problema de dependencia, no un fallo de aplicación.

La fatiga por alertas es la mayor amenaza para la respuesta ante incidencias. Cuando un equipo recibe cincuenta avisos por turno, todos se ignoran. El objetivo de una buena estrategia no es detectar cualquier anomalía, sino producir un conjunto pequeño y de alta señal de notificaciones que requieran juicio humano. Todo lo demás debería ser un panel o una consulta.

El sistema de niveles

Organiza las alertas en tres niveles. Las de nivel 1 avisan de inmediato a quien está de guardia, porque indican un problema visible para el usuario: tasa de error alta, servicio caído por completo o consumo del presupuesto de error por encima del umbral. Las de nivel 2 crean un ticket para revisar al día siguiente: latencia elevada, componentes degradados pero no caídos. Las de nivel 3 son informativas: certificado por caducar, límites de almacenamiento cercanos.

• Avisa solo por síntomas, no por causas. El usuario ve un error 5xx: alerta por eso, no por el uso de CPU
• Usa alertas con varias condiciones que exijan una desviación sostenida antes de dispararse (por ejemplo, cinco minutos por encima del umbral)
• Fija un máximo de tres avisos por persona y turno para conservar la calidad de la señal
• Revisa y poda las reglas cada trimestre: las alertas caducas erosionan la confianza en el sistema
• Incluye el enlace a un manual de actuación en cada alerta, para que quien responde sepa los tres primeros pasos

Alertas por ritmo de consumo

Las alertas por ritmo de consumo se disparan cuando tu presupuesto de error se agota más rápido de lo previsto. A diferencia de los umbrales fijos, están ligadas directamente a tus SLO. Si tu objetivo es un 99,9% de disponibilidad en 30 días, dispones de unos 43 minutos de caída. La alerta salta cuando el ritmo proyectado agotaría la ventana antes de lo planeado, dándote tiempo para responder antes de incumplir el objetivo.

La mayoría de los paneles son cementerios de gráficos sin usar. Un panel es útil cuando responde a una pregunta concreta sin exigir interpretación. Los mejores se construyen para un único perfil y un único uso: un panel de guardia para triar incidencias, un panel de revisión semanal para planificar capacidad y un panel de equipo para seguir el cumplimiento de los SLO.

El panel de guardia

Debe caber en una pantalla y responder a cuatro preguntas: ¿está el servicio en pie?, ¿cuál es la tasa de error?, ¿cómo se distribuye la latencia?, ¿se ha consumido el presupuesto de error? Cada gráfico necesita una línea de umbral clara para que se vea de inmediato si el valor actual es sano. No pongas más de seis gráficos: durante una incidencia, la carga mental importa.

• Empieza por las métricas RED: ritmo (peticiones por segundo), errores (peticiones fallidas) y duración (percentiles de latencia)
• Añade métricas USE para la infraestructura: utilización, saturación y errores por recurso
• Muestra el cumplimiento del SLO y el ritmo de consumo como indicadores destacados
• Enlaza cada gráfico con sus registros o su consulta de trazas para bajar al detalle con un clic
• Usa escalas logarítmicas en los gráficos de latencia: las lineales ocultan variaciones importantes en las colas

Antipatrones habituales

El antipatrón más común es el panel que muestra todas las métricas que produce tu infraestructura. Esos «muros verdes» crean una falsa sensación de seguridad y hacen imposible encontrar la señal durante una incidencia. Otros antipatrones: usar gráficos circulares para series temporales, apilar métricas en ejes inconsistentes y no etiquetar las líneas de umbral. Si un gráfico necesita un comentario que lo explique, no pertenece al panel.

Los indicadores, objetivos y presupuestos de error forman el contrato entre tu equipo y tus usuarios. Los SLI son las mediciones en bruto: latencia, tasa de error, rendimiento. Los SLO son los objetivos que te comprometes a cumplir: el 99,9% de las peticiones por debajo de 200 milisegundos. El presupuesto de error es el margen de fallo admisible: ese 0,1% que da permiso al equipo para desplegar, experimentar e iterar sin miedo a incumplir lo prometido.

Elegir SLI con sentido

Un buen SLI mira al usuario, se puede medir y lleva a la acción. Disponibilidad (proporción de peticiones correctas), latencia (proporción por debajo de un umbral) y frescura (antigüedad de los datos servidos) son los más habituales en servicios web. La clave es medir desde la perspectiva del usuario: una petición que tu servidor resuelve en 50 milisegundos pero tarda dos segundos en una red móvil lenta es un fallo a ojos de quien la hace.

Fijar objetivos realistas

Un SLO del 99,999% suena impresionante, pero conlleva un coste de ingeniería enorme. Cada nueve adicional exige unas diez veces más inversión en redundancia, pruebas y herramientas de operación. Empieza con un 99,9% para la mayoría de servicios y reserva los objetivos más altos para los caminos críticos de cara al cliente. Sé honesto con lo que puedes lograr: un SLO que se incumple constantemente es peor que ninguno, porque normaliza el fallo y erosiona la confianza en las métricas.

Cómo los presupuestos de error dan velocidad

El presupuesto de error convierte la fiabilidad de una restricción en un riesgo medible. Cuando está lleno, el equipo puede desplegar con soltura sabiendo que hay margen. Cuando se agota, se detienen las entregas no críticas y se trabaja solo en fiabilidad. Así se crea un proceso de decisión claro y basado en datos, que sustituye los debates subjetivos sobre si una entrega es «suficientemente segura».

La computación sin servidor y en el borde plantea retos propios. Las funciones son efímeras, la infraestructura está abstraída y la ejecución se reparte por puntos de presencia de todo el mundo. La monitorización clásica con agentes no sirve, porque no hay máquina donde alojarlos. Aquí hace falta otro enfoque: telemetría enviada desde el código, trazas finas para los arranques en frío y un control cuidadoso de la cardinalidad en despliegues globales.

Patrones propios de lo sin servidor

El arranque en frío es el factor dominante de latencia. Instrumenta la inicialización por separado del tratamiento de la petición, para distinguir la latencia del arranque de la de la lógica de negocio. Usa registro estructurado para capturar el contexto de invocación —identificador de petición, región, versión de la función, entorno de ejecución— y emite métricas propias de número de invocaciones, duración y tasa de error de forma asíncrona, para no bloquear la respuesta.

• Mide la duración del arranque en frío como métrica propia: es invisible en las métricas estándar del proveedor
• Usa propagadores de OpenTelemetry compatibles con el mecanismo de extensión de tu plataforma
• Exporta la telemetría por lotes para no añadir latencia al tiempo de ejecución de la función
• Configura métricas derivadas de registros allí donde no haya API de métricas propias
• Etiqueta toda la telemetría con entorno, región y versión de la función para poder filtrar con eficacia

Consideraciones en el borde

Las plataformas de borde ejecutan código en decenas de ubicaciones repartidas por el mundo. Esa dispersión hace impracticable la recogida centralizada clásica. Usa herramientas pensadas para el borde, que recojan telemetría en cada punto y la agreguen centralmente con poco coste. Vigila la tasa de error por región: un problema de un operador local puede degradar tu servicio en una zona mientras la media mundial parece sana.

Las herramientas y las canalizaciones son necesarias pero no bastan. Lo más difícil de la observabilidad es cultural. Tu equipo debe valorar el código instrumentado tanto como el código probado. Cada funcionalidad nueva debería incluir instrumentación en su definición de terminado, igual que incluye pruebas unitarias y revisión. Eso requiere infraestructura: bibliotecas compartidas, convenciones documentadas y alguien que impulse el tema en cada equipo.

Hacer de la observabilidad un asunto de primer orden

Empieza redactando un documento de diseño de telemetría que fije los campos estándar, las convenciones de nombres de métricas y los requisitos de trazado para cada servicio. Hazlo parte de la puesta en marcha de todo servicio nuevo. Configura comprobaciones automáticas en integración continua que exijan una instrumentación mínima: por ejemplo, rechaza los cambios que añadan manejadores HTTP sin su correspondiente trazado o sus entradas de registro estructurado.

• Incluye la instrumentación en la definición de terminado de cada funcionalidad
• Organiza jornadas de práctica en las que el equipo depure usando solo paneles y consultas de trazas
• Celebra los aciertos: comparte análisis de incidencias que muestren cómo una buena telemetría llevó a una resolución rápida
• Asigna responsables rotatorios que revisen la calidad de la telemetría entre equipos cada iteración
• Invierte en bibliotecas de instrumentación compartidas que hagan más fácil lo correcto que lo incorrecto

El ciclo de realimentación

La observabilidad no es una implantación puntual, sino un ciclo continuo: instrumentar, entregar, observar, aprender y mejorar. Cuando una incidencia deja al descubierto un punto ciego —una métrica que no se seguía, un campo de registro ausente, una traza descartada—, trátalo como un fallo de tu plataforma de observabilidad y corrígelo. Con el tiempo tu telemetría se completa, la depuración se acelera y el equipo gana la confianza de saber que puede entender cualquier fallo, incluso los que nunca ha visto.

«El objetivo de la observabilidad no es evitar incidencias. Es asegurar que, cuando ocurran, tu equipo tenga los datos, las herramientas y la confianza para resolverlas antes de que tus usuarios lo noten.»

Adoptar la observabilidad es un camino, no una compra. Empieza en pequeño: instrumenta de punta a punta un servicio crítico, construye un solo panel útil y escribe un SLO con sentido. Deja que el valor hable por sí mismo. Una vez que tu equipo experimente la diferencia entre adivinar y saber durante una incidencia, no querrá volver atrás.