En la web de documentación de BMC hay un documento de planificación, fechado en agosto de 2022, que cuenta una escena muy concreta. Un usuario ficticio, Jim, trabaja en gestión de eventos y lleva dos horas sin recibir ni un solo evento de un PATROL Agent. No sabe si es porque no pasa nada o porque el agente ha dejado de recolectar datos. La pregunta que el documento quiere responder es literalmente esa: ¿cómo puedo estar seguro de que un agente está recolectando y no está caído? La solución que describe, una política de alarma de serie que avisa cuando un agente deja de enviar datos, aparece en las notas de la versión 22.3.01.
Esa pregunta no es teórica. En un proyecto con más de 1000 servidores monitorizados, cada día había un montón de Patrol Agents caídos. Lo más incómodo eran los que seguían con el servicio levantado pero sin reportar nada. Lo que se hizo fue un intento de resolverlo con el heartbeat (“latido”: una señal que el agente envía cada cierto tiempo para decir “sigo vivo”; si deja de llegar, algo va mal, como cuando se pierde el pulso) y el reinicio automático del agente, y no se llegó a algo lo bastante bueno. Desde entonces, cada vez que alguien habla de «resolución autónoma de incidentes», la pregunta vuelve: si cuesta tanto saber que el vigilante está vivo, ¿cuánto de lo que viene después se puede delegar de verdad?
Dos autorremediaciones que conviene no mezclar (aunque vayan de la mano)
Autorremediación (en inglés, self-healing, «curarse solo») es que un sistema reaccione ante un fallo sin esperar a una persona: reiniciar un servicio caído, liberar espacio en un disco, hacer rollback de una versión mala. Aquí hay dos cosas distintas.
La primera es la autorremediación de los incidentes: los problemas de las aplicaciones y la infraestructura que monitorizamos. La segunda es la de la propia herramienta de monitorización: que un agente o un clúster se vigile y se recupere solo, o al menos nos avise cuando no está bien. La segunda es la que más se olvida. Es el detector de humos al que se le ha gastado la pila: da una sensación de seguridad que no se corresponde con nada, y solo te enteras cuando hace falta.
Lo que prometen los fabricantes y lo que dice su documentación
Los fabricantes hablan de operaciones autónomas «con guardarraíles». Un guardarraíl es la barrera de la carretera: no conduce por ti, pero impide que te salgas. En automatización son los límites que acotan lo que un sistema puede hacer solo: qué acciones, sobre qué servidores, cuántas veces.
Para leer bien la oferta hay que distinguir dos cosas. Un flujo determinista es una secuencia de pasos escrita de antemano que, con la misma entrada, hace siempre lo mismo: es un tren sobre raíles. Un agente de IA basado en un modelo de lenguaje, en cambio, razona sobre la marcha y puede responder distinto ante la misma situación: es un conductor que decide el camino.
Los Workflows de Dynatrace son flujos de ese primer tipo. Se disparan con un problema detectado, con la posibilidad de filtrar por gravedad, y pueden lanzar acciones como un playbook de Ansible (un playbook es el guion de tareas que Ansible ejecuta sobre los servidores). Según una de sus notas de versión, los workflows nuevos que se disparan con un problema solo arrancan cuando Davis AI ha terminado el análisis inicial de causa raíz. Es decir, la propia herramienta espera a saber qué ha pasado antes de actuar. Los «workflows agénticos», que incorporan IA generativa, aparecían en su documentación de enero de 2026 como Preview (conviene comprobar su estado actual) y la propia página recomienda añadir un paso de aprobación humana cuando las acciones tienen consecuencias. Ese paso envía un correo y espera hasta 24 horas; si se rechaza o caduca, el workflow falla. Dynatrace describe además un camino de tres escalones: primero recomendaciones, luego automatización supervisada y, al final, operaciones autónomas con guardarraíles.
El resto del mercado va por el mismo sitio. Datadog anunció en junio de 2026 remediación autónoma con guardarraíles predefinidos. New Relic documenta que su agente puede sugerir intervenciones, como un rollback o ajustar recursos, que un ingeniero debe revisar antes de aplicarlas. PagerDuty habla de ejecutar automatizaciones ya aprobadas. Y Zabbix, la opción abierta de toda la vida, lleva años permitiendo comandos remotos como respuesta a un problema: ya su documentación de la versión 1.8 hablaba de ejecutar scripts arbitrarios. Hoy esos comandos vienen deshabilitados por defecto en agentes y proxies, y desde Zabbix 7.0 también los scripts globales en el servidor en instalaciones nuevas. El fabricante te obliga a decidir conscientemente que quieres hacerlo.
Las cifras de fondo recomiendan prudencia. Gartner prevé que más del 40% de los proyectos de IA agéntica se cancelarán a finales de 2027 por costes, valor poco claro y controles de riesgo insuficientes, y estima que solo unos 130 proveedores, de miles que lo afirman, ofrecen autonomía real.
La causa raíz es el hueso duro
La experiencia en proyectos reales apunta a esto: el discurso bonito de «detectamos la causa y lo arreglamos solo» choca con que llegar a la causa raíz casi nunca es sencillo. Para que una herramienta la encuentre, la monitorización tiene que estar bien configurada, la aplicación instrumentada y los datos adecuados disponibles. Es lo más difícil de implementar y lo que casi siempre falla antes de hablar de remediar nada.
Un experimento de ClickHouse lo ilustra: probaron varios modelos de lenguaje sobre datos reales de observabilidad y concluyeron que el análisis autónomo de causa raíz aún no está listo. Uno de los modelos llegó a inventarse una causa sin evidencia y a intentar demostrarla. Eso sí, todos redactaron bien los informes posteriores.
Pero el planteamiento de los equipos que llevan años automatizando es más modesto. En su blog de ingeniería, Cloudflare explica que su sistema de remediación automática está pensado para reconocer un modo de fallo inesperado y mitigarlo de inmediato, dejando la causa raíz para un análisis posterior. No se remedia porque se conozca la causa, sino porque se conoce esa clase de fallo y su arreglo.
Dónde sí tiene sentido: lo conocido y repetido
Un ejemplo: la alerta «el disco supera el 90%», que siempre se resuelve igual (rotar logs y avisar). Es candidata perfecta. Mike Julian, en Practical Monitoring (O’Reilly, 2017), tiene una sección titulada «Attempt Automated Self-Healing First» (intenta primero la autorremediación) y advierte de que, si los pasos del runbook son copiar y pegar comandos, estás abusando de los runbooks: lo que toca es automatizar el arreglo o resolver la causa y borrar la alerta. (Un runbook es el manual de pasos a seguir ante una alerta concreta.)
De ahí sale una regla práctica: una alerta que salta cada semana con la misma causa no se resuelve: se arregla. La autorremediación es un buen puente, pero nunca debería ser el destino.
Los cuatro frenos
La automatización en la que se puede confiar suele llevar incorporados estos frenos.
Un límite de intentos. Si la acción solo puede ejecutarse, por ejemplo, N veces al día, y después escala a una persona, se evita el bucle: reiniciar, fallar, reiniciar. Un autor que supervisaba sus agentes con systemd cuenta que, con Restart=always, un fallo persistente generó reinicios sin fin y un log que crecía 10 MB por hora (systemd es el gestor de servicios de Linux, y esa opción le dice que reinicie el servicio siempre que se pare).
Un aviso de repetición. Aunque la automatización funcione y no haya síntoma aparente, que se repita es información. Es el polvo debajo de la alfombra: el problema sigue ahí y solo lo hemos hecho invisible. Es como tomar un analgésico cada día sin preguntarse de dónde viene el dolor.
Conservar la evidencia antes de actuar. En un blog técnico tenemos el siguiente ejemplo: su remediación automática «limpió la escena del crimen»: el sistema se recuperaba antes de que nadie observara el fallo, los logs rotaban, los pods se reiniciaban y las trazas desaparecían. Su propuesta es capturar un paquete forense antes de remediar. Es exactamente el mismo principio que con una aplicación Java en Tomcat: antes de reiniciar tras un error de memoria, conviene sacar un heap dump (una fotografía de la memoria del proceso en ese instante) y varios thread dumps (el estado de cada hilo de ejecución). La JVM puede hacerlo sola con la opción -XX:+HeapDumpOnOutOfMemoryError, que genera el volcado cuando salta el error de memoria.
Verificar y fallar con ruido. Después de actuar, hay que comprobar que ha funcionado; y si algo falla, que se oiga. Un caso con Ansible: en un cliente se usaba para instalar el agente Patrol, y en otro para actualizarlo. A veces fallaba, pero cuando fallaba avisaba. Eso es lo que lo hace aceptable: ahorra un trabajo manual rutinario y el fallo no pasa desapercibido. Y, si es posible, un interruptor para desactivarlo: Adobe cuenta en su blog que necesitaron poder suspender la autorremediación por servidor mientras un SRE trabajaba en él, para que no reiniciara servicios a mitad de una intervención.
Cuando el remedio es la enfermedad
La mejor prueba de por qué estos frenos importan es el apagón de AWS de octubre de 2025. Según el propio postmortem de AWS, el origen fue una condición de carrera en la automatización del DNS de DynamoDB. Una condición de carrera es cuando dos procesos compiten por lo mismo y el resultado depende de cuál llega antes. Dos procesos automáticos que actualizaban el DNS se pisaron: una limpieza borró el plan vigente y el nombre del servicio se quedó con un registro vacío, sin ninguna dirección IP. La propia automatización no consiguió reparar ese estado y hizo falta intervención manual de los operadores. Entre las medidas posteriores, AWS desactivó esa automatización en todo el mundo hasta corregir el fallo y añadió salvaguardas, como un control de velocidad en los balanceadores de red.
¿Quién vigila al vigilante?
El nombre clásico de la solución es el dead man’s switch («interruptor del hombre muerto»). En un tren, es el pedal que el maquinista debe mantener pisado: si lo suelta, el tren frena. En monitorización, la lógica se invierte: una señal que se emite constantemente a un servicio externo y, si deja de llegar, algo avisa por otro canal. En Prometheus se llama la alerta Watchdog, una que siempre está disparada, y Irin Observability insiste en que la ruta que avisa de que la monitorización está caída no puede depender de la propia monitorización. A ese latido se le llama heartbeat.
En un proyecto con Patrol se creó justo eso: un heartbeat para saber que el agente estaba vivo, y el aviso lo daba la propia plataforma TrueSight o Helix. No sé cómo está hoy el asunto en cada despliegue, pero BMC ha incorporado una política de serie para avisar si un agente deja de enviar datos, y su documentación actual describe un monitor de «salud del agente» que compara la tasa de recolección de las últimas 24 horas con la de la última hora.
En Zabbix, un ticket de su gestor de incidencias (ZBX-28045) describió un caso preocupante con el Agent 2: tras una respuesta fallida, podía dejar de ejecutar los checks activos, mientras el latido seguía funcionando y el host aparecía disponible. Es el «levantado pero no reporta» con otro nombre. Está corregido en las versiones 7.0.30, 7.4.14 y 8.0.0, pero el patrón es el que importa. Un clásico de los foros para estos casos es combinar un ítem de latido con la función nodata.
En Dynatrace, la documentación de eventos de monitorización no disponible explica que, si la mayoría de los OneAgent pierden la conexión con el servidor, se suprimen los problemas individuales de host no disponible y se avisa de la interrupción global. Alertar de que solo ha caído un OneAgent es más matizado: en un hilo de la comunidad, varios expertos discuten que una parada ordenada no genera problema para evitar falsas alarmas, y que hay que activar la monitorización de disponibilidad de procesos. Por otro lado, el ActiveGate tiene un watchdog dedicado que lo reinicia si se cuelga, según su documentación oficial.
En Dynatrace Managed hay que vigilar también el propio clúster: nodos, llenado de disco, estado del CMC (la consola de gestión del clúster). Existe un entorno de autosupervisión local, documentado oficialmente, donde se pueden configurar alertas. Además, la documentación actual indica que las notificaciones por correo de eventos del clúster (disco insuficiente, hardware insuficiente, almacenamiento de métricas insuficiente) se configuran en la consola de gestión del clúster o mediante su API. Un hilo antiguo de la comunidad hablaba de muchas menos opciones, así que es un asunto que ha cambiado; aun así, conviene comprobar en cada entorno qué eventos llegan realmente y a quién. Algunos clientes han acabado recurriendo a un monitor secundario para avisar de cosas tan simples y tan críticas como un filesystem lleno o un nodo caído: una redundancia que da risa hasta que te salva.
Poca evidencia pública: lo decimos claro
Llama la atención algo que conviene decir claro: casi nadie publica sus automatismos en producción. Lo que se encuentra en la red son sobre todo promesas de los proveedores y casos publicados por integradores. Es el caso, por ejemplo, de un fabricante que cerró el bucle de Dynatrace con Event-Driven Ansible (el módulo de Ansible que reacciona a eventos) para clases de incidente concretas y sin intervención humana, contado por el integrador que hizo el proyecto.
Por eso, un técnico junior que busque ejemplos reales no encontrará muchos. O tiene compañeros con experiencia aplicada a su caso concreto, o la vía es probar con cabeza, empezando por casos pequeños y conocidos, y supervisando cada paso.
Resumiendo
La conclusión, con la prudencia que corresponde a una opinión personal: hoy se delega bien lo que cubre una clase de fallo conocida, conserva la evidencia, verifica el resultado, falla con ruido y tiene freno. Lo demás sigue necesitando a una persona, y no es una contradicción con el discurso de los agentes de IA: es lo que los propios fabricantes plantean con sus pasos de aprobación. La paradoja, si la hay, está entre el titular de marketing y la práctica.
Y la otra mitad, la que se olvida: antes de preguntarnos qué incidentes puede resolver una herramienta sola, conviene preguntarse quién nos avisa cuando la herramienta no está bien.
Nota: observasistemas.com es un blog personal, sin vínculos con ninguna herramienta ni ingresos por publicidad o patrocinio. No se han utilizado todas las herramientas del mercado ni soluciones a medida, así que este artículo no clasifica ninguna como mejor o peor: se limita a contar experiencias personales, de compañeros y de la comunidad.
Fuentes
- BMC: documento de planificación «Report no collection data»
- Dynatrace: conceptos de Workflows
- AWS: resumen del evento de DynamoDB en us-east-1, octubre de 2025
- Platform Notes: automatizamos el incidente y perdimos el aprendizaje
- Dynatrace Managed: autosupervisión local
- Cloudflare: mejorando la resiliencia de la plataforma mediante automatización
