Hace unos años, un equipo de operaciones de una empresa mediana recibió una alerta a las tres de la madrugada. El servicio web había caído. Cuando el técnico de guardia se conectó, encontró que el problema real no era el servicio web: era una base de datos que había saturado conexiones por culpa de una consulta mal optimizada que había pasado desapercibida durante días. La alerta llegó tarde, cuando el daño ya estaba hecho.
Hoy, Dynatrace promete detectar ese tipo de problemas antes de que se conviertan en incidentes, correlacionar datos de múltiples fuentes y señalar la causa raíz sin que nadie tenga que buscarla manualmente. Su motor de IA, conocido como Davis AI, y el paraguas que lo engloba —Dynatrace Intelligence— forman la columna vertebral analítica de la plataforma. Y en buena medida, esa promesa se cumple.
Pero para que funcione bien en producción hay cosas que entender, ajustar y mantener. Este artículo explora qué hace realmente Dynatrace Intelligence, cómo funciona su enfoque de IA causal, qué hacen sus agentes y qué necesita el equipo para sacarle partido de verdad.
Qué es Dynatrace Intelligence y qué es Davis AI
Dynatrace Intelligence es el nombre que agrupa las capacidades de análisis automatizado, detección de anomalías y análisis de causa raíz de la plataforma. En el centro de todo está Davis AI, el motor propio de inteligencia artificial que lleva años evolucionando y que en 2025-2026 ha incorporado también capacidades agénticas.
Lo que distingue a Davis de enfoques basados en umbrales estáticos o en correlación estadística es su apuesta por IA determinista basada en causalidad. En lugar de buscar patrones estadísticos y asumir correlación, Davis recorre el grafo de topología en tiempo real de la infraestructura —llamado Smartscape— para establecer relaciones causales entre componentes. Smartscape mapea automáticamente todas las dependencias: qué servicios llaman a qué bases de datos, qué procesos corren en qué hosts, cómo fluye el tráfico entre microservicios.
Cuando algo falla, Davis no pregunta «¿qué cosas cambiaron al mismo tiempo?», sino «¿qué entidad de este grafo causó el problema y cómo se propagó hacia arriba?». La diferencia práctica es importante: la correlación puede llevarte por falsos caminos cuando dos eventos coinciden en el tiempo sin relación causal. La causalidad, respaldada por el mapa de topología, es mucho más difícil de confundir. La documentación oficial describe este proceso como fault-tree analysis, la misma metodología que usan la NASA y la FAA para análisis de fallos en sistemas complejos.
Sobre esta base determinista, Dynatrace Intelligence incorpora también modelos predictivos y, más recientemente, capacidades de IA generativa a través de Davis CoPilot, que permite hacer preguntas en lenguaje natural sobre el estado del sistema y obtener respuestas contextualizadas con todo el contexto de topología disponible.
Qué hace realmente el OneAgent
Los agentes de Dynatrace —agrupados bajo la marca OneAgent— son piezas de software que se instalan en servidores, contenedores o máquinas virtuales para instrumentar aplicaciones automáticamente y enviar datos de rendimiento a la plataforma central.
A diferencia de agentes más tradicionales que exportan métricas de sistema, OneAgent inyecta código en tiempo de ejecución para capturar trazas de transacciones completas sin que el desarrollador tenga que modificar nada. Detecta las tecnologías en uso —Java, Node.js, .NET, bases de datos, colas de mensajes— y aplica la instrumentación correspondiente de forma automática. En entornos con microservicios, donde una petición puede atravesar diez servicios antes de completarse, tener visibilidad de extremo a extremo sin tocar código es una ventaja real y apreciable.
El impacto de OneAgent en el sistema está diseñado para ser bajo: típicamente unos pocos puntos porcentuales de CPU en condiciones normales. Pero «bajo» no es «cero». En VMs con recursos muy ajustados o en sistemas con márgenes de rendimiento estrechos, la sobrecarga puede ser perceptible. Es algo a evaluar caso por caso, no un problema generalizado.
Un apunte práctico sobre la estrategia de despliegue: instalar OneAgent en todos los hosts por defecto no siempre es lo mejor. Los agentes instalados en hosts que no ejecutan cargas de aplicación relevantes —nodos de salto, utilidades compartidas— generan datos que consumen licencia (las DDU, Davis Data Units) sin aportar valor real. La cobertura debe ser intencionada.
Detección de anomalías: cómo funciona y qué necesita
La detección automática de anomalías es uno de los pilares de Dynatrace Intelligence. El sistema aprende el comportamiento de cada métrica y alerta cuando algo se desvía de lo esperado. Hay tres modalidades principales:
- Auto-adaptive threshold: umbral dinámico calculado mediante machine learning sobre una ventana móvil de siete días. Se adapta continuamente al comportamiento reciente de la métrica.
- Seasonal baseline: para métricas con patrones predecibles —picos diarios, variaciones semanales—, Davis crea una banda de confianza que tiene en cuenta la estacionalidad.
- Static threshold: umbral fijo, útil cuando el equipo tiene criterios claros y no quiere variabilidad en la detección.
En entornos estables con patrones de tráfico predecibles, esto funciona muy bien. Si todos los lunes a las nueve hay un pico de peticiones y un lunes no llega, el sistema lo detecta. Si el tiempo de respuesta de una API escala de 200ms a 900ms en diez minutos, la anomalía es clara.
El reto aparece en entornos con alta variabilidad: servicios que se despliegan varias veces al día, infraestructuras que escalan de forma agresiva, tráfico con picos irregulares. En esos casos, los parámetros de sensibilidad y los periodos de aprendizaje requieren ajuste. La plataforma ofrece todas las herramientas para hacerlo, pero hay que dedicarle tiempo, especialmente en las primeras semanas de despliegue.
Quien instala los agentes, activa las alertas por defecto y espera que todo funcione desde el primer día va a recibir más ruido del deseable hasta que el sistema esté bien calibrado. No es un defecto de Dynatrace; es la naturaleza de cualquier sistema de detección basado en aprendizaje adaptativo.
Correlación de eventos y análisis de causa raíz: donde brilla de verdad
Si hay un área donde Dynatrace aporta valor diferencial frente a herramientas más simples, es en la correlación de eventos y el análisis de causa raíz. Cuando ocurre un incidente, Davis recorre el grafo Smartscape, identifica qué componentes están afectados, establece la cadena causal y agrupa todos los eventos relacionados en un único «problema» con jerarquía de causas. En lugar de recibir diez alertas inconexas sobre síntomas distintos, el equipo recibe una única notificación que explica la relación entre esas señales y señala el origen probable.
La plataforma correlaciona también eventos de cambio: despliegues, modificaciones de configuración, actualizaciones de infraestructura. Cuando un incidente ocurre, Davis puede identificar si un despliegue reciente está en la cadena causal, lo que reduce significativamente el tiempo de diagnóstico.
Hay límites naturales a tener en cuenta. Si el sistema no tiene visibilidad sobre un cambio —un script ejecutado manualmente, una modificación directa en base de datos, un cambio de red no registrado— no puede correlacionarlo. Y si el cambio problemático ocurrió hace varios días pero el síntoma solo se manifiesta ahora, la correlación temporal puede quedar fuera de la ventana de análisis (los problemas abiertos durante más de 90 minutos dejan de incorporar nuevos eventos para evitar mezclar incidentes no relacionados). Son comportamientos documentados y razonables; simplemente hay que conocerlos.
Autonomía real: dónde estamos hoy y hacia dónde va
La palabra «autónomo» aparece con frecuencia en la documentación de Dynatrace. Vale la pena entender qué significa en la práctica en 2026.
La autonomía actual es principalmente operativa: Davis ajusta dinámicamente el comportamiento de los agentes según la carga del sistema, reduce el nivel de detalle de las trazas cuando detecta presión sobre el host, y aumenta la frecuencia de muestreo en transacciones que están fallando de forma recurrente. Esas decisiones tácticas ocurren dentro de un marco definido por las políticas configuradas en la plataforma.
Lo que está llegando ahora —en Preview en el momento de escribir este artículo— son los agentic workflows: flujos de trabajo donde agentes de IA pueden no solo detectar un problema y analizar su causa raíz, sino también proponer acciones de remediación y ejecutarlas bajo guardrails de política definidos por el equipo. La integración con AWS DevOps Agent anunciada en 2025 es un ejemplo concreto: Dynatrace detecta el problema y cuantifica su impacto, y un agente externo investiga configuraciones y logs para confirmar la causa raíz y proponer el fix. Es un horizonte real y bien orientado.
Lo que Davis no hace, independientemente del nivel de madurez de la plataforma, es decidir estratégicamente qué monitorizar ni interpretar qué es importante para el negocio. Puede detectar que el tiempo de respuesta de una API ha aumentado un veinte por ciento, pero no sabe si eso importa o no: puede ser un servicio interno de baja prioridad o el endpoint crítico del que depende toda la facturación. Esa distinción la tiene que hacer el equipo. Y está bien que sea así.
Lo que necesita el equipo para sacarle partido
Uno de los errores más habituales al adoptar Dynatrace es asumir que la plataforma va a resolver problemas de observabilidad que en realidad son problemas de arquitectura o de calidad de datos. Si una aplicación no tiene trazabilidad interna, si los logs no tienen contexto estructurado, si los servicios no exponen métricas útiles, Dynatrace puede recoger datos, pero esos datos no van a contar una historia coherente. La herramienta amplifica lo que ya existe; no lo crea desde cero.
También es habitual no invertir suficiente tiempo en la fase de calibración inicial. Activar las alertas por defecto y esperar resultados perfectos desde el día uno es una expectativa poco realista. La detección adaptativa necesita aprender, y ese aprendizaje mejora con la intervención del equipo durante las primeras semanas.
Por último, es buena práctica validar las sugerencias de causa raíz antes de actuar sobre ellas. Davis fundamenta sus análisis en causalidad determinista, no en correlación estadística, y eso le da una precisión notable. Pero ningún sistema tiene visibilidad perfecta sobre todos los cambios que ocurren en un entorno real. Los criterios de validación antes de ejecutar una remediación siguen siendo responsabilidad del equipo.
Cuándo tiene más sentido
Dynatrace tiene sentido en organizaciones con infraestructuras complejas donde la correlación manual de eventos es inviable. En entornos con decenas de microservicios, múltiples equipos desplegando de forma independiente y alta frecuencia de cambios, la capacidad de tener una vista unificada con topología en tiempo real y detección automática de anomalías justifica la inversión.
En entornos más pequeños o con arquitecturas simples, herramientas de monitorización más ligeras combinadas con buen conocimiento del sistema pueden ser suficientes. No se trata de que Dynatrace sea mejor o peor en abstracto, sino de si resuelve un problema real que el equipo tiene hoy.
La pregunta útil es concreta: ¿el equipo pierde horas buscando la causa raíz de incidentes? ¿Tiene demasiadas alertas y no sabe cuáles importan? ¿La complejidad de la infraestructura supera lo que puede gestionar manualmente? Si la respuesta es sí, vale la pena explorarlo en serio.
Una herramienta al servicio del equipo
Davis AI y Dynatrace Intelligence son un conjunto de técnicas bien fundamentadas —IA causal determinista, grafos de topología en tiempo real, instrumentación automática, detección adaptativa de anomalías— aplicadas a uno de los problemas más difíciles de la operación de sistemas: entender qué está pasando en infraestructuras complejas cuando algo falla.
Lo que hacen bien es reducir el tiempo que se tarda en conectar síntomas dispersos y llegar a la causa raíz. Eso, en producción, cuando cada minuto de degradación tiene un coste medible, puede marcar la diferencia entre un incidente menor y una caída prolongada.
Pero como cualquier herramienta sofisticada, vive al servicio del equipo que la opera. Requiere calibración, mantenimiento y criterio técnico para interpretar lo que dice. Con eso, da mucho de sí.
Para seguir aprendiendo
Documentación oficial de Dynatrace:
- Dynatrace Intelligence y Davis AI — arquitectura del motor, conceptos de detección y análisis de causa raíz.
- Anomaly Detection — configuración de los tres modos de detección y mejores prácticas.
- Root Cause Analysis — cómo Davis agrupa eventos y construye el árbol causal.
- Blog técnico de Dynatrace — artículos actualizados sobre nuevas capacidades, integraciones y casos de uso reales.
Libros de referencia:
- Observability Engineering, de Charity Majors, Liz Fong-Jones y George Miranda (O’Reilly): fundamentos de la observabilidad moderna y cómo construir sistemas que se puedan entender en producción.
- Site Reliability Engineering, editado por Betsy Beyer, Chris Jones, Jennifer Petoff y Niall Richard Murphy (O’Reilly): principios de monitorización, gestión de incidentes y respuesta que cualquier herramienta de observabilidad debe servir.