Fundamentos de Log Analytics y KQL

Un área de trabajo de Log Analytics es el almacén central de datos de Azure Monitor para datos de registros y telemetría. Cuando configura los valores de diagnóstico en un recurso de Azure, los registros y las métricas estructurados se envían al área de trabajo. Después, puede consultar los datos mediante Kusto Query Language (KQL). Un área de trabajo tiene su propia directiva de retención (30 días de forma predeterminada, hasta 730 días) y sus propios controles de acceso.

Todos los recursos de Azure pueden emitir registros de diagnóstico: registros detallados de operaciones como llamadas a la API, eventos de autenticación y ejecución de consultas. Puede habilitarlos mediante Diagnostic Settings en el recurso y especificar como destino su área de trabajo de Log Analytics. Entre las categorías de registros habituales se incluyen AuditEvent para Key Vault, AppServiceHTTPLogs para App Service y NetworkSecurityGroupFlowEvent para NSG.

Kusto Query Language (KQL) es un lenguaje de consulta de solo lectura para analizar datos de registros. Una consulta de KQL se lee de izquierda a derecha como una canalización: comienza con un nombre de tabla y, después, utiliza el operador de canalización (|) para encadenar operadores. Entre los operadores habituales se incluyen where para filtrar, project para seleccionar columnas, summarize para agregar y order by para ordenar. KQL distingue entre mayúsculas y minúsculas en los nombres de columna, pero no en las palabras clave.

El operador where filtra filas mediante expresiones booleanas. Puede combinar condiciones con and, or y not. El operador has realiza búsquedas sin distinción entre mayúsculas y minúsculas respetando los límites de palabra en cadenas, mientras que contains busca una subcadena. El operador in comprueba si un valor pertenece a una lista. Use ago() para expresar intervalos de tiempo relativos, como ago(1h) o ago(7d).

El operador summarize calcula agregaciones entre filas. Entre las funciones de agregación habituales se incluyen count(), sum(), avg(), max(), min() y dcount() para contar valores distintos. Puede agrupar por una o más columnas mediante la cláusula by. La función bin() redondea las marcas de tiempo a intervalos para realizar agregaciones de series temporales.

KQL admite join para correlacionar datos de varias tablas. El tipo de unión predeterminado es innerunique, pero puede especificar inner, leftouter, rightouter o fullouter. Un patrón habitual consiste en unir AzureActivity con AzureMetrics para correlacionar cambios administrativos con descensos del rendimiento. El operador lookup es una alternativa más ligera para enriquecer filas a partir de una tabla de referencia pequeña.

Después de escribir una consulta en el portal de Log Analytics, puede representar los resultados como un gráfico temporal, un gráfico de barras, un gráfico circular o una tabla mediante el operador render. También puede fijar cualquier resultado de consulta en un panel de Azure o guardarlo como un Workbook. El comando render timechart convierte una consulta de summarize de series temporales en un gráfico de líneas instantáneo para analizar tendencias.

Las alertas de búsqueda en registros ejecutan una consulta de KQL según una programación y se activan cuando el resultado cumple una condición, como que el recuento de resultados sea mayor que cero o que una columna numérica supere un umbral. Son más flexibles que las alertas de métricas porque permiten consultar cualquier dato de registro en varias tablas. La frecuencia de evaluación y la ventana de tiempo se pueden configurar de forma independiente; por ejemplo, puede ejecutarse cada 5 minutos sobre los últimos 15 minutos.

Azure Monitor almacena los registros en tablas conocidas. AzureActivity registra las operaciones realizadas en el nivel de suscripción. SecurityEvent contiene registros de seguridad de Windows de máquinas virtuales que tienen instalado el agente de Log Analytics. Heartbeat muestra la conectividad del agente (una fila por minuto por cada máquina virtual conectada). AppRequests, AppExceptions y AppDependencies proceden de Application Insights. Conocer estos nombres de tabla es esencial para escribir consultas operativas eficaces.

Los precios de Log Analytics tienen dos componentes: ingesta de datos (por GB ingerido) y retención de datos (los primeros 30 días son gratuitos; después, se cobra por GB al mes por el período que supere el valor predeterminado). Puede reducir los costos filtrando las categorías de registros ruidosas antes de la ingesta, usando Basic Logs para datos de gran volumen y poco valor a un precio reducido, y archivando los datos antiguos en Azure Data Explorer o en almacenamiento en frío para conservarlos a largo plazo por motivos de cumplimiento.

Las áreas de trabajo de Log Analytics admiten dos modelos de control de acceso. En el modo workspace-context, un usuario con acceso de lectura al área de trabajo puede consultar todas las tablas. En el modo resource-context, un usuario solo puede consultar los registros emitidos por recursos para los que tiene permisos RBAC de lectura, incluso sin acceso explícito al área de trabajo. El modo resource-context se recomienda para organizaciones grandes en las que distintos equipos son responsables de distintos recursos.

Compruebe su comprensión de los conceptos de Microsoft Azure Fundamentals (AZ-900) tratados en esta lección.

En esta lección ha aprendido que las áreas de trabajo de Log Analytics centralizan los datos de registros de diagnóstico de los recursos de Azure, que los operadores de KQL, como where, summarize y render, permiten filtrar, agregar y visualizar registros, y que las alertas de búsqueda en registros desencadenan respuestas automatizadas cuando el resultado de una consulta de KQL cumple una condición definida. A continuación, exploraremos Application Insights para la telemetría a nivel de aplicación.