Gray failures: cuando nada está «caído» pero todo va mal

Un pod con 8 GB de heap Java lleva tres días subiendo su consumo de memoria un par de puntos porcentuales cada hora. El liveness probe lo comprueba cada diez segundos y siempre recibe la misma respuesta: 200, cuarenta milisegundos. Ese proceso está, a todos los efectos que mide Kubernetes, perfectamente sano. Pero cuando ese mismo pod atiende una petición real de un cliente, el recolector de basura se dispara por la presión de memoria y la respuesta tarda ocho segundos en volver. El técnico de guardia no tiene ninguna alerta abierta. El cliente, sin embargo, ha cerrado la pestaña hace rato.

Ese hueco entre lo que mide tu comprobación de salud y lo que sufre de verdad el cliente tiene origen académico, no de marketing. Un grupo de ingenieros de Microsoft Azure lo documentó en 2017 en un paper que sigue siendo la referencia obligada del tema: Huang et al., «Gray Failure: The Achilles’ Heel of Cloud-Scale Systems», presentado en el workshop HotOS de la ACM. Lo llamaron precisamente así, fallo gris, porque describía algo que ni los propios ingenieros de Azure sabían nombrar bien hasta entonces: sistemas que a duras penas cojean sin llegar nunca a caerse del todo, y que por eso mismo escapan a cualquier detector binario de arriba/abajo.

Qué es exactamente un gray failure

Los autores proponen una definición precisa que merece la pena traducir bien: un sistema sufre un fallo gris cuando al menos una aplicación observa que algo no funciona correctamente, pero el detector de fallos —tu check, tu alerta, tu health probe— sigue observando que todo está sano. A esta discrepancia la llaman differential observability, y es la pieza que de verdad importa: no es que el fallo sea pequeño, es que dos observadores del mismo sistema llegan a conclusiones opuestas sobre su estado.

El nombre «gris» cobra sentido si piensas en un semáforo de dos colores. Negro o caído: el proceso ha muerto, el health check falla, la alerta salta. Blanco o sano: todo responde según lo esperado. El gris es la zona intermedia donde el componente sigue vivo y sigue contestando «sí» a la pregunta exacta que le hace tu check, mientras por debajo se degrada. El propio paper enumera ejemplos que cualquier SRE reconocerá al instante: degradación severa de rendimiento, pérdida de paquetes intermitente, I/O errático, memory thrashing, presión de capacidad, excepciones no fatales que no tumban el proceso pero sí lo dejan cojo.

Por qué el baseline dinámico no siempre lo ve

Herramientas como Dynatrace con Davis AI o los baselines automáticos de Datadog prometen justamente resolver esto: en vez de un umbral fijo, aprenden el comportamiento «normal» de cada métrica y avisan cuando algo se desvía. Funciona razonablemente bien para picos evidentes. Pero tiene tres puntos ciegos estructurales que conviene conocer antes de confiar en él a ciegas:

• Aprende de su propio histórico. Si la degradación es lenta y progresiva —una fuga de memoria que crece durante días, un disco que va perdiendo IOPS poco a poco— el baseline se reajusta al mismo ritmo que el problema. Literalmente aprende que lo malo es lo nuevo normal.
• Trabaja con agregados. Si el problema afecta a un segmento pequeño del tráfico —una región concreta, un tenant, un tipo de dispositivo— la media o el percentil global lo diluye. El usuario afectado lo sufre al cien por cien; tu p95 agregado apenas se mueve.
• Tiene lógica de estacionalidad. Útil para no disparar falsos positivos cuando el lunes a las 9 hay más tráfico que de costumbre, pero también puede enmascarar un patrón real que coincide justo con ese pico habitual.

Ninguno de los tres es un fallo del producto: son consecuencias inevitables de basar la detección en agregados estadísticos. La mitigación real pasa por definir SLOs por segmento o por recorrido de negocio, no solo por servicio global, y por tratar las señales que vienen directamente del cliente —tickets de soporte, caídas de NPS, quejas en redes— como una fuente de primera clase, no como algo que llega después de que el dashboard ya decía verde.

El problema añadido: la degradación que se autorrepara

Hay una variante todavía más incómoda. El pico dura noventa segundos: el autoscaling reacciona, un retry funciona, el garbage collector termina su ciclo, y el sistema se recupera solo. Nadie tuvo que intervenir. El problema es que, para cuando alguien va a investigar qué pasó, la evidencia fina ya no existe.

Las métricas de alta resolución se agregan a intervalos cada vez más amplios en cuestión de días. Las trazas de ese minuto concreto, si no había ninguna señal de «esto es anómalo» en el instante exacto, probablemente cayeron en el sampling estándar y no se guardaron completas. Davis AI o el motor de anomalías de turno pueden decirte que hubo un problema, cuánto duró y que se resolvió solo —pero sin la traza fina de ese momento, el «por qué» se queda en hipótesis razonadas, no en evidencia.

La defensa práctica contra esto es el sampling adaptativo con disparador: cuando una métrica se sale de rango, forzar retención al cien por cien de spans y logs de esa ventana durante unos minutos, en vez de fiarse del sampling homogéneo de siempre. Si esta lógica no está configurada, el equipo se queda exactamente en el peor sitio posible: sabiendo que pasó algo, sin poder decir el qué.

El punto ciego que nadie reconoce en voz alta: la costura entre capas

Aquí llega la parte más honesta del artículo, y la que menos se lee en contenido patrocinado por un vendor. El OneAgent de Dynatrace o el Agent de Datadog te dan CPU, memoria, I/O de disco, latencia de red desde dentro de la máquina —pero eso es instrumentación de host y aplicación, no de hardware físico. Para eso, Dynatrace sí ofrece extensiones SNMP en su Hub (switches, cabinas de almacenamiento, sensores de temperatura y voltaje vía el MIB de entidad-sensor), pero funcionan mediante una ActiveGate haciendo polling aparte, como una pieza que hay que activar y configurar de forma explícita, no como algo que llega gratis con el agente de aplicación. Y hay huecos reales que ni con esa capa se cubren: no hay lectura SMART predictiva nativa de un disco concreto, y el soporte de IPMI depende de puentes de terceros (por ejemplo, un plugin de Telegraf que reenvía los sensores al Metric API), no de una integración propia. Eso sigue siendo terreno natural de Zabbix, Checkmk o cualquier plataforma nacida para infraestructura física, no para servicios —no porque Dynatrace u otras suites de APM no puedan tocar esa capa en absoluto, sino porque hacerlo exige montar y mantener una pieza aparte, con su propio ciclo de configuración, en vez de heredar la cobertura del agente principal.

Cuando el fallo gris vive exactamente en esa capa —un disco de una cabina RAID empezando a fallar, degradando el I/O de todas las máquinas virtuales que dependen de él— tu APM ve el síntoma (latencia de disco alta en varios hosts a la vez) pero no la causa física, porque nunca tuvo visibilidad de esa capa. Y al revés funciona igual: es habitual encontrar en foros de sysadmins el relato de equipos que, apoyados en una única suite de ITSM/ITOM de corte más clásico, tienen visión perfecta de topología e infraestructura pero se quedan ciegos en cuanto el problema es de código o de una dependencia externa dentro de la aplicación.

La conclusión práctica: «todo en una sola herramienta» es una promesa de interfaz, no de cobertura. Cada plataforma reduce la zona gris en su propia capa, y el fallo gris de verdad casi siempre se esconde en la costura entre capas —donde el origen está en una y el síntoma se manifiesta en otra, sin que ninguna tenga el contexto completo para unir ambas por sí sola.

Las tres patas que hacen falta para reducir la zona gris

Ningún tipo de señal por separado cubre el hueco. Hacen falta las tres, y cada una cubre el punto ciego de la anterior:

• Sintético. Es el canario permanente: realiza una comprobación simulada, ejecutada desde fuera de la infraestructura, del recorrido crítico de la aplicación web o del frontend —el inicio de sesión, el proceso de compra, la transacción que de verdad importa— cada pocos minutos, sin depender de que haya tráfico real ni de que un cliente decida quejarse. Su ventaja frente al baseline aprendido es que es determinista: si esa comprobación empieza a tardar el doble sin que haya tráfico real que lo justifique, es una señal limpia que ningún agregado va a diluir.
• RUM (Real User Monitoring). Da la verdad del usuario real, con toda su variabilidad de dispositivo, red y geografía. Es el que detecta justo el caso que el agregado global esconde: el cinco por ciento de usuarios afectados. Por sí solo no explica el porqué, solo dónde duele.
• Trazas de backend y frontend. Unen el «duele aquí» con la causa concreta: el servicio, la query, la dependencia responsable.

La pieza que de verdad suele faltar es la correlación entre las tres por el mismo identificador. Tanto Dynatrace como Datadog Synthetics permiten que el propio monitor sintético inyecte un traceparent real y quede enlazado a la traza de esa ejecución —pero en ninguno de los dos casos llega así por defecto: en Dynatrace hay que tener activado explícitamente el soporte de W3C Trace Context, y en Datadog hay que declarar en la configuración del test qué URLs deben recibir esas cabeceras de integración con APM. Configurado ese enlace, cuando el sintético falla aterrizas directamente en la traza exacta de esa ejecución, no en «algo pasó por esta hora, a ver si encuentro la traza parecida». Esa diferencia, correlación real frente a correlación por proximidad temporal, es la que separa una investigación de veinte minutos de una de dos horas.

Correlacionar infraestructura y APM sin comprar una única suite

La buena noticia es que el mercado ya está lo bastante maduro como para no depender de una sola herramienta que lo prometa todo. Las plataformas de APM más extendidas aceptan ingesta de métricas custom pensada exactamente para este escenario:

• Dynatrace ofrece la Metrics API v2, con un protocolo de línea simple que permite crear un custom device —por ejemplo, una cabina de almacenamiento o un switch— y enviarle datos SNMP o IPMI capturados por un script externo, con sus propias dimensiones.
• Datadog acepta métricas custom vía Agent, DogStatsD, API REST o directamente por OTLP, sin límite fijo de cardinalidad —se factura por volumen, eso sí.
• New Relic resuelve lo mismo con su Metric API, pensada específicamente para reportar datos sin pasar por un agente propio.

En la práctica, esto significa que un script que lea SNMP de la cabina de turno y empuje esos valores al Metrics API de Dynatrace, etiquetados con el mismo hostname que ya usa OneAgent, es perfectamente viable y no especialmente complejo de montar. Lo que marca la diferencia no es la ingesta —eso ya está resuelto por las cuatro APIs anteriores— sino la disciplina de correlación: si ese custom device no comparte namespace o tags con las entidades que ya monitoriza el agente de aplicación, tendrás el dato dentro de la misma interfaz, pero seguirá siendo un silo, solo que ahora en la misma pantalla en vez de en dos pestañas distintas.

Por qué esto importa más de lo que sugiere el gasto en herramientas

Un estudio de Virtana publicado en marzo de 2026, «AI Is Breaking Human-Managed Operations», encuestó a más de 350 responsables senior de infraestructura y operaciones. El dato central: más de la mitad de los profesionales de IT sigue reportando huecos de visibilidad persistentes y observabilidad fragmentada, a pesar de un gasto medio anual en observabilidad que supera los 800.000 dólares por empresa según cifras de Gartner citadas en el propio informe. Un subconjunto de esas organizaciones gasta más de diez millones de dólares al año en un único proveedor.

El mensaje no es sutil: más herramientas y más gasto no cierran la zona gris por sí solos. Lo que la cierra es diseñar deliberadamente la correlación entre lo que ya tienes —mismo esquema de tags y topología, timestamps sincronizados, un punto de agregación de incidentes donde un runbook o un humano puedan cruzar «la cabina reporta degradación» con «la latencia de I/O sube en cuatro hosts» y con «el proceso de compra tarda el triple en una región concreta»— y ver que es el mismo incidente contado desde tres ángulos distintos.

Buenas prácticas para entornos delicados

A modo de checklist, lo que de verdad ayuda a reducir la zona gris en un entorno de producción exigente:

1. Define SLOs por recorrido o segmento de negocio, no solo por servicio agregado —el agregado global esconde justo el problema que más duele a menos usuarios.
2. Mantén sintéticos deterministas sobre las transacciones críticas, inyectando trace context real para poder aterrizar directamente en la traza cuando fallen.
3. Configura sampling adaptativo con disparador: cuando una métrica se sale de rango, fuerza retención completa de esa ventana en vez de fiarte del sampling estándar.
4. No asumas que tu APM ve la infraestructura física. Si tienes cabinas, switches o hardware crítico on-premise, necesitas SNMP/IPMI aparte, correlado por topología y tiempo, no solo por proximidad de dashboards.
5. Diseña la correlación entre herramientas de forma explícita —mismo esquema de tags, timestamps sincronizados— en lugar de asumir que una única suite lo cubrirá todo por comprarla más cara.
6. Trata las señales del cliente real —tickets, quejas, caídas de NPS— como una fuente de detección de primera clase, no como confirmación tardía de algo que el dashboard ya debería haber visto.

La conclusión incómoda

El gray failure no se resuelve comprando la plataforma que promete «root cause automático»: ese motor ayuda, pero siempre necesita afinarse con criterio humano, y ningún vendor va a admitir en su propia documentación que su cobertura tiene límites de capa. El mercado de observabilidad en 2026 ya ofrece herramientas de sobra —sintético, RUM, trazas, APIs de ingesta abiertas entre plataformas— para montar un sistema de verdad, no una sola herramienta que lo prometa todo. La pregunta que de verdad merece la pena hacerse no es qué producto comprar, sino si el diseño de correlación entre lo que ya tienes está pensado a propósito, o si simplemente confías en que la próxima factura más grande venga con menos zona gris incluida.

Fuentes consultadas:

• Huang, R. et al. (2017). «Gray Failure: The Achilles’ Heel of Cloud-Scale Systems». HotOS ’17, ACM.
• Dynatrace. Metrics API v2 — POST ingest data points.
• Datadog. Custom Metrics documentation.
• New Relic. Introduction to the Metric API.
• Virtana (marzo 2026). «AI Is Breaking Human-Managed Operations».