Cuando todos los paneles están en verde y el sistema está fallando

Imagina un sistema que vigila actas en plena noche de recuento electoral. Son las tres de la madrugada y todos los paneles de infraestructura están en verde. La latencia es la de siempre, la memoria va holgada y no hay un solo error de servicio. Y, sin embargo, el sistema falla: las alertas de anomalía se disparan en cascada sobre actas perfectamente legítimas. Es un escenario construido para este artículo, no la crónica de un proyecto. La tentación, cuando el reloj aprieta, es tocar lo que emite las alertas —el modelo— y rezar. Ese reflejo gasta horas y confianza en la dirección equivocada, y es justo lo que una plataforma bien observada te ahorra. Un sistema de datos y modelos de inteligencia artificial que toman decisiones ya no se observa como un conjunto de servicios. Por eso "tenemos Prometheus y Grafana" es una respuesta incompleta.

La observabilidad se pensó para servicios: un microservicio recibe peticiones, las procesa y responde, y basta con vigilar su latencia, sus errores y su saturación. Una plataforma que ingiere datos, los transforma, los pasa por modelos y dispara acciones sobre el resultado rompe ese marco, porque el fallo deja de ser "el servicio está caído" y pasa a ser algo mucho más escurridizo: un lote de datos que entra limpio pero miente, un modelo que responde rápido mientras su precisión se degrada en silencio, o un agente que se queda dando vueltas sin converger. Observar de punta a punta significa instrumentar cuatro capas —la infraestructura, los datos, los modelos y los agentes— con el mismo rigor, y, sobre todo, poder correlacionarlas para bajar de la alerta a la causa sin cambiar de herramienta. Ese último matiz, la correlación, es el que separa una colección de paneles bonitos de una plataforma que responde preguntas que nadie previó.

Prometheus y Grafana son un pilar y medio

Cuando alguien pregunta qué se usa además de Prometheus y Grafana, la pregunta de fondo es si el equipo entiende que esas dos herramientas cubren un solo pilar de los tres que hacen falta. Prometheus es un sistema de métricas —series temporales numéricas, baratas de almacenar y fáciles de agregar—, ideal para "cuántas peticiones por segundo" o "qué latencia en el percentil 95"; y Grafana es la capa de visualización y alertado que se sienta encima. El problema es que una métrica te dice que algo va mal, pero no por qué. Para el porqué hacen falta los otros dos pilares: los logs, que son el registro textual y contextual de qué ocurrió en cada evento, y las trazas, que reconstruyen el recorrido de una petición individual a través de todos los servicios que la atienden. Un equipo maduro no elige entre pilares; los tiene los tres y los tiene conectados entre sí.

La diferencia práctica se ve en ese escenario. Con solo métricas, el equipo sabe que los falsos positivos se disparan y que el dato llega "fuera de ventana", y poco más; con las tres capas correlacionadas, en cambio, la traza muestra que el reconocimiento óptico y el modelo responden con su latencia normal —así que no son ellos—, y los logs de ingesta revelan marcas de tiempo desplazadas justo la cantidad de una diferencia horaria. La causa no está en el modelo ni en la infraestructura, sino en el dato: las actas traen la hora de cierre en horario local y el sistema las ingiere como tiempo universal.

Ese desfase corre la ventana esperada de llegada y altera la distribución que el modelo toma de entrada. Ir de la alerta a la línea de log culpable en tres pasos, en vez de reentrenar a ciegas un modelo sano, es exactamente lo que compra la correlación. En términos de herramientas abiertas, ese salto se construye instrumentando con OpenTelemetry —el estándar que desacopla la instrumentación del backend— y navegando métricas, logs y trazas desde un mismo Grafana; el monitoreo de aplicación no es entonces un producto aparte, sino la lectura conjunta de los tres pilares.

Fiabilidad es aritmética, no heroísmo

Medir por medir no sirve de nada si no se decide qué nivel de servicio importa y se le pone un número. Un indicador de nivel de servicio captura la experiencia real —no "la CPU al ochenta por ciento", sino "el noventa y nueve por ciento de las actas se procesan en menos de cinco minutos"—; el objetivo de nivel de servicio es el umbral que uno se compromete a cumplir; y el presupuesto de error es su complemento, el margen de fallo que queda antes de incumplir. Esa aritmética, que proviene del manual de ingeniería de fiabilidad de Google (Beyer et al., 2016), cambia por completo la conversación de guardia.

Se deja de discutir si hubo incidentes, que siempre los hay, y se pasa a discutir si queda presupuesto, lo que permite priorizar con criterio en lugar de apagar fuegos por reflejo. En una plataforma de datos y modelos, esos objetivos se reparten por capa —cobertura y frescura en los datos, latencia de inferencia y falsos positivos en el modelo, las señales de oro en la infraestructura, coste e intervención humana en los agentes— y se alertan con tasa de quemado a varias ventanas, de modo que una caída brusca salta en minutos y una degradación lenta no pasa inadvertida.

El fallo más peligroso de todos, sin embargo, es el que no dispara ninguna de esas alertas de infraestructura, porque no vive en la infraestructura. Un modelo puede seguir respondiendo con su latencia de siempre, con todos los paneles en verde, mientras sus predicciones dejan de ser buenas porque el mundo que observa ha cambiado. A ese fenómeno se le llama deriva, y conviene separar la deriva de datos —cambia la distribución de las entradas, por ejemplo un escáner distinto que altera la calidad de imagen— de la deriva de concepto —cambia la relación entre lo que entra y lo que se considera anómalo—. Ninguna de las dos aparece en un gráfico de consumo de recursos, y por eso la observabilidad de datos y de modelos es una capa propia, con sus propias herramientas: validación de calidad en la frontera de ingesta, medición de deriva que se publica como una métrica más para alertar igual que la latencia, y un registro de modelos que hace cada predicción rastreable a la versión que la produjo. Sin esa capa, el sistema puede estar roto y verse impecable.

Observar la decisión, no solo el cálculo

La frontera más nueva de la observabilidad es la capa donde el sistema deja de calcular y empieza a decidir. Un agente de inteligencia artificial no es una función que entra y sale una vez: es un bucle que razona, llama a herramientas, evalúa el resultado y decide si continuar o parar. Ese diseño introduce una pieza que la observabilidad tradicional no contempla, el criterio de parada, y resulta que ese criterio es, además de un control operativo imprescindible, la señal más informativa de toda la capa. Un agente que empieza a parar por haber agotado su tope de iteraciones, en lugar de por haber convergido, está avisando de que ha dejado de resolver y está tocando su red de seguridad cada vez más a menudo; observar por qué para —convergencia, confianza suficiente, presupuesto de coste agotado o tope duro— dice más sobre la salud del sistema que cualquier métrica de latencia. Junto a ello, vigilar el coste por ejecución, el número de iteraciones y la tasa de intervención humana convierte una caja negra que decide en un componente tan observable como el resto.

Sostener todo esto sin multiplicar el esfuerzo por el número de nubes exige una última disciplina, la de tratar la infraestructura como código y no como artesanía. Si la telemetría se instrumenta con un estándar abierto en lugar de con el agente propietario de cada proveedor, la misma instrumentación funciona en Amazon, en Azure y en Google, y solo cambia el destino de los datos; y si los entornos se declaran en código versionado y se reconcilian con un modelo GitOps, levantar una réplica en otra nube o reconstruir tras un incidente es aplicar un plan, no seguir una lista de pasos que nadie recuerda del todo.

El beneficio para la observabilidad es directo y suele pasarse por alto: el análisis de causa raíz es idéntico se ejecute donde se ejecute la carga, los objetivos de servicio se definen una vez y se despliegan en todas partes, y la portabilidad deja de ser una promesa de folleto para ser una propiedad real del sistema. La independencia respecto a la consola de cualquier proveedor no es una preferencia estética: es lo que garantiza que, cuando algo falle a las tres de la madrugada, el equipo pueda averiguar por qué sin depender de nadie.

La pregunta mide criterio, no herramientas

Detrás de "¿qué usáis además de Prometheus y Grafana?" no hay una petición de nombres de productos, sino una prueba de criterio: si quien responde entiende que la observabilidad no es acumular paneles sino poder preguntarle al sistema por qué sin haber previsto la pregunta. La respuesta completa no es una lista de herramientas, es un modo de pensar —cuatro capas, tres pilares correlacionados, objetivos de servicio con su presupuesto de error, y portabilidad por diseño— que se sostiene igual en un sistema electoral bajo presión que en cualquier plataforma de datos y modelos en producción. Y quizá la mejor señal de madurez sea la humildad de la pregunta que queda abierta para la siguiente guardia: no "¿cómo evito que vuelva a fallar?", que es imposible, sino "cuando falle de una forma que no he previsto, ¿podré averiguar por qué?".