Observabilidad vs. monitoreo: métricas, logs y trazas en sistemas distribuidos

Una API empieza a responder lentamente. El dashboard confirma que la latencia P95 aumentó, pero el tráfico permanece estable y la tasa de errores apenas se movió. El servicio sigue disponible, aunque los usuarios esperan casi un segundo por una operación que normalmente termina en 200 milisegundos.

El sistema de monitoreo detectó el síntoma. No explicó qué dependencia consumió el tiempo, si todas las solicitudes fueron afectadas, qué cambió antes de la degradación ni qué mitigación puede aplicarse sin aumentar el riesgo.

Esa es la frontera práctica entre monitoreo y observabilidad. El monitoreo comprueba condiciones esperadas. La observabilidad proporciona evidencia correlacionada para investigar comportamientos que no se anticiparon.

Las métricas cuantifican el síntoma. Las trazas reconstruyen el recorrido de ejecución. Los logs aportan contexto sobre eventos y estado. Ninguna señal es suficiente por sí sola, y recolectar las tres no vuelve observable a un sistema automáticamente. La capacidad aparece cuando comparten identidad, semántica, propiedad y propósito operativo.

Esta guía explica cómo diseñar esa capacidad, cómo evitar telemetría costosa pero débil para el diagnóstico y cómo validar que el sistema resultante realmente mejora las decisiones en producción.

Monitoreo y observabilidad no son sinónimos

Monitoreo y observabilidad se superponen, pero describen capacidades diferentes.

La definición de Google SRE se concentra en recopilar, procesar, agregar y mostrar datos cuantitativos sobre un sistema. El monitoreo es, por tanto, una actividad operativa: definir señales, evaluar condiciones, visualizar comportamiento y notificar a personas o automatizaciones cuando una condición requiere una acción.

La observabilidad es una propiedad del sistema y de su instrumentación. Un sistema es observable cuando un ingeniero puede utilizar la evidencia que emite externamente para formular preguntas nuevas sobre su comportamiento interno sin desplegar primero código adicional de diagnóstico. OpenTelemetry describe esta capacidad como la posibilidad de investigar problemas no previstos y responder por qué ocurre un comportamiento.

La diferencia no consiste en que el monitoreo utilice métricas y la observabilidad tres herramientas. Un sistema moderno de monitoreo puede emplear métricas, logs, trazas, pruebas sintéticas, perfiles y eventos. La diferencia está en el tipo de pregunta que el sistema permite responder.

Qué responde el monitoreo

El monitoreo es efectivo cuando la condición puede definirse antes de que ocurra:

• ¿El servicio acepta solicitudes?
• ¿La tasa de errores superó el umbral del SLO?
• ¿La latencia P95 excedió el presupuesto operativo?
• ¿El pool de conexiones se aproxima al agotamiento?
• ¿Una cola dejó de drenar?
• ¿La versión actual se comporta de forma distinta a la anterior?

Son preguntas conocidas, con mediciones explícitas y una lógica de evaluación definida.

Qué permite investigar la observabilidad

La observabilidad se vuelve necesaria cuando la investigación no estaba determinada de antemano:

• ¿Por qué solo son lentas las solicitudes de una región?
• ¿Qué dependencia domina la latencia de una operación específica?
• ¿Por qué dos instancias con la misma versión se comportan de forma diferente?
• ¿La degradación fue causada por el despliegue o cambió al mismo tiempo la composición del tráfico?
• ¿Qué operaciones visibles para el usuario fueron afectadas por un evento compartido de infraestructura?
• ¿La cola crece porque los consumidores son más lentos, los productores son más rápidos o los reintentos están duplicando trabajo?

La observabilidad no garantiza una identificación automática de la causa raíz. Proporciona evidencia para reducir el espacio de búsqueda, formular una hipótesis y comprobarla. Una traza puede mostrar dónde se acumuló el tiempo sin demostrar por qué. Un log puede registrar un timeout sin probar si lo causó la dependencia, la red o la falta de recursos locales.

Comparación operativa

La ruta de monitoreo determina que una condición conocida requiere atención. La ruta de observabilidad aporta la evidencia necesaria después de la detección para comprender el alcance, formular una hipótesis y validar la respuesta.

Las tres señales principales de telemetría

Métricas, logs y trazas siguen siendo el modelo operativo más útil para comprender aplicaciones distribuidas. Llamarlas «los tres pilares» resulta conveniente, pero no constituye una definición completa de observabilidad. OpenTelemetry también modela contexto, baggage, eventos, recursos y perfiles. El modelo de tres señales es valioso porque cada una posee una forma diagnóstica y un costo diferentes.

Métricas: detectar y dimensionar

Una métrica es una medición numérica asociada al tiempo y a un conjunto acotado de dimensiones. Las métricas están diseñadas para agregarse. Responden cuánto, con qué frecuencia, durante cuánto tiempo y cómo cambia el comportamiento.

Entre los instrumentos habituales se encuentran:

• Counter: total monotónico, como solicitudes completadas o eventos de timeout.
• Up-down counter: valor que puede aumentar o disminuir, como trabajos activos o conexiones abiertas.
• Gauge: último valor observado, como profundidad de cola o presión de memoria.
• Histogram: distribución de mediciones, como duración de solicitudes o tamaño de payloads.

El modelo exacto depende del estándar de telemetría y del backend. La API de métricas de OpenTelemetry, por ejemplo, define counters, gauges, up-down counters e histograms, mientras su modelo de datos describe cómo representar valores agregados y distribuciones.

Métricas útiles para un servicio incluyen:

• Tasa de solicitudes por operación.
• Proporción de éxitos y errores.
• Latencia P50, P95 y P99.
• Profundidad y antigüedad de cola.
• Conexiones activas, libres y en espera.
• Pools de workers o threads saturados.
• Reintentos y solicitudes rechazadas.
• Cumplimiento del SLO y velocidad de consumo del presupuesto de error.

Una métrica es eficiente porque convierte muchos eventos en una serie temporal. Esa eficiencia también es su limitación. Un valor P95 puede mostrar que el 5 % de las solicitudes superó cierto tiempo, pero normalmente no permite identificar qué solicitudes fueron lentas ni qué ocurrió dentro de ellas.

Para profundizar en el diseño de rendimiento extremo a extremo y el presupuesto de latencia, conviene separar la decisión sistémica de la interpretación estadística de los percentiles. La explicación estadística completa corresponde al artículo especializado sobre los percentiles de latencia P50, P95 y P99.

Regla de decisión para métricas

Utiliza una métrica cuando la pregunta requiera agregación sobre muchos eventos y sus dimensiones puedan mantenerse acotadas.

No coloques request IDs, transaction IDs, timestamps, URLs sin normalizar, correos electrónicos ni user IDs en etiquetas de métricas. Esos valores pertenecen a logs o trazas porque su naturaleza casi única crea una nueva serie temporal por cada conjunto distinto de etiquetas.

Logs: conservar contexto de eventos

Un log registra un evento. Su valor diagnóstico depende menos de la frase que contiene que de la estructura y el contexto asociados.

Un log débil dice:

Algo salió mal al procesar la solicitud.

No ofrece un nombre estable de operación, identidad del servicio, resultado, clasificación del error, duración ni campos de correlación. Durante un incidente, los ingenieros deben inferir el contexto a partir de líneas cercanas, hostnames y timestamps. Ese enfoque falla rápidamente cuando las solicitudes atraviesan servicios concurrentes.

Un registro estructurado más útil podría ser:

{
  "timestamp": "2026-07-12T22:14:08.417Z",
  "severity": "ERROR",
  "service.name": "authorization-api",
  "service.version": "2026.07.12.3",
  "deployment.environment": "production",
  "operation": "authorize",
  "result": "timeout",
  "trace_id": "4e8f2c7b6bb44df19cd9d6f0db8916a2",
  "span_id": "a1729f6b1c83e402",
  "correlation_id": "order-8129",
  "dependency": "risk-service",
  "duration_ms": 1842,
  "pool_wait_ms": 1614,
  "error_code": "DEPENDENCY_CONNECTION_ACQUIRE_TIMEOUT"
}

Este registro permite varias rutas de investigación:

• Buscar todos los logs asociados a una traza.
• Comparar fallos por versión del servicio.
• Separar el tiempo de ejecución de la dependencia del tiempo de espera en el pool local.
• Agrupar un flujo funcional más amplio mediante Correlation ID.
• Medir si el mismo error code aumentó después de un despliegue.

La especificación de logs de OpenTelemetry soporta expresamente la correlación mediante tiempo, contexto de traza y contexto de recurso. Incluir Trace ID y Span ID en los registros permite pasar desde el waterfall de una traza hacia los eventos exactos emitidos durante esa ejecución.

Campos que deben ser consistentes

Como mínimo, los logs de aplicación deben utilizar nombres estables para:

• Timestamp del evento y timestamp de observación cuando ambos sean relevantes.
• Severidad.
• Nombre y versión del servicio.
• Entorno de despliegue.
• Nombre de operación o evento.
• Resultado y clasificación de error.
• Trace ID y Span ID cuando exista contexto de traza.
• Correlation ID cuando lo requiera el flujo funcional.
• Duración y unidad.
• Dependencia o recurso involucrado.

El esquema debe seguir una convención compartida en lugar de permitir que cada equipo invente sus propios nombres. Las Semantic Conventions de OpenTelemetry existen precisamente para proporcionar nomenclatura común entre lenguajes, librerías y plataformas.

Qué no debe registrarse

Más detalle no implica necesariamente mejor diagnóstico. Los logs pueden crear riesgos de seguridad, privacidad y costo. Evita registrar credenciales, access tokens, datos completos de pago, datos personales sin un propósito definido o cuerpos completos de request y response por defecto. La redacción y el filtrado deben formar parte del pipeline de telemetría, no aplicarse después de que la información sensible llegó al backend.

Trazas distribuidas: reconstruir la ejecución

Una traza distribuida representa el recorrido de una operación a través de procesos y fronteras de red. Está compuesta por spans. Cada span describe una operación mediante tiempo de inicio, tiempo de fin, atributos, eventos, estado y una relación de paternidad o enlace.

Un recorrido simplificado podría ser:

Cliente
  -> API Gateway
    -> Authorization API
      -> Risk Service
        -> Base de datos
        -> API externa de reglas

Una traza transforma esa topología en una ejecución temporizada. Puede mostrar que Authorization API completó 70 milisegundos de trabajo local, esperó 620 milisegundos por una conexión hacia Risk Service, consumió 130 milisegundos dentro de la dependencia y respondió tras 820 milisegundos totales.

La diferencia es relevante. Sin el span o atributo de espera, un ingeniero podría culpar al servicio downstream porque aparece en la ruta. Con el desglose completo, la evidencia apunta al tiempo de adquisición de conexiones o al control de concurrencia local.

Las métricas establecen impacto y tendencia. Las trazas identifican el recorrido degradado. Los logs explican el estado y los eventos asociados. El diagnóstico depende de unir las señales, no de leer dashboards aislados.

Una traza localiza tiempo, pero no demuestra automáticamente la causa

Un span largo es evidencia de dónde se observó tiempo transcurrido. Puede representar:

• Trabajo ejecutado por el propietario del span.
• Espera por una conexión, lock, thread o cola.
• Retardo de red.
• Reintentos ocultos dentro de una librería cliente.
• Tiempo consumido en una dependencia remota.
• Falta de instrumentación hija que colapsa varias operaciones dentro de un solo span.

La siguiente decisión consiste en comparar trazas, revisar métricas de recursos y localizar logs específicos del estado. La observabilidad apoya el análisis causal; no lo reemplaza.

Trace ID, Span ID y Correlation ID

Estos identificadores están relacionados, pero resuelven problemas distintos.

Trace ID

Un Trace ID identifica la ejecución distribuida completa representada por una traza. Todos sus spans comparten el mismo Trace ID.

La especificación W3C Trace Context define una propagación interoperable mediante el header traceparent y el header opcional tracestate. El valor de traceparent transporta el identificador de traza, el identificador del span padre, la versión y los trace flags en un formato independiente del proveedor.

Ejemplo:

traceparent: 00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01

El Trace ID del ejemplo es:

0af7651916cd43dd8448eb211c80319c

Span ID

Un Span ID identifica una operación dentro de una traza. Las relaciones entre Span IDs padres e hijos reconstruyen el árbol o grafo causal.

Una traza puede contener spans para:

• La solicitud HTTP entrante.
• Una operación interna de autorización.
• Una consulta a base de datos.
• La publicación de un mensaje.
• Una llamada a un servicio remoto.

Cada span tiene su propio Span ID, pero conserva el Trace ID de la ejecución distribuida.

Correlation ID

Un Correlation ID es un identificador definido por la aplicación para asociar eventos que pertenecen a un flujo lógico. No reemplaza el contexto de trazas ni está estandarizado por W3C Trace Context.

Un flujo funcional puede sobrevivir a una sola traza. Por ejemplo, una orden puede crearse de forma síncrona, procesarse asincrónicamente, reintentarse horas después y conciliarse al día siguiente. Esas ejecuciones pueden producir varias trazas mientras comparten un identificador estable de orden o de workflow.

A la inversa, una traza puede involucrar varias entidades funcionales. Forzar un identificador de dominio como Trace ID puede romper la generación de trazas, las suposiciones de sampling y la interoperabilidad.

Cuándo utilizar cada identificador

Decisión de propagación

Propaga W3C Trace Context a través de las fronteras síncronas y asíncronas soportadas. Conserva campos de correlación de aplicación únicamente cuando tengan propietario, ciclo de vida y clasificación de datos definidos.

No copies valores arbitrarios enviados por usuarios hacia campos confiables de correlación sin validarlos. No sobrecargues baggage con valores grandes o sensibles: el contexto propagado cruza fronteras de servicios, aumenta el tamaño de las solicitudes y puede exponer información a componentes que no la necesitan.

OpenTelemetry sin acoplamiento al backend

OpenTelemetry proporciona APIs, SDKs, Semantic Conventions, propagación de contexto, OpenTelemetry Protocol y Collector independientes del proveedor. Estandariza cómo se produce y transporta la telemetría. No entrega por sí solo el resultado completo de observabilidad.

Qué resuelve OpenTelemetry

OpenTelemetry ayuda a estandarizar:

• Instrumentación de trazas, métricas y logs.
• Propagación de contexto entre servicios.
• Instrumentación automática o sin cambios de código para librerías y runtimes soportados.
• Instrumentación basada en código para operaciones específicas de la aplicación.
• Identidad del recurso, como nombre y versión del servicio.
• Nomenclatura semántica entre lenguajes y frameworks.
• Exportación mediante OTLP y otros protocolos compatibles.
• Recolección, batching, filtrado, transformación, sampling y routing mediante Collector.

Qué no decide OpenTelemetry

No decide:

• Qué recorridos de usuario requieren un SLO.
• Qué operación funcional merece un span manual.
• Qué etiquetas son seguras para métricas.
• Qué información es sensible.
• Qué trazas deben conservarse.
• Qué alerta debe despertar a un ingeniero.
• Qué pregunta debe responder un dashboard durante un incidente.
• Qué modelo de retención y consulta se ajusta a la organización.

Esas siguen siendo decisiones de arquitectura y modelo operativo.

Ruta recomendada de las señales

El Collector desacopla las aplicaciones de mecanismos de ingesta específicos y centraliza controles transversales como batching, retries, filtering, redaction y sampling. Los entornos pequeños pueden exportar directamente, pero el Collector adquiere valor cuando la política de telemetría debe cambiar sin redesplegar cada servicio.

Instrumentación automática y manual

La documentación de OpenTelemetry distingue entre instrumentación basada en código e instrumentación sin cambios de código. Deben combinarse en lugar de tratarse como opciones excluyentes.

La instrumentación automática o zero-code es útil para:

• Llamadas HTTP entrantes y salientes.
• Middleware de frameworks.
• Clientes de bases de datos.
• Clientes de mensajería.
• Telemetría de runtime y procesos.
• Operaciones comunes de red.

Permite revelar rápidamente la topología técnica y los tiempos base.

La instrumentación manual es necesaria para:

• Operaciones de dominio como authorize_order o calculate_quote.
• Etapas funcionales dentro de una solicitud.
• Atributos que clasifiquen la operación de forma acotada y significativa.
• Eventos como activación de fallback o rechazo de una política.
• Fronteras que una librería genérica no puede inferir.

La instrumentación automática puede mostrar que una llamada HTTP tardó 800 milisegundos. La instrumentación manual puede revelar que 650 milisegundos se consumieron esperando un permiso limitado antes de invocar el cliente HTTP.

Una secuencia de instrumentación defendible

1. Establece una identidad consistente del recurso: nombre de servicio, versión, entorno, región e identidad de instancia o workload cuando corresponda.
2. Habilita instrumentación automática para protocolos y librerías estándar.
3. Define las operaciones críticas de usuario y de negocio que requieren spans o métricas manuales.
4. Aplica Semantic Conventions antes de inventar nombres de atributos propios.
5. Añade contexto de traza y span a los logs estructurados.
6. Define presupuestos de cardinalidad y reglas para datos sensibles.
7. Ejecuta pruebas de carga sobre el pipeline y mide overhead en la aplicación, saturación del Collector, datos descartados y costo de ingesta.
8. Valida las señales mediante un fallo controlado o un ejercicio de game day.

El último paso es esencial. Una instrumentación que parece completa en una demostración puede fallar bajo concurrencia, ejecución asíncrona, sampling parcial o el volumen propio de un incidente.

Cómo elegir entre RED, USE y las Golden Signals

RED, USE y las Four Golden Signals no son estándares rivales. Organizan perspectivas distintas sobre el mismo sistema.

RED para servicios orientados a solicitudes

El método RED, creado por Tom Wilkie para monitorear servicios, se concentra en:

• Rate: cuántas solicitudes u operaciones se procesan.
• Errors: cuántas fallan, incluidas respuestas semánticamente fallidas cuando corresponda.
• Duration: distribución del tiempo de ejecución.

RED es un punto de partida sólido para APIs, servicios RPC, consumidores y otros componentes orientados a solicitudes. Permite determinar si cambió la demanda, la tasa de fallos o la latencia.

USE para recursos

El método USE de Brendan Gregg evalúa cada recurso mediante:

• Utilization: qué proporción de su capacidad está ocupada.
• Saturation: cuánto trabajo espera porque el recurso no puede atenderlo inmediatamente.
• Errors: eventos de error asociados al recurso.

USE se aplica a CPU, discos, interfaces de red, pools de conexiones, thread pools, colas, capacidad de memoria y otros recursos finitos.

La saturación es crítica. La utilización promedio puede parecer aceptable mientras intervalos breves alcanzan la capacidad total y crean colas. Un promedio de CPU de 70 % durante cinco minutos no demuestra que ningún intervalo de un segundo haya alcanzado 100 %.

Las Four Golden Signals para la salud del servicio

Las Four Golden Signals de Google SRE son:

• Latency.
• Traffic.
• Errors.
• Saturation.

Proporcionan una vista operativa compacta del comportamiento visible para el usuario y de la presión sobre recursos.

Cómo elegir

RED y las Golden Signals muestran el síntoma visible para el usuario. USE examina si un recurso finito puede explicarlo. Los métodos adquieren valor cuando conducen a la siguiente decisión, no cuando existen como tres carpetas independientes de dashboards.

Cardinalidad: cuando una etiqueta rompe el sistema de métricas

Los sistemas de métricas identifican una serie temporal mediante el nombre de la métrica y su conjunto completo de etiquetas. Cada combinación única crea otra serie, con costo de almacenamiento, memoria, indexación, consulta y red.

Esta métrica es peligrosa:

http_requests_total{
  user_id,
  transaction_id,
  request_id,
  timestamp
}

Cada solicitud puede crear una combinación nueva. La métrica deja de comportarse como agregado y se convierte en un event store costoso implementado con la señal equivocada.

Un diseño más defendible sería:

http_requests_total{
  service,
  operation,
  status_code,
  region
}

Estas dimensiones están acotadas y permiten agregaciones operativas.

La documentación de Prometheus advierte expresamente que valores de alta cardinalidad o sin límite, como user IDs y correos electrónicos, no deben utilizarse como labels. El principio se extiende más allá de Prometheus: las dimensiones casi únicas pertenecen a logs o trazas, no a la identidad de una métrica.

Por qué la cardinalidad se multiplica

Supongamos que una métrica de duración utiliza estas dimensiones observadas:

• 12 servicios.
• 40 operaciones.
• 5 clases de estado.
• 6 regiones.

El límite superior teórico es:

12 × 40 × 5 × 6 = 14,400 series temporales

Si se agregan 100,000 user IDs activos:

14,400 × 100,000 = 1,440,000,000 combinaciones posibles

El backend quizá no observe todas las combinaciones, pero cada conjunto nuevo sigue creando una serie. Incluso una fracción pequeña de ese límite puede desbordar ingesta, memoria, retención y rendimiento de consultas.

La cardinalidad no es solo un problema de almacenamiento

También provoca:

• Dashboards y alertas lentos.
• Consultas amplias y costosas.
• Mayor presión de memoria en Collector y backend.
• Costos impredecibles durante picos de tráfico.
• Investigaciones más largas porque las consultas expiran.
• Puntos ciegos cuando la plataforma empieza a descartar telemetría.

Las dimensiones operativas acotadas ya se multiplican. Añadir un identificador por usuario transforma la métrica de una señal agregada en un generador de series sin límite.

Prueba de decisión para una etiqueta

Antes de añadir una label a una métrica, pregunta:

1. ¿El conjunto de valores está acotado?
2. ¿Cuál es la cantidad actual y proyectada de valores distintos?
3. ¿La dimensión permite tomar una decisión operativa o solo satisface curiosidad?
4. ¿La pregunta puede responderse mediante logs o trazas?
5. ¿Qué ocurre si un cliente defectuoso genera valores arbitrarios?
6. ¿La dimensión requiere resolución completa o puede normalizarse?

Para métricas HTTP, utiliza rutas normalizadas como /orders/{orderId} en lugar de paths crudos como /orders/8129.

El sampling de trazas como decisión de ingeniería

Trazar cada solicitud puede ser aceptable con poco volumen, pero resulta costoso en sistemas de alto throughput. Sampling es la decisión de conservar y exportar solo una parte de la población de trazas.

El objetivo no es minimizar datos a cualquier costo. Es preservar evidencia suficiente para responder preguntas operativas mientras el overhead de la aplicación, la capacidad del Collector, la ingesta y la retención permanecen dentro del presupuesto.

Head sampling

Head sampling decide cerca del inicio de la traza, antes de conocer el resultado final.

Ventajas:

• Simple.
• Bajo overhead de infraestructura.
• Volumen predecible.
• Disponible en SDKs y primeras etapas del pipeline.

Limitaciones:

• Puede descartar una solicitud que posteriormente se vuelve lenta o falla.
• Una probabilidad fija puede subrepresentar modos de fallo raros.
• La decisión solo puede utilizar información disponible al crear la traza.

Tail sampling

Tail sampling decide después de recibir suficientes spans para evaluar el resultado de la traza.

Ventajas:

• Permite conservar trazas con errores.
• Permite conservar trazas lentas.
• Admite reglas basadas en atributos o duración completa.
• Puede retener una muestra menor y representativa del tráfico exitoso.

Limitaciones:

• Requiere buffering y memoria adicional.
• Introduce latencia de decisión.
• Exige que todos los spans de una traza lleguen al mismo punto de decisión.
• Es más complejo de escalar y operar.

El procesador de tail sampling de OpenTelemetry Collector agrupa spans por Trace ID y requiere routing consistente para que todos los spans de una traza alcancen la misma instancia responsable de decidir.

Una política de sampling defendible

Un punto de partida frecuente es:

• Conservar todas las trazas clasificadas como error.
• Conservar trazas que superen umbrales de latencia específicos por operación.
• Conservar trazas de operaciones raras o de alto valor.
• Conservar una muestra estadísticamente útil de tráfico exitoso con latencia normal.
• Aplicar límites más estrictos a endpoints conocidos por su ruido.
• Elevar temporalmente la muestra durante una investigación controlada únicamente si el pipeline tiene capacidad.

Los umbrales deben ser específicos por operación. Quinientos milisegundos pueden ser críticos para una consulta de caché y normales para un reporte prolongado.

Qué puede salir mal

• Muestrear solo fallos elimina la línea base saludable necesaria para comparar.
• Un head sampling uniforme de 1 % puede omitir por completo operaciones de bajo volumen.
• Tail sampling puede saturar el Collector durante un incidente, precisamente cuando aumentan el volumen y el valor de las trazas.
• Decisiones independientes de sampling entre servicios pueden producir trazas incompletas.
• Incrementar la muestra sin revisar cuotas del backend puede convertir un incidente de aplicación en un incidente de telemetría.

Cómo validar el sampling

Monitorea el propio sistema de sampling:

• Spans recibidos, aceptados, muestreados y descartados.
• Latencia de decisión.
• CPU y memoria del Collector.
• Fallos de colas y exporters.
• Trazas conservadas por cada política.
• Cobertura por servicio y operación.
• Trazas rotas o incompletas.

El sampling funciona cuando los investigadores aún pueden comparar ejecuciones saludables y degradadas, preservar fallos raros y consultar el backend durante incidentes de máxima carga.

Alertar por impacto y diagnosticar mediante causas

Una alerta debe comunicar que una condición requiere acción. Las señales más confiables para paging suelen expresar impacto sobre el usuario o el servicio:

• Disponibilidad por debajo del objetivo.
• Tasa de errores que consume demasiado rápido el presupuesto de error.
• SLI de latencia fuera del umbral acordado.
• Workflow crítico que no completa.
• Cola durable que excede su antigüedad máxima aceptable.

Google SRE recomienda alertar a partir de SLO porque alinea el paging con la confiabilidad que perciben los usuarios. La guía de Prometheus también recomienda alertar sobre síntomas y utilizar consolas para identificar causas.

Señales de síntoma

Ejemplos:

• Más de 2 % de solicitudes de autorización fallan según una regla de burn rate con múltiples ventanas.
• P95 de una operación crítica supera su objetivo y existe suficiente tráfico para que la señal sea confiable.
• La finalización exitosa de un checkout cae por debajo del SLI objetivo.
• La antigüedad del mensaje pendiente más antiguo supera el objetivo de recuperación.

Señales de causa

Ejemplos:

• La utilización de CPU es alta.
• El pool de conexiones no tiene conexiones libres.
• El espacio en disco cae por debajo de un umbral.
• Crece la cola de un thread pool.
• Una dependencia responde con throttling.

Las señales de causa son valiosas para diagnosticar y, en ocasiones, prevenir. Son más débiles como reglas principales de paging porque la misma causa puede no generar impacto, mientras que el impacto puede surgir por una causa nunca codificada.

Cuándo se justifica una alerta de causa

Una alerta preventiva basada en causa puede ser apropiada cuando:

• El recurso está por cruzar un límite irreversible o de recuperación lenta.
• La condición amenaza la integridad de los datos.
• Es necesario actuar antes de que aparezca impacto visible.
• La señal tiene propietario y runbook claros.
• La evidencia histórica muestra una relación confiable con consecuencias graves.

Agotamiento de disco, expiración de certificados, reservas de capacidad agotadas y fallos de replicación pueden justificar alertas preventivas. La decisión depende de la capacidad de actuar y de la consecuencia, no de una regla absoluta que considere incorrectas todas las alertas de causa.

Criterios de calidad de una alerta

Una alerta que despierta a una persona debe tener:

• Propietario identificado.
• Descripción clara del impacto.
• Enlaces al servicio, SLO, dashboard y runbook afectados.
• Suficientes labels para enrutarla correctamente, pero no tantas como para duplicar páginas por un mismo incidente.
• Una condición que se cierre automáticamente al recuperarse el servicio.
• Un camino de respuesta probado.
• Severidad coherente con la urgencia, no con la preferencia del equipo.

Cómo evitar la fatiga de alertas

La fatiga de alertas no significa únicamente «demasiadas alertas». Es la pérdida de confianza provocada por notificaciones ruidosas, duplicadas, no accionables, obsoletas o mal priorizadas.

Google SRE advierte que las páginas de baja prioridad interrumpen el trabajo y pueden hacer que alertas graves reciban menos atención. También recomienda controlar el fan-out para que una condición anormal no genere varias páginas independientes.

Causas frecuentes

• Umbrales estáticos que ignoran volumen de tráfico o ventana temporal.
• Alertas separadas por cada síntoma downstream de un mismo incidente.
• Falta de distinción entre page, ticket y evento informativo.
• Alertas sin propietario.
• Reglas que describen una métrica, pero no la acción requerida.
• Alertas que permanecen abiertas después de la recuperación.
• Flapping repetido alrededor de un umbral.
• Cada instancia genera paging por separado para un evento del servicio completo.
• Alertas creadas durante un incidente pasado y nunca revisadas.

Revisión práctica

Para cada alerta, pregunta:

1. ¿Qué decisión debe tomar quien la recibe?
2. ¿Una persona debe actuar ahora?
3. ¿Qué objetivo del usuario o del sistema está amenazado?
4. ¿La misma condición puede agruparse a nivel de servicio o incidente?
5. ¿La notificación aporta contexto suficiente para iniciar el triage?
6. ¿Existe un runbook y se ha ejercitado?
7. ¿Cuál es la relación esperada entre alertas e incidentes reales?
8. ¿Cuándo fue útil por última vez esta regla?

Una alerta sin acción inmediata debe convertirse en ticket, reporte o anotación de dashboard, no en page.

Qué debe mostrar un dashboard operativo

Un dashboard no es una pared de métricas disponibles. Es una interfaz para tomar decisiones.

Cada panel debe responder una pregunta de producción. El dashboard principal de un servicio debe permitir que la persona de guardia determine impacto, alcance, cambios recientes y la siguiente ruta de investigación en pocos minutos.

Jerarquía recomendada

1. Impacto sobre usuarios y SLO

• SLI de disponibilidad o finalización exitosa.
• SLI de latencia y percentiles relevantes.
• Estado del presupuesto de error y burn rate.
• Finalización de recorridos críticos.

2. Demanda y alcance

• Tasa de llegada de tráfico o trabajo.
• Operación, región, clase de tenant o canal cuando sean dimensiones acotadas y operativamente relevantes.
• Versión actual y distribución del despliegue.

3. Comportamiento del servicio

• Tasa de errores por clasificación estable.
• Distribución de duración por operación.
• Tasas de retry, timeout, cancellation y rejection.

4. Saturación y dependencias

• Profundidad y antigüedad de cola.
• Presión sobre pools de conexiones y threads.
• Latencia y tasa de errores de dependencias.
• CPU throttling, presión de memoria, disco y red según corresponda.

5. Cambios recientes

• Despliegues.
• Cambios de configuración.
• Cambios de feature flags.
• Eventos de capacidad.
• Incidentes de dependencias.

Qué no debe incluir

• Decenas de paneles con la misma jerarquía visual.
• Métricas sin unidad.
• Promedios sin distribuciones cuando importa la latencia de cola.
• Datos crudos por instancia en la página principal, salvo que permitan un drill-down inmediato.
• Gráficos sin propietario ni decisión conocida.
• Gauges decorativos cuyos umbrales no tienen significado operativo.
• KPI de negocio mezclados con síntomas técnicos sin una relación explícita.

Tabla de decisiones del dashboard

El dashboard principal no debe intentar reemplazar los backends de trazas o logs. Debe dirigir al ingeniero hacia la siguiente consulta de mayor valor.

Caso de producción: una API se vuelve lenta sin fallar

Consideremos una authorization-api genérica con este comportamiento normal:

• Entre 8,000 y 10,000 solicitudes por segundo.
• Latencia P50: 95 ms.
• Latencia P95: 220 ms.
• Latencia P99: 410 ms.
• Tasa de errores: 0.4 %.
• Objetivo de latencia: 95 % de las solicitudes por debajo de 350 ms.

A las 22:10 UTC, P95 aumenta a 890 ms y P99 alcanza 1.7 segundos. El tráfico permanece cerca de 9,200 solicitudes por segundo y la tasa de errores solo aumenta de 0.4 % a 0.6 %.

El servicio no está «caído», pero consume su presupuesto de latencia y el rendimiento percibido por los usuarios se degradó.

Paso 1 — Detectar el síntoma

La alerta debe vincularse al SLI de latencia o al consumo del presupuesto de error, no únicamente a CPU o a una métrica del pool.

Observado:

P95: 220 ms -> 890 ms
P99: 410 ms -> 1,700 ms
Tasa de solicitudes: 9,100 -> 9,200 solicitudes/s
Tasa de errores: 0.4% -> 0.6%

Conclusión inicial:

• El problema principal es latencia, no disponibilidad.
• Un incremento de demanda no es la explicación evidente.
• Una tasa de errores estable no convierte el incidente en inocuo.

Paso 2 — Establecer el alcance

Desglosa dimensiones acotadas:

• Operación.
• Región.
• Versión del servicio.
• Clasificación de respuesta.
• Ruta hacia la dependencia.

La degradación aparece únicamente en:

operation = authorize
region = west
service.version = 2026.07.12.3

Las demás operaciones y regiones permanecen dentro de sus distribuciones normales.

Decisión:

• Evitar una mitigación global hasta que la evidencia demuestre riesgo global.
• Comparar la versión y región afectadas con un control saludable.

Paso 3 — Comparar trazas saludables y lentas

Una traza saludable:

Gateway                              12 ms
Trabajo local de Authorization API   58 ms
Llamada a Risk Service              118 ms
Consulta a base de datos             31 ms
Total                               219 ms

Una traza lenta:

Gateway                              13 ms
Trabajo local de Authorization API   71 ms
Espera para adquirir conexión       623 ms
Llamada a Risk Service              131 ms
Consulta a base de datos             34 ms
Total                               872 ms

La llamada remota solo es 13 milisegundos más lenta que en la línea base. La mayor parte de la latencia adicional ocurre antes de iniciar la llamada.

La traza localiza el retraso dominante en la adquisición de conexiones. Todavía no demuestra por qué el pool está saturado ni si la versión nueva lo causó.

Paso 4 — Correlacionar logs mediante Trace ID

Busca logs estructurados correspondientes a las trazas lentas:

{
  "service.name": "authorization-api",
  "service.version": "2026.07.12.3",
  "operation": "authorize",
  "trace_id": "4e8f2c7b6bb44df19cd9d6f0db8916a2",
  "event": "connection_pool.acquire",
  "pool.active": 40,
  "pool.idle": 0,
  "pool.waiters": 173,
  "pool_wait_ms": 623,
  "result": "acquired"
}

Otro log muestra que las solicitudes finalmente completan. Esto explica el pequeño aumento de errores: están esperando en lugar de fallar inmediatamente.

Paso 5 — Comprobar hipótesis competidoras

Hipótesis posibles:

1. Risk Service está lento.
2. Aumentó la latencia de red.
3. El pool local es demasiado pequeño para la concurrencia actual.
4. La versión 2026.07.12.3 fuga conexiones o las mantiene ocupadas más tiempo.
5. Una política de retry aumentó las llamadas concurrentes hacia la dependencia.

La evidencia debilita las hipótesis 1 y 2 porque el tiempo de ejecución downstream permanece cerca de la línea base. Favorece una hipótesis de espera local, pero todavía no distingue entre capacidad insuficiente, mayor tiempo de retención, leak o amplificación por reintentos.

Debe revisarse:

• Conexiones activas y libres, waiters, duración de adquisición y cantidad de timeouts.
• Duración durante la cual cada conexión permanece ocupada.
• Llamadas a la dependencia por solicitud entrante.
• Reintentos por resultado.
• Comparación entre versiones.
• Concurrencia y rate limits de la dependencia.

La comparación revela:

2026.07.12.2: 1.02 llamadas a la dependencia por solicitud
2026.07.12.3: 1.84 llamadas a la dependencia por solicitud

Una ruta nueva está reintentando una clase de respuesta que no debería reintentarse. Los intentos adicionales consumen conexiones, incrementan los waiters y amplifican la latencia sin producir todavía un aumento grande de errores.

Se está formando una tormenta de reintentos, aunque el tráfico que llega a la API pública no haya cambiado.

Paso 6 — Elegir una mitigación

Las alternativas incluyen:

• Desactivar mediante feature flag el retry incorrecto.
• Hacer rollback de la versión afectada en la región.
• Reducir la concurrencia de la operación afectada.
• Aplicar degradación controlada sobre la ruta opcional hacia la dependencia.
• Aumentar el pool únicamente después de validar capacidad downstream y costo local.

Aumentar el pool de inmediato es tentador, pero arriesgado. Puede trasladar la saturación al servicio downstream, aumentar el overhead de conexiones o esconder el defecto de retry. La mitigación debe eliminar primero la amplificación antes de añadir capacidad.

Decisión:

• Desactivar el retry para la clase de respuesta no reintentable.
• Mantener preparado el rollback si la latencia no se recupera.

Para comprender la relación de diseño entre timeouts, retries y fallos en cascada, cada mecanismo debe tratarse como parte de un único sistema de control de carga, no como una opción aislada de librería.

Paso 7 — Validar la recuperación

No se cierra un incidente porque el cambio de configuración se aplicó correctamente. Debe validarse el resultado del sistema:

P95: 890 ms -> 245 ms
P99: 1,700 ms -> 460 ms
Waiters del pool: 173 -> 4
Llamadas a dependencia/solicitud: 1.84 -> 1.03
Tasa de errores: 0.6% -> 0.4%
Consumo del SLO de latencia: vuelve por debajo del umbral de alerta

También debe verificarse:

• Que no aumenten los errores en ninguna región.
• Que la dependencia no se sature.
• Que cola y pool permanezcan estables durante una ventana de observación apropiada.
• Que las trazas antes lentas vuelvan a presentar una forma comparable con las saludables.

Paso 8 — Evitar la recurrencia

Añade o mejora:

• Métrica de reintentos por operación y resultado.
• Atributo acotado de traza para el motivo del retry.
• Histogram de duración de adquisición de conexiones.
• Comparación en dashboard entre solicitudes entrantes e intentos hacia dependencias.
• Prueba de carga que incluya la clase de respuesta que disparó los reintentos.
• Prueba de política que demuestre que las respuestas no reintentables permanecen así.
• Panel de comparación de versiones desplegadas.

El método completo de investigación corresponde a una pieza especializada para evitar duplicar aquí todo el marco de diagnóstico: cómo investigar un incidente con métricas, logs y trazas.

El proceso avanza desde impacto y alcance hacia evidencia de ejecución, comprobación de hipótesis, mitigación reversible y validación medible. Evita saltar desde una métrica sospechosa hacia un cambio permanente de configuración.

Errores frecuentes de instrumentación

1. Recolectar señales que no pueden correlacionarse

Las métricas usan un nombre de servicio, los logs otro y las trazas omiten la versión. Las zonas horarias difieren y no existen marcadores de despliegue.

Consecuencia: El equipo consume parte del incidente demostrando que los registros pertenecen al mismo componente.

Corrección: Estandariza identidad de recursos y timestamps. Inserta Trace ID y Span ID en los logs. Mantén consultables los metadatos de despliegue.

2. Instrumentar únicamente las fronteras del framework

La instrumentación automática captura HTTP y bases de datos, pero no la etapa de dominio que espera un permiso, evalúa reglas o activa un fallback.

Consecuencia: Un span grande oculta la operación relevante.

Corrección: Añade spans manuales o eventos en fronteras de decisión, no alrededor de cada función.

3. Crear un span por cada función trivial

El exceso de spans aumenta costo y vuelve ilegibles las trazas.

Consecuencia: Los tiempos importantes quedan enterrados bajo detalle de implementación.

Corrección: Crea spans para llamadas remotas, fronteras asíncronas, etapas costosas y operaciones con valor diagnóstico.

4. Utilizar identificadores crudos como labels de métricas

Request IDs, user IDs y URLs crudas crean series sin límite.

Consecuencia: El backend de métricas se vuelve costoso o deja de responder durante alto tráfico.

Corrección: Normaliza dimensiones y traslada el contexto único hacia logs o trazas.

5. Registrar la misma excepción en cada capa

Una excepción downstream se registra en cliente, servicio, controlador, gateway y handler global.

Consecuencia: Un fallo aparece como cinco eventos independientes y puede disparar alertas duplicadas.

Corrección: Registra el evento donde la propiedad y el contexto sean más fuertes; propaga un estado estructurado sin duplicar ruido.

6. Aplicar sampling sin verificar cobertura

Se activa un head sample global de 1 % y se considera suficiente.

Consecuencia: Desaparecen operaciones de poco volumen y fallos raros.

Corrección: Mide cobertura por operación y resultado; conserva errores, trazas lentas y una línea base saludable.

7. Alertar por cada anomalía

Cada umbral de recurso genera paging de manera independiente.

Consecuencia: Un solo incidente produce una tormenta de notificaciones y la guardia no puede identificar el impacto principal.

Corrección: Genera paging por síntomas significativos del servicio, agrupa causas relacionadas y utiliza métricas de causa para diagnóstico o tickets preventivos.

8. Tratar la observabilidad como una migración de backend

Se cambia de proveedor, pero se mantienen nombres inconsistentes, contexto ausente, alertas débiles y dashboards decorativos.

Consecuencia: Cambia la sintaxis de consulta; la capacidad diagnóstica no mejora.

Corrección: Define preguntas, esquemas, propiedad y validación antes de elegir o migrar el backend.

Checklist operativo

Instrumentación

• Cada servicio tiene service.name, versión, entorno e identidad de despliegue estables.
• W3C Trace Context se propaga a través de fronteras síncronas y asíncronas soportadas.
• Los logs estructurados incluyen Trace ID y Span ID cuando existe contexto.
• Las operaciones críticas tienen instrumentación manual cuando la automática es insuficiente.
• Los nombres de métricas incluyen unidades y siguen una convención compartida.
• Los atributos sensibles y de alta cardinalidad se revisan expresamente.
• El overhead se mide bajo carga realista.

Métricas

• Existen métricas RED o equivalentes para componentes orientados a solicitudes.
• Existen señales USE para recursos finitos que pueden saturarse.
• La latencia se registra como distribución apta para calcular los percentiles necesarios.
• Se mide antigüedad de cola cuando el tiempo de espera importa más que su longitud.
• Retry, timeout, rejection y fallback son medibles.
• Los SLI y el presupuesto de error son visibles.

Logs

• Los logs usan campos estructurados y no dependen de parsing de mensajes.
• Los códigos de error son estables y están documentados.
• Se controla el registro duplicado de excepciones.
• Los campos sensibles se redactan antes de exportarse.
• Retención e indexación corresponden al valor de investigación.

Trazas

• Pueden compararse trazas saludables y degradadas.
• Los nombres de spans están acotados y no contienen IDs únicos.
• Las llamadas remotas, colas y esperas relevantes son visibles.
• El sampling conserva errores, solicitudes lentas y una línea base exitosa.
• El routing del Collector no rompe las decisiones de tail sampling.
• Se monitorean trazas incompletas y descartadas.

Alertas y dashboards

• Las alertas de paging expresan impacto o un fallo inminente de consecuencias graves.
• Cada page tiene propietario y runbook.
• Un incidente no produce fan-out descontrolado.
• El dashboard comienza con SLO, tráfico, errores, latencia y saturación.
• Los cambios de despliegue y configuración aparecen en la misma ventana temporal.
• Cada panel responde una pregunta operativa explícita.

Validación

• Se utilizó un fallo controlado para probar la ruta completa de investigación.
• El equipo puede pasar de la alerta a trazas y logs afectados sin añadir instrumentación.
• El éxito de una mitigación se valida mediante señales de usuario, servicio y recursos.
• La saturación y pérdida de datos del pipeline de telemetría son observables.
• Las acciones posteriores al incidente incluyen calidad de señales y cobertura de regresión, no solo alertas nuevas.

Conclusión

El monitoreo es necesario porque no se puede responder a una condición que no se detectó. La observabilidad es necesaria porque la detección rara vez explica un fallo distribuido.

El objetivo práctico no es recolectar la mayor cantidad posible de telemetría. Es construir un sistema controlado de evidencia:

• Las métricas revelan impacto y tendencia.
• Las trazas localizan el recorrido de ejecución.
• Los logs explican eventos y estado.
• Una identidad compartida permite unir las señales.
• El sampling y el control de cardinalidad mantienen operable la plataforma.
• Las alertas orientadas al SLO involucran personas ante condiciones significativas.
• Los dashboards dirigen la siguiente decisión.

La validación final es operativa. Cuando ocurre un incidente desconocido, el equipo debe poder determinar el alcance, comparar comportamiento saludable y degradado, comprobar hipótesis competidoras, aplicar una mitigación reversible y demostrar que el servicio se recuperó.

Esa secuencia es también el límite de lo que conviene automatizar. Cuando la evidencia ya se obtiene de forma verificable, la pregunta deja de ser qué instrumentar y pasa a ser quién interpreta el resultado: observabilidad empresarial con IA trata dónde ubicar un modelo sobre estos controles sin que termine decidiendo si el sistema está sano.

Preguntas frecuentes

¿Observabilidad y monitoreo son lo mismo?

No. El monitoreo consiste en recopilar y evaluar señales frente a condiciones esperadas. La observabilidad es la capacidad del sistema para permitir investigaciones mediante la evidencia que emite. Un sistema de monitoreo maduro contribuye a la observabilidad, pero dashboards y alertas no la garantizan.

¿Cuáles son los tres pilares de la observabilidad?

Métricas, logs y trazas son un modelo operativo útil porque aportan agregación, contexto de eventos y recorridos de ejecución. «Tres pilares» es una simplificación, no una definición técnica completa. La propagación de contexto, identidad de recursos, eventos, baggage, Semantic Conventions y perfiles también pueden formar parte del sistema.

¿Qué diferencia existe entre Trace ID y Correlation ID?

Trace ID identifica una ejecución distribuida y se propaga mediante estándares de tracing. Correlation ID es definido por la aplicación y puede representar un flujo de negocio que abarca varias trazas. Pueden coexistir, pero no son intercambiables.

¿Qué es OpenTelemetry?

OpenTelemetry es un framework de observabilidad independiente del proveedor que define APIs, SDKs, Semantic Conventions, propagación de contexto, protocolos y Collector para telemetría como trazas, métricas y logs. Estandariza instrumentación y transporte; no decide por el equipo las preguntas operativas ni la estrategia del backend.

¿Debo usar RED o USE?

Usa RED para el comportamiento de servicios orientados a solicitudes y USE para recursos finitos. RED permite detectar cambios visibles en rate, errors y duration. USE ayuda a comprobar si utilización, saturación o errores de recursos explican el síntoma. Las Four Golden Signals ofrecen una vista compacta del servicio que se superpone con ambos.

¿Cuándo debo usar P95 o P99?

Utiliza el percentil que represente la población de usuarios, criticidad de la operación, volumen de tráfico y SLO que necesitas proteger. P99 expone la cola de la distribución, pero puede ser inestable en ventanas de poco volumen. No elijas un percentil porque esté de moda; elígelo porque corresponde a un objetivo explícito y tiene observaciones suficientes para interpretarlo.

La explicación estadística completa corresponde a la guía dedicada de percentiles P50, P95 y P99.

¿Cómo evito la fatiga de alertas?

Reduce el paging a condiciones significativas y accionables. Agrupa síntomas relacionados, alinea pages con SLO o riesgos de alta consecuencia, asigna propiedad y runbooks, y revisa las reglas que se disparan repetidamente sin requerir acción. Una alerta que no cambia una decisión debe convertirse en ticket, reporte o señal de dashboard.

Referencias técnicas

• OpenTelemetry — Observability primer: opentelemetry.io/docs/concepts/observability-primer
• OpenTelemetry — Signals: opentelemetry.io/docs/concepts/signals
• OpenTelemetry — Instrumentation: opentelemetry.io/docs/concepts/instrumentation
• OpenTelemetry — Semantic Conventions: opentelemetry.io/docs/concepts/semantic-conventions
• OpenTelemetry — Logs Data Model: opentelemetry.io/docs/specs/otel/logs/data-model
• OpenTelemetry — Metrics API: opentelemetry.io/docs/specs/otel/metrics/api
• OpenTelemetry Collector Contrib — Tail Sampling Processor: github.com/open-telemetry/opentelemetry-collector-contrib
• W3C — Trace Context Level 2: w3.org/TR/trace-context-2
• Google — SRE: Monitoring Distributed Systems: sre.google/sre-book/monitoring-distributed-systems
• Google — SRE Workbook: Alerting on SLOs: sre.google/workbook/alerting-on-slos
• Prometheus — Instrumentation: prometheus.io/docs/practices/instrumentation
• Prometheus — Metric and Label Naming: prometheus.io/docs/practices/naming
• Prometheus — Alerting: prometheus.io/docs/practices/alerting
• Brendan Gregg — The USE Method: brendangregg.com/usemethod.html
• Tom Wilkie — The RED Method: grafana.com/blog/the-red-method

Jorel del Portal

Jorel del Portal es ingeniero de sistemas especializado en arquitectura, integración, resiliencia y observabilidad de plataformas críticas. Diseña sistemas, construye productos y documenta decisiones reales de ingeniería.

Acerca de LinkedIn YouTube X TikTok Instagram