Azure Copilot Observability Agent: cambiando la forma en que investigamos

Tal vez esta historia te suene conocida: un componente empieza a fallar, hay poca información y mucha presión. Hay que actuar rápido, cada minuto cuenta, sientes el peso en los hombros y terminas con dolor de espalda. Cada incidente requiere un análisis detallado, preciso y de calidad. Y ojalá que para ayer.

¿Cómo mitigo esa presión? Rodeándome de herramientas que me permitan ubicarme rápidamente. En mi caso, Azure Monitor, con sus métricas para ir descartando sospechosos y acorralar al culpable, y después las consultas KQL para profundizar en la investigación.

Se me reportó un problema de rendimiento que implicó revisar métricas, formular hipótesis y ejecutar varias consultas KQL. Después de un rato tenía un informe que, modestia aparte, había quedado bellísimo. Con la evidencia pude entender mejor el problema y tomar acción. No podía sentirme más orgullosa.

Lo curioso vino después. Al tiempo, me encontré con una opción nueva en Azure Monitor: Observability Agent.

La curiosidad ganó. ¿Podría ayudarme a investigar un problema como el que había analizado?

Le describí el síntoma en lenguaje natural, le indiqué la ventana de tiempo y los servicios involucrados. ¿Y qué crees? En cuestión de minutos generó la mayoría de las consultas que yo había escrito, y algunas más. Además, preparó un informe bien redactado y, como si no me hubiera impresionado lo suficiente, agregó cuatro hermosos gráficos que ayudaban a visualizar el problema.

¿Significaba que podía olvidarme de investigar? No exactamente. Pero sí que podía dedicar menos tiempo a construir consultas desde cero y más tiempo a interpretar las evidencias.

En este artículo te cuento un poquito sobre Azure Copilot Observability Agent, y qué debes tener en cuenta para aprovecharlo. Aviso: esto es solo un vistazo desde 100.000 pies de altura. El agente tiene más capacidades que las que exploré en esta experiencia.

El Azure Copilot Observability Agent es un asistente con inteligencia artificial integrado en Azure Monitor. No reemplaza lo que ya conoces: métricas, logs, Application Insights, alertas y dashboards. Su propósito es ayudarte a trabajar con las señales de observabilidad mediante lenguaje natural, investigaciones guiadas y correlación de información.

En lugar de saltar de una pantalla a otra para armar el rompecabezas a mano, puedes pedirle que explore los datos, genere consultas y te ayude a entender qué está pasando.

Y un detalle importante: no es una herramienta estática. Sus capacidades están evolucionando y algunas funciones todavía se encuentran en versión preliminar.

Chatear con tus datos. Puedes explorar métricas, logs y otras señales de telemetría utilizando lenguaje natural. También puedes pedirle que genere consultas para profundizar en un comportamiento.

Investigar un problema. Las investigaciones profundas permiten analizar señales de distintos componentes, buscar correlaciones y generar un informe con hallazgos y posibles siguientes pasos.

Explorar operaciones autónomas. El agente puede correlacionar alertas en segundo plano, crear issues en Azure Monitor e iniciar investigaciones profundas sobre ellos. Requieren crear un recurso de Observability Agent y solo están disponibles en ciertas regiones. En mi práctica, las decisiones de mitigación y los cambios en el entorno los sigo tomando yo. Consulta la documentación oficial sobre operaciones autónomas para conocer las capacidades, los requisitos y las regiones admitidas.

Necesitas acceso a Azure Copilot. Por eso, dentro de una misma organización, es posible que algunos usuarios puedan utilizarlo y otros no.

En mis pruebas pude interactuar con el agente tanto en español como en inglés. Sin embargo, la documentación indica que el inglés es el idioma admitido y que otros idiomas tienen soporte limitado. En mi experiencia, los informes se generaron en inglés.

Como siempre, conviene distinguir entre lo que funcionó en una prueba y lo que está oficialmente soportado.

El secreto de cualquier agente de IA es darle buen contexto. Cuanto mejor sea tu especificación, más posibilidades tendrás de obtener resultados útiles.

No es lo mismo decirle «averigua por qué falla mi aplicación» que dirigir la investigación hacia donde realmente tiene sentido.

No hay recetas que funcionen para todas las organizaciones, pero te comparto un tip:

Un buen dashboard no es un grupo de gráficos bonitos. Un buen dashboard te cuenta una historia.

Debe ayudarte a entender cómo se comporta tu aplicación, qué tan disponible está y dónde podrían estar los problemas de rendimiento.

En una aplicación con varios servicios, por ejemplo, debería ayudarte a responder preguntas como estas:

Un dashboard no necesariamente te dará la causa raíz, pero sí puede ayudarte a decidir por dónde empezar.

Es probable que, por historia, tengas un componente o servicio que consideras el patito feo: ese que siempre da problemas.

A mí me ha pasado. Tengo mi favorito, el que siempre tengo entre ojos. Pero eso es una corazonada. A veces acierto, pero muchas veces el sospechoso no era el culpable y mi primer vistazo estaba equivocado.

Los datos nos ayudan a separar las sospechas de las evidencias. Con buenos dashboards puedo formarme una primera idea del problema y, como se dice en mi país, «así sabemos por dónde anda la procesión».

Esa primera idea es útil, pero no debería convertirse en una conclusión antes de tiempo.

Con los datos de tus dashboards y las señales disponibles en Azure Monitor, ya tienes una base para orientar la investigación.

Lo interesante es que, al revisar los resultados, puedes encontrar relaciones que no habías considerado inicialmente. El agente puede ayudarte a explorar esas posibilidades, pero sus conclusiones deben contrastarse con las evidencias.

Como con cualquier herramienta de IA, te recomiendo:

¿Qué está ocurriendo? ¿Errores intermitentes, latencia elevada, timeouts o una degradación general del rendimiento?

Menciona las validaciones realizadas y los problemas que ya descartaste. Así ayudas a acotar la investigación.

3. Señala las hipótesis que quieres evaluar.

Puedes dirigirlo hacia determinados componentes y pedirle que busque correlaciones, sin asumir que el sospechoso es necesariamente el culpable.

4. Acota la ventana de tiempo e indica la zona horaria.

Este detalle es importante. En una investigación puedes tener reportes expresados en hora local y telemetría registrada en UTC. Si no alineas las referencias temporales, puedes terminar comparando eventos que no corresponden al mismo momento.

Veamos un ejemplo con un escenario que seguramente les resultará familiar a muchos equipos de soporte.

Un usuario está recibiendo timeouts de forma intermitente en la función F.

Ya validé que los recursos A y B están disponibles y que no presentan señales de saturación ni acumulación de solicitudes.

El componente C está mostrando latencia. Analiza su comportamiento y correlaciónalo con el rendimiento de la función F durante la ventana de tiempo [hora de inicio] a [hora final], en UTC-6.

Identifica las evidencias que respaldan o descartan al componente C como posible origen del problema. Explica las correlaciones encontradas, las hipótesis alternativas y las consultas utilizadas para llegar a tus conclusiones.

La diferencia está en que no le estoy pidiendo que adivine qué falla. Le estoy dando un síntoma, un contexto y una hipótesis que debe contrastar con los datos.

En mi experiencia, el agente encontró correlaciones que respaldaban mi hipótesis y me presentó evidencias que podía contrastar con mi análisis.

En cuestión de minutos tenía consultas KQL, un informe y gráficos que me ayudaban a visualizar los hallazgos.

¿Eso significa que el agente siempre encontrará la causa raíz? No. La calidad de la telemetría, el contexto disponible y el alcance de la investigación influyen en los resultados. Una correlación tampoco demuestra, por sí sola, que un componente sea la causa del problema.

Las consultas y los gráficos requieren revisión. Las conclusiones deben contrastarse con los datos y con el conocimiento que tenemos del sistema.

Y si hay que definir un workaround, esa decisión me corresponde a mí, no al agente.

1. El agente acelera, pero tú apuntas. Sin el contexto y las pistas que le proporcioné, la investigación no habría sido la misma.

2. Mira primero tus dashboards. Te ayudan a reconocer patrones y a decidir dónde conviene profundizar.

3. No tengas favoritismos entre servicios. El que menos sospechas puede ser el que merezca una segunda mirada.

4. Acota la búsqueda. No es lo mismo explorar todos los servicios involucrados que centrarte en un conjunto de hipótesis. Tampoco es lo mismo analizar un año de telemetría que una ventana de tiempo relacionada con el síntoma.

5. Valida lo que te entrega. Que una hipótesis parezca confirmada no significa que la causa raíz esté demostrada. Revisa las consultas, los gráficos y las evidencias antes de tomar decisiones.

6. El costo del servicio. El agente usa facturación por consumo, esto entró en vigor el 1 de julio de 2026, y una investigación profunda consume más trabajo y por tanto suele costar más, así que asegúrate de mantener acotado el alcance de las investigaciones.

Lo que te conté corresponde a mi experiencia explorando los datos y solicitando investigaciones puntuales. No he probado todas las capacidades del agente, y todavía queda mucho por explorar.

La observabilidad sigue siendo una disciplina que requiere buenas métricas, telemetría útil, contexto y criterio técnico. La IA puede ayudarnos a recorrer ese camino más rápido, pero no elimina la necesidad de comprender los sistemas que operamos.

Y esa es, para mí, la parte más interesante: no se trata de dejar de investigar, sino de cambiar la forma en que invertimos nuestro tiempo al hacerlo.