Preparación para la Certificación Microsoft AI-200
KQL y Azure Monitor para IA: registros, paneles, Workbooks y alertas
Convierte la telemetría de Application Insights en investigaciones, paneles operativos, Azure Workbooks interactivos y alertas proactivas para canalizaciones distribuidas de IA.
Tiempo de estudio sugerido: 120 minutos • Nivel intermedio • Reescritura original completa con versión resumida de cada tema, evaluación comentada y laboratorio guiado
Por João Ricardo Dutra••Contenido original completo
1. Escenario y objetivos de aprendizaje
Una canalización corporativa de moderación recibe documentos mediante una de ingesta, clasifica el contenido con un modelo, extrae entidades y comprueba infracciones de directivas. Algunos documentos superan 30 segundos, determinados formatos hacen que la moderación falle y los usuarios descubren los incidentes antes que operaciones. El objetivo es reunir la salud de la canalización, avisar al equipo en cinco minutos tras un pico de errores e investigar por tiempo, servicio y tipo de documento.
Recuperar y analizar telemetría de con KQL.
Encontrar patrones de error, cuellos de botella en dependencias y tendencias de rendimiento.
Crear un panel de compartido para la supervisión operativa.
Construir Workbooks guiados por parámetros.
Configurar reglas de alertas, grupos de acciones y detección de anomalías.
Resumen rápido
El diseño de supervisión debe convertir datos sin procesar en preguntas, contexto visual, diagnóstico interactivo y respuesta oportuna.
2. KQL y la experiencia de consulta de
KQL (Lenguaje de consulta de Kusto) se usa en Registros de , Analytics y . La consulta parte de una fuente tabular y envía el resultado por operadores separados por una barra vertical. Cada etapa recibe la tabla anterior, la transforma y produce otra, por lo que la lógica se lee de arriba abajo.
Analytics en Microsoft Azure Portal ofrece autocompletado, resaltado de sintaxis, controles temporales, resultados tabulares y gráficos. Se abre desde , un recurso de o un área de trabajo de Analytics. El ámbito elegido determina los recursos, esquemas y alias de tablas disponibles.
Cada operador realiza una transformación explícita y mantiene la investigación legible y fácil de modificar.
Resumen rápido
KQL es una canalización de transformaciones tabulares: define el ámbito y compón un operador analítico claro por etapa.
3. Tablas de y campos de correlación
Telemetría principal y dónde investigarla
Tabla de
Tabla del área de trabajo
Finalidad
AppRequests
Operaciones entrantes, duración, código de respuesta y éxito.
dependencies
AppDependencies
Llamadas salientes a bases de datos, , servicios de , modelos, almacenes vectoriales y microservicios.
exceptions
AppExceptions
Errores controlados y no controlados, mensajes, tipos y pilas.
AppTraces
Mensajes de registro de la aplicación emitidos por marcos compatibles.
customEvents
AppEvents
Eventos de negocio explícitos como documento clasificado o moderación marcada.
customMetrics
AppMetrics
Mediciones como profundidad de cola o confianza.
performanceCounters
AppPerformanceCounters
CPU, memoria, E/S y otros contadores del host.
Las consultas con ámbito de recurso suelen usar nombres cortos; las consultas del área de trabajo usan nombres con prefijo App. El contexto compartido importa más que el alias: timestamp sitúa el evento, operation_Id conecta una operación distribuida, cloud_RoleName identifica el servicio emisor, customDimensions conserva contexto propio e itemCount indica cuántos eventos representa una fila muestreada.
Resumen rápido
Elige la tabla por tipo de telemetría y conserva operation_Id, cloud_RoleName, customDimensions e itemCount para correlacionar y contar correctamente.
4. Filtrar, seleccionar, inspeccionar y clasificar filas
Usa where para condiciones, project para limitar y nombrar la salida, take para una muestra arbitraria y top cuando el orden importa. Las comparaciones exactas usan ==, !=, > y <. En texto, has aprovecha el índice de términos y suele ser mejor para palabras completas; contains busca subcadenas y puede costar más; startswith compara prefijos. Combina condiciones con and y or.
requests
| where timestamp > ago(1h)
| where success == false
| project timestamp, name, resultCode, duration, cloud_RoleName
| top 20 by duration desc
La consulta restringe el periodo, conserva errores, expone los campos que necesita el responsable y devuelve las veinte entradas más lentas. Una proyección deliberada evita además propagar dimensiones irrelevantes o sensibles a exportaciones y mosaicos.
Resumen rápido
Filtra pronto, proyecta solo campos diagnósticos y usa top en lugar de take cuando preguntes por lo mayor, más lento o más reciente.
5. Agregar tendencias con summarize, bin y percentiles
summarize transforma filas en evidencia agrupada. count(), sum(), avg(), min() y max() responden a totales y estadísticas comunes. dcount() estima distintos de forma eficiente; count_distinct() es exacto pero más costoso. percentile() revela la cola de latencia que una media puede ocultar.
Las fechas suelen agruparse con bin(). Sin un intervalo fijo, los milisegundos fragmentan la serie en casi un grupo por evento. Las columnas después de by definen la granularidad.
summarize define la pregunta, bin fija el grano temporal y los percentiles muestran la cola lenta suavizada por la media.
6. Visualizar una consulta con render
render añade una indicación visual al resultado. timechart es natural para métricas agrupadas en el tiempo; barchart y columnchart comparan categorías; piechart muestra una distribución proporcional con pocas categorías; areachart enfatiza movimiento acumulado. El panel de resultados permite cambiar el gráfico, pero conservar render mantiene la presentación al compartir o anclar.
Relaciona forma de datos y visualización
Pregunta
Visual recomendado
¿Cómo cambia p95 en el tiempo?
timechart
¿Qué servicio concentra errores?
barchart
¿Qué cuota de solicitudes atiende cada servicio?
piechart con pocas categorías
¿Cuáles son los últimos errores exactos?
tabla/cuadrícula
Resumen rápido
Un gráfico ayuda cuando sus ejes y categorías coinciden con el resultado; render registra esa intención.
7. Investigar excepciones sin perder volumen muestreado
Empieza midiendo el alcance: cuándo cambió la tasa, qué excepciones dominan y qué operaciones se vieron afectadas. Con muestreo de ingesta, count() cuenta filas almacenadas, no siempre eventos reales. sum(itemCount) recompone el volumen representado y es la agregación correcta para totales muestreados.
exceptions
| where timestamp > ago(24h)
| summarize exceptionCount = sum(itemCount)
by bin(timestamp, 1h), type
| render timechart
exceptions
| where timestamp > ago(24h)
| summarize exceptionCount = sum(itemCount)
by type, operation_Name
| top 10 by exceptionCount desc
El gráfico temporal revela el inicio y la forma del pico; la clasificación lo reduce a un tipo y una operación. En una canalización documental puede mostrar que los tiempos de espera se concentran en un de clasificación y no en todos los servicios.
Resumen rápido
Usa sum(itemCount) para volumen muestreado y avanza desde el momento del pico al tipo de excepción y la operación.
8. Correlacionar solicitudes y excepciones con operation_Id
Un error distribuido rara vez se explica con una tabla. operation_Id enlaza , dependencies, exceptions y de la misma transacción. Proyecta solo lo necesario y renombra columnas duplicadas dentro de cada rama antes del join; de lo contrario, KQL añade sufijos a los nombres ambiguos.
La fila combinada indica si la excepción perteneció a una solicitud visible, cuánto duró y qué rol de nube la atendió. Las excepciones en segundo plano sin correspondiente requieren otra estrategia, como leftouter, y no deben interpretarse como inexistentes.
Resumen rápido
operation_Id reconstruye el incidente entre tablas; proyecta y renombra antes del join para evitar ambigüedades.
9. Analizar latencia y errores de dependencias
La tabla dependencies suele ser la ruta más corta hacia un cuello de botella de IA: inferencia, embeddings, búsqueda vectorial, almacenamiento, bases de datos y posteriores aparecen como llamadas salientes. Compara mediana, p95 y p99 por destino y tipo; examina aparte los errores por código y servicio de origen.
dependencies
| where timestamp > ago(24h)
| summarize averageDuration = avg(duration),
p50 = percentile(duration, 50),
p95 = percentile(duration, 95),
p99 = percentile(duration, 99)
by target, type
| order by p95 desc
dependencies
| where timestamp > ago(24h) and success == false
| summarize failureCount = sum(itemCount)
by target, resultCode, cloud_RoleName
| order by failureCount desc
Interpreta el código en contexto: 429 suele señalar limitación o rendimiento agotado; 5xx apunta a un problema del servidor dependiente; un código ausente con larga duración puede indicar , conectividad o saturación. Los percentiles separan degradación general de cola lenta.
Resumen rápido
Ordena dependencias por latencia de cola y segmenta errores por destino, código y servicio para elegir capacidad, reintentos o fiabilidad.
10. Errores, Rendimiento y diagnóstico de transacciones
Las vistas integradas de complementan consultas propias. Errores agrupa operaciones no satisfactorias y muestra códigos, excepciones, dependencias fallidas y muestras. Al seleccionar una muestra, el diagnóstico de transacción presenta cronológicamente la solicitud, dependencias, excepciones y trazas.
Rendimiento ordena operaciones por duración o volumen y expone la distribución temporal. Una distribución dividida o bimodal puede mostrar que un tipo de documento sigue una ruta mucho más lenta aunque la media sea aceptable. Usa las vistas para orientarte y KQL para joins, dimensiones personalizadas, agregación especializada o visuales reutilizables.
Resumen rápido
Las vistas integradas localizan el área y una transacción concreta; KQL prueba la hipótesis en todo el conjunto.
11. Paneles de para conciencia operativa
Un panel de es una superficie compartida y relativamente estática de mosaicos en Microsoft Azure Portal. Combina métricas, resultados de consultas, Markdown y recursos de distintas suscripciones o grupos. Responde “¿el sistema está sano ahora?” durante la operación diaria, reuniones o monitores de sala.
Tiempo de respuesta y percentiles de latencia.
Solicitudes y dependencias con error.
Tasa de solicitudes y rendimiento.
Éxito de pruebas de disponibilidad.
Pocas señales de negocio como documentos procesados o decisiones de moderación.
Elige la agregación conscientemente: media describe la latencia típica, suma totaliza eventos y máximo expone extremos. Usa filtros o división por rol, operación o código para distinguir servicios.
Resumen rápido
El panel es una superficie operativa enfocada en señales estables de salud, no un lienzo ilimitado de investigación.
Ejecuta la consulta en Registros, selecciona el gráfico y ancla el resultado. Una distancia creciente entre p50 y p95 indica que la mayoría sigue rápida mientras una cola relevante empeora. Los mosaicos se actualizan periódicamente, no continuamente; para un incidente activo usa Live Metrics o una vista interactiva con periodo corto.
Mantén entre cinco y diez mosaicos orientados a decisiones.
Separa salud técnica de resultados de negocio si juntos saturan la pantalla.
Agrupa latencia, fiabilidad, rendimiento y disponibilidad en un flujo predecible.
Usa títulos explícitos como “Latencia p95 de clasificación”.
Añade Markdown con propietario, runbooks y escalamiento.
Publicar comparte el panel, pero se aplica al panel y a cada origen de datos. Sin acceso a , el usuario verá un error de autorización en el mosaico.
Resumen rápido
Ancla consultas listas para decidir, explica el propósito y comprueba permisos del panel y de sus fuentes.
13. Workbooks como informes interactivos
Workbooks combina texto, consultas de registros, métricas, parámetros y visualizaciones en informes reutilizables. A diferencia del panel, un libro responde “¿por qué se comporta así?”: el usuario cambia ámbito, tiempo y filtros, y las etapas dependientes vuelven a ejecutarse.
El panel detecta la condición; el permite cambiar el contexto y seguir la evidencia hasta la causa.
El libro se construye verticalmente con pasos de texto, consulta, métricas y parámetros. Los resultados pueden verse como cuadrículas, líneas, barras, mosaicos o mapas. Las plantillas Microsoft de rendimiento, errores y uso pueden personalizarse o el informe puede comenzar vacío.
Resumen rápido
Los paneles supervisan; Workbooks investiga mediante una narrativa parametrizada de datos y explicaciones.
14. Parámetros, visibilidad condicional y profundización
El parámetro temporal coordina el periodo. Los desplegables pueden ser estáticos o llenarse con KQL, por ejemplo con valores distintos de cloud_RoleName. El selector de recursos alterna entre o áreas de trabajo. La selección múltiple alimenta in para comparar servicios concretos.
Prefiere el temporal nativo para obtener un predicado seguro. La sintaxis depende del control y formato del ; revisa el valor generado antes de inyectarlo en KQL. La visibilidad condicional oculta detalles hasta elegir un servicio. Un enlace de cuadrícula puede abrir el diagnóstico, otro o exportar la fila como parámetro.
Empieza con la salud global.
Coloca filtros de tiempo y servicio arriba.
Haz que una cuadrícula de resumen alimente un parámetro.
Muestra pilas y líneas de dependencias bajo demanda.
Limita consultas porque cada cambio puede volver a ejecutarlas.
Resumen rápido
Los parámetros coordinan el ámbito; cuadrículas enlazadas y pasos condicionales convierten el resumen en investigación enfocada.
15. Anatomía, tipos y severidad de las reglas de alertas
Una regla de alertas de reúne ámbito, condición, acciones y severidad. El ámbito selecciona recursos; la condición define señal y disparo; los grupos de acciones notifican o automatizan; la severidad comunica urgencia de 0 Crítica a 4 Detallada.
Elige el mecanismo
Tipo
Uso adecuado
Alerta de métrica
Métrica precalculada y umbral sencillo o dinámico.
Alerta de búsqueda de registros
Lógica KQL, agregación, joins, dimensiones propias o evaluación programada.
Alerta simple de búsqueda de registros
Cada evento coincidente necesita respuesta rápida.
Alerta de detección inteligente
Anomalía aprendida difícil de expresar con un límite estático.
Estandariza severidades: interrupción de producción en 0, impacto funcional significativo en 1, riesgo emergente en 2, información relevante en 3 y diagnóstico detallado en 4. La severidad debe controlar enrutamiento y respuesta, no solo el color del portal.
Resumen rápido
Una alerta eficaz identifica qué observa, qué evidencia constituye problema, quién o qué responde y con qué urgencia.
16. Crear alertas accionables de búsqueda de registros
Una alerta programada tiene tres controles temporales: frecuencia de evaluación indica cuándo se ejecuta KQL; tamaño de ventana indica cuántos datos examina; número de infracciones indica cuántas evaluaciones deben incumplir. Equilibran velocidad, coste y resistencia a ruido transitorio.
// Failure-volume alert: return a row for every affected service.
requests
| where success == false
| summarize failedCount = sum(itemCount) by cloud_RoleName
| where failedCount > 10
// Latency-SLO alert: detect a p95 above three seconds.
requests
| summarize p95Duration = percentile(duration, 95)
by cloud_RoleName
| where p95Duration > 3s
Para errores, usa ventana y frecuencia de cinco minutos y dispara con más de cero filas; cada fila identifica un servicio con más de diez errores. Para latencia, p95 superior a tres segundos protege la experiencia del 5% más lento mejor que la media. Devuelve contexto suficiente, pero conserva una consulta determinista y compatible con alertas.
Resumen rápido
La consulta debe devolver solo incumplimientos accionables; frecuencia, ventana e infracciones controlan sensibilidad y ruido.
17. Grupos de acciones y detección automática de anomalías
Los grupos de acciones son conjuntos reutilizables de destinatarios y automatizaciones. Las notificaciones incluyen correo, SMS, push y voz. Las acciones llaman ,,, Runbooks de , o sistemas de incidentes. Una alerta puede usar varios grupos y un grupo muchas reglas.
Separa el enrutamiento crítico de las advertencias: un grupo crítico puede avisar al guardia y crear un incidente; uno de advertencia puede escribir al equipo. Prueba los grupos antes de producción y usa el esquema común cuando la automatización necesite una carga estable.
La detección inteligente aprende la línea base e identifica comportamiento inusual. Las anomalías de errores agrupan operaciones, usuarios, excepciones y dependencias; las de rendimiento capturan cambios graduales de latencia o volumen. Las reglas manuales garantizan conocidos; la detección busca desviaciones inesperadas.
Los límites conocidos y las anomalías aprendidas convergen en rutas reutilizables de notificación y corrección.
Resumen rápido
Estandariza la respuesta con grupos de acciones, aplica límites conocidos con reglas y cubre desviaciones nuevas con detección inteligente.
18. Laboratorio guiado: consultar telemetría y crear una alerta
El ejercicio aprovisiona , genera telemetría de , dependencies y exceptions en Python con OpenTelemetry, investiga en Registros y crea un grupo de acciones y una regla programada. Requiere suscripción de ,, Python 3.12 o posterior y actualizada.
Crea un grupo de recursos y ; mantén la cadena fuera del repositorio.
Ejecuta un generador para rutas correctas, lentas, con dependencia fallida y con excepción.
Espera la ingesta y confirma las tres tablas.
Consulta errores y usa sum(itemCount) para totales muestreados.
Une excepciones con solicitudes por operation_Id.
Calcula p50, p95 y p99 de dependencias y segmenta errores por destino y código.
Crea y prueba un grupo de acciones.
Crea una alerta con ámbito, ventana, frecuencia, umbral, severidad y grupo explícitos.
Provoca la condición y confirma la alerta y la notificación.
az monitor app-insights component create \
--app ai200-telemetry --location <region> \
--resource-group <resource-group>
# After generating request, dependency, and exception telemetry,
# create an action group and a scheduled-query alert rule.
az monitor action-group create \
--name ai200-oncall --resource-group <resource-group> \
--short-name ai200
# Use the portal wizard or az monitor scheduled-query create with
# the Application Insights resource ID, KQL condition, window,
# frequency, severity, and action-group resource ID.
Resumen rápido
El laboratorio termina cuando la telemetría sostiene un diagnóstico correlacionado y una alerta provocada llega al destinatario probado.
19. Evaluación comentada, lista de control y referencias
Respuestas de la evaluación
sum(itemCount) produce el total de excepciones consciente del muestreo.
operation_Id enlaza la telemetría de una transacción distribuida.
Workbooks permite filtrar interactivamente por tiempo, servicio y error.
El umbral de filas mayor que cero dispara cuando cualquier servicio devuelve una fila con más de diez errores.
percentile(duration, 95) representa el límite del 5% más lento.
Lista de control de producción
Documenta nombres de tabla por recurso y área de trabajo.
Usa operadores de texto indexados cuando corresponda.
Conserva precisión de muestreo con itemCount.
Correlaciona tablas antes de atribuir la causa.
Supervisa latencia de cola y códigos de dependencias.
Mantén paneles pequeños, nombrados y con permisos probados.
Diseña Workbooks alrededor de preguntas y parámetros.
Ajusta alertas a , persistencia, enrutamiento y contexto.
