Alertas de registro en Azure Monitor

Introducción

Las alertas de registro son uno de los tipos de alerta que se admiten en Alertas de Azure. Las alertas de registro permiten a los usuarios usar una consulta de Log Analytics para evaluar los registros de los recursos según una frecuencia establecida y activar una alerta en función de los resultados. Las reglas pueden desencadenar una o varias acciones mediante grupos de acciones.

Requisitos previos

Las alertas de registro ejecutan consultas sobre los datos de Log Analytics. En primer lugar, debe comenzar a recopilar datos de registro y consultar estos datos de registro para detectar problemas. Puede usar el artículo de ejemplos de consultas de alertas en Log Analytics para comprender qué puede detectar, o bien puede empezar a escribir su propia consulta.

El colaborador de supervisión de Azure es un rol común necesario para crear, modificar y actualizar las alertas de registro. También se necesitan derechos de acceso y de ejecución de consulta para los registros de recursos. El acceso parcial a los registros de recursos puede producir errores en las consultas o devolver resultados parciales. Más información sobre la configuración de alertas de registro en Azure.

Definición de la evaluación de la consulta

La definición de la condición de las reglas de búsqueda de registros comienza con estos puntos:

• ¿Qué consulta debo ejecutar?
• ¿Cómo uso los resultados?

En las secciones siguientes se describen los distintos parámetros que se pueden usar para establecer la lógica anterior.

Consulta de registro

La consulta de Log Analytics se utiliza para evaluar la regla. Los registros devueltos por esta consulta se usan para determinar si se desencadena una alerta. El ámbito de la consulta puede ser:

• Un recurso específico, como una máquina virtual.
• Un recurso a gran escala, como una suscripción o un grupo de recursos.
• Varios recursos, mediante el uso de una consulta entre recursos.

Intervalo de tiempo de consulta

El intervalo de tiempo se establece en la definición de la condición de la regla. En las áreas de trabajo y en Application Insights, se llama Período. En los demás tipos de recursos, se llama Reemplazar intervalo de tiempo de consulta.

Al igual que en el análisis de registros, el intervalo de tiempo limita los datos de consulta al intervalo especificado. Este intervalo se aplica incluso si se utiliza el comando ago en la consulta.

Por ejemplo, una consulta examina 60 minutos si el intervalo de tiempo es de 60 minutos, aunque el texto contenga ago(1d) . El intervalo de tiempo y el filtrado de tiempo de la consulta deben coincidir. En el caso del ejemplo, cambiar el valor de Período / Reemplazar intervalo de tiempo de consulta a un día funcionaría según lo esperado.

Measure

Las alertas de registro convierten el registro en valores numéricos que se pueden evaluar. Se pueden medir dos elementos diferentes:

Recuento de las filas de la tabla de resultados

El recuento de resultados es la medida predeterminada. Es la medida perfecta para trabajar con eventos como registros de eventos de Windows, syslog o excepciones de aplicaciones. Se desencadena cuando se producen o no se producen entradas de registro en el período de tiempo evaluado.

Las alertas de registro funcionan mejor cuando se quieren detectar datos en el registro. No funcionan tan bien cuando se quiere detectar la falta de datos en los registros. Por ejemplo, cuando se trata de alertas sobre el latido de máquinas virtuales.

En el caso de las áreas de trabajo y Application Insights, se llama Basada en con la selección Número de resultados. En los demás tipos de recursos, se denomina Medida con la selección Filas de la tabla.

Ejemplo de caso de uso de recuento de filas de la tabla de resultados

Desea saber cuándo respondió la aplicación con el código de error 500 (error interno del servidor). Crearía una regla de alertas con los detalles siguientes:

• Consulta:

requests
| where resultCode == "500"

• Período de tiempo / Granularidad de agregación: 15 minutos
• Frecuencia de la alerta: 15 minutos
• Valor del umbral: mayor que 0

Con esta configuración, la regla de alertas supervisa si hay solicitudes que terminen con el código de error 500. La consulta se ejecuta cada 15 minutos y busca en los últimos 15 minutos. Si se encuentra aunque sea un registro, se activa la alerta y se desencadenan las acciones configuradas.

Cálculo de medida basado en una columna numérica (como el valor del contador de CPU)

En el caso de las áreas de trabajo y Application Insights, se llama Basada en con la selección Unidades métricas. En los demás tipos de recursos, se denomina Medida con la selección de cualquier nombre de columna de número.

Tipo de agregación

El cálculo se realiza en varios registros para agregarlos a un único valor numérico. Por ejemplo:

• Recuento devuelve el número de registros de la consulta.
• Media devuelve el promedio de la columna de la medida Granularidad de agregación definida.

En las áreas de trabajo y Application Insights, solo se admite en el tipo de medida Unidades métricas. El resultado de la consulta debe contener una columna denominada AggregatedValue que proporcione un valor numérico después de una agregación definida por el usuario. En los demás tipos de recursos, el valor de Tipo de agregación se selecciona a partir del campo con ese nombre.

Granularidad de agregación

Determina el intervalo que se usa para agregar varios registros en un solo valor numérico. Por ejemplo, si ha especificado 5 minutos, los registros se agruparán por intervalos de 5 minutos según el valor especificado en Tipo de agregación.

En las áreas de trabajo y Application Insights, solo se admite en el tipo de medida Unidades métricas. El resultado de la consulta debe contener bin(), que establece el intervalo de los resultados de la consulta. En los demás tipos de recursos, el campo que controla esta configuración se denomina Granularidad de agregación.

División por dimensiones de alerta

Puede dividir las alertas por columnas de número o de cadena en alertas independientes mediante la agrupación en combinaciones únicas. Al crear alertas orientadas a recursos a gran escala (con un ámbito de suscripción o grupo de recursos), puede dividirlas por columna de identificador de recurso de Azure. La división según la columna de identificador de recurso de Azure cambiará el destino de la alerta al recurso especificado.

Se recomienda dividir por la columna de identificador de recursos de Azure cuando quiera supervisar la misma condición en varios recursos de Azure. Por ejemplo, supervisar un uso de la CPU superior al 80 % en todas las máquinas virtuales. También puede decidir no dividirlas cuando desea una condición en varios recursos del ámbito. Como, por ejemplo, supervisar que al menos cinco máquinas del ámbito del grupo de recursos tengan un uso de la CPU superior al 80 %.

En las áreas de trabajo y Application Insights, solo se admite en el tipo de medida Unidades métricas. El campo se denomina Agregado en. Se limita a tres columnas. Si hay más de tres columnas de agrupación en la consulta, pueden producirse resultados inesperados. En los demás tipos de recursos, se configura en la sección Split by dimensions (Dividir por dimensiones) de la condición (se limita a seis divisiones).

Ejemplo de división por dimensiones de alerta

Por ejemplo, supongamos que desea supervisar los errores de varias máquinas virtuales que ejecutan la aplicación o el sitio web en un grupo de recursos específico. Puede hacerlo mediante una regla de alertas de registro, tal como se indica a continuación:

• Consulta:

  // Reported errors
  union Event, Syslog // Event table stores Windows event records, Syslog stores Linux records
  | where EventLevelName == "Error" // EventLevelName is used in the Event (Windows) records
  or SeverityLevel== "err" // SeverityLevel is used in Syslog (Linux) records
  

  Cuando se usan áreas de trabajo y Application Insights con la lógica de alerta Unidades métricas, es necesario agregar esta línea al texto de la consulta:

  | summarize AggregatedValue = count() by Computer, bin(TimeGenerated, 15m)
  

• Resource ID Column (Columna de id. de recurso) : _ResourceId (actualmente, la división por la columna de identificador de recurso en las reglas de alertas solo está disponible en las suscripciones y los grupos de recursos)

• Dimensiones/Agregado en:

  • Equipo = VM1, VM2 (actualmente, no está disponible el filtrado de valores en la definición de reglas de alertas para áreas de trabajo y Application Insights; debe filtrar en el texto de la consulta)

• Período de tiempo / Granularidad de agregación: 15 minutos

• Frecuencia de la alerta: 15 minutos

• Valor del umbral: mayor que 0

Esta regla supervisa si alguna máquina virtual presentó eventos de error en los últimos 15 minutos. Cada máquina virtual se supervisa por separado y desencadena acciones de forma individual.

Definición de la lógica de alerta

Después de definir la consulta para ejecutar y evaluar los resultados, deberá definir la lógica de alerta y cuándo activar las acciones. En las secciones siguientes se describen los distintos parámetros que se pueden usar:

Umbral y operador

Los resultados de la consulta se transforman en un número que se compara con el umbral y operador.

Frecuencia

El intervalo en el que se ejecuta la consulta. Se puede establecer entre un minuto y un día. Debe ser igual o menor que el intervalo de tiempo de consulta para no omitir entradas del registro.

Por ejemplo, supongamos que establece el período de tiempo en 30 minutos y la frecuencia en 1 hora. Si la consulta se ejecuta a las 00:00, devuelve registros entre las 23:30 y las 00:00. La próxima vez que se ejecute la consulta será a la 01:00 y devolverá los registros comprendidos entre las 00:30 y la 01:00. Por tanto, nunca se evaluarán los registros creados entre las 00:00 y las 00:30.

Número de infracciones que desencadenarán la alerta

Puede especificar el período de evaluación de la alerta y el número de errores necesarios para desencadenarla. Esto permite definir mejor el tiempo de impacto para desencadenar una alerta.

Por ejemplo, si el valor de Granularidad de agregación de la regla se define como "5 minutos", solo se puede desencadenar una alerta si se producen tres errores (15 minutos) en la última hora. Esta configuración se define mediante la directiva empresarial de la aplicación.

Estado y resolución de alertas

Las alertas de registro pueden ser sin estado o con estado (actualmente en versión preliminar).

Las alertas sin estado se activan cada vez que se cumple la condición, incluso si se han activado anteriormente. Puede marcar la alerta como cerrada una vez que se resuelva la instancia de alerta. También puede silenciar acciones para evitar que se desencadenen durante un período después de que se active una regla de alertas. En áreas de trabajo de Log Analytics y Application Insights, esta opción se llama Suprimir alertas. En los demás tipos de recursos, se denomina Silenciar acciones.

Consulte este ejemplo de evaluación de alertas sin estado:

Las alertas con estado se activa una vez por incidente y se resuelven. La regla de alerta se resuelve cuando la condición de alerta no se cumple durante 30 minutos durante un período de evaluación específico (para tener en cuenta el retraso de ingesta de registros) y durante tres evaluaciones consecutivas para reducir el ruido si hay condiciones de oscilación. Por ejemplo, con una frecuencia de 5 minutos, la alerta se resuelve después de 40 minutos; con una frecuencia de 1 minuto, la alerta se resuelve después de 32 minutos. Cuando la notificación resuelta se envíe a través del webhook o del correo electrónico, el estado de la instancia de alerta (llamada estado de supervisión) de Azure Portal también se establecerá como Resuelta.

La característica de alertas con estado se encuentra actualmente en versión preliminar en la nube pública de Azure. Puede establecer esta opción mediante Automatically resolve alerts (Resolución automática de alertas) de la sección de detalles de alertas.

Selección de ubicación en alertas de registro

Las alertas de registro le permiten establecer una ubicación para las reglas de alertas. En Áreas de trabajo de Log Analytics, la ubicación de la regla debe coincidir con la ubicación del área de trabajo. En todos los demás recursos, puede seleccionar cualquiera de las ubicaciones admitidas, las cuales coinciden con la lista de regiones admitidas de Log Analytics.

La ubicación afecta a la región en la que se evalúa la regla de alertas. Las consultas se ejecutan en los datos de registro de la región seleccionada, es decir, el servicio de alertas completo es global. Lo que significa que la definición de la regla de alertas, las alertas desencadenadas, las notificaciones y las acciones no están ligadas a la ubicación de la regla de alertas. Los datos se transfieren desde la región establecida ya que el servicio de alertas de Azure Monitor es un servicio no regional.

Precios y facturación de las alertas de registro

La información de precios se encuentra en la página de precios de Azure Monitor. Las alertas de registro aparecen bajo el proveedor de recursos microsoft.insights/scheduledqueryrules con:

• Las alertas de registro en Application Insights se muestran con el nombre exacto del recurso junto con las propiedades del grupo de recursos y la alerta.
• Las alertas de registro de Log Analytics se muestran con el nombre exacto del recurso junto con las propiedades del grupo de recursos y la alerta, cuando se crean mediante scheduledQueryRules API.
• Las alertas de registro creadas con la API heredada de Log Analytics no son recursos de Azure con seguimiento y no tienen nombres de recurso únicos. Estas alertas se siguen creando en microsoft.insights/scheduledqueryrules como recursos ocultos, que tienen la estructura de nomenclatura de recursos <WorkspaceName>|<savedSearchId>|<scheduleId>|<ActionId>. Las alertas de registro de la API heredada se muestran con el nombre de recurso oculto anterior junto con las propiedades del grupo de recursos y la alerta.

Pasos siguientes

• Más información sobre la creación de alertas de registro en Azure.
• Información sobre webhooks en alertas de registro en Azure.
• Más información acerca de las Alertas de Azure.
• Más información sobre Log Analytics.