Compartir a través de


Solución de problemas de alertas de búsqueda de registros en Azure Monitor

Este artículo describe cómo resolver incidencias habituales con las alertas de registro en Azure Monitor. Además, se proporcionan soluciones a los problemas comunes sobre la funcionalidad y la configuración de las alertas de registro.

Puede usar las alertas de registro para evaluar los registros de recursos según una frecuencia establecida mediante una consulta de Log Analytics y activar una alerta en función de los resultados. Las reglas pueden desencadenar una o varias acciones mediante grupos de acciones. Para más información sobre la funcionalidad y la terminología de las alertas de búsqueda de registros, consulte Alertas de registro en Azure Monitor.

Nota:

En este artículo no se describen los casos en los que se desencadenó la regla de alertas, puede verla en Azure Portal, pero no se envió la notificación. Consulte solución de problemas de alertas para ver casos como estos.

Una alerta de búsqueda de registros no se ha desencadenado cuando debería

Si la alerta de búsqueda de registros no se ha desencadenado cuando debería, compruebe los siguientes elementos:

  1. ¿La regla de alerta está en un estado de mantenimiento degradado o no disponible?

    Vea el estado de mantenimiento de la regla de alertas de búsqueda de registros:

    1. En el portal, seleccione Supervisar y, a continuación, Alertas.

    2. En la barra de comandos superior, seleccione Regla de alertas. La página muestra todas tus reglas de alerta en todas las suscripciones.

    3. Seleccione la regla de alertas de búsqueda de registros que quiere supervisar.

    4. En el panel izquierdo, en Ayuda, seleccione Estado de los recursos.

      Captura de pantalla de la sección Estado del recurso en una regla de alertas de búsqueda de registros.

    Consulte Supervisión del estado de las reglas de alertas de búsqueda de registros para obtener más información.

  2. Compruebe la latencia de ingesta de registros.

    Azure Monitor procesa terabytes de registros de clientes de todo el mundo, lo que puede provocar latencia en la ingesta de registros.

    Los registros son datos semiestructurados e intrínsecamente con mayor latencia que las métricas. Si advierte que hay más de cuatro minutos de retraso en las alertas activadas, debería usar alertas de métricas. Puede enviar datos al almacén de métricas desde los registros mediante alertas de métricas para registros.

    El sistema vuelve a intentar la evaluación de la alerta varias veces para mitigar la latencia. Una vez que llegan los datos, se activa la alerta, lo cual en la mayoría de los casos no coincide con la hora de entrada del registro.

  3. ¿Se silencian las acciones o se configuró la regla de alerta para resolverse automáticamente?

    Un problema común es que cree que la alerta no se ha activado, pero la regla se configuró para que la alerta no se activara. Consulte las opciones avanzadas de la regla de alertas de búsqueda de registros para comprobar que las dos opciones siguientes no están seleccionadas:

    • La casilla Silenciar acciones : permite silenciar las acciones de alerta desencadenadas durante un período de tiempo establecido.
    • Resolver automáticamente las alertas: configura la alerta para que solo se active una vez por cada condición que se cumpla.

    Suprimir alertas

  4. ¿Se ha movido o eliminado el recurso de regla de alertas?

    En caso de moverse un recurso de destino de regla de alertas, cambiarse el nombre o eliminarse, todas las reglas de alertas de registro que hagan referencia a ese recurso se interrumpirán. Para corregir este problema, las reglas de alerta deben volver a crearse mediante un recurso de destino válido para el ámbito.

  5. ¿La regla de alerta usa una identidad administrada asignada por el sistema?

    Al crear una regla de alertas del registro con una identidad administrada asignada por el sistema, la identidad se crea sin permisos. Después de crear la regla, debe asignar los roles adecuados a la identidad de la regla para que pueda acceder a los datos que quiere consultar. Por ejemplo, puede que tenga que asignarle el rol Lector para las áreas de trabajo pertinentes de Log Analytics o un rol Lector y un rol Visor de bases de datos para el clúster de ADX correspondiente. Consulte las identidades administradas para obtener más información sobre el uso de identidades administradas en las alertas de registro.

  6. ¿La consulta se usa en la regla de alertas de búsqueda de registros válida?

    Cuando se crea una regla de alertas de registro, se valida la consulta para comprobar si la sintaxis es correcta. En ocasiones, sin embargo, la consulta proporcionada en la regla de alertas de registro puede empezar a producir un error. Estos son algunos de los motivos habituales:

    • Las reglas se crearon a través de la API y el usuario omitió la validación.
    • La consulta se ejecuta en varios recursos y uno o varios de los recursos se eliminaron o se movieron.
    • Se produce un error en la consulta por los siguientes motivos:
      • Los datos dejaron de llegar a una tabla de la consulta durante más de 30 días.
      • No se han creado tablas de registros personalizados porque no se ha iniciado el flujo de datos.
    • Los cambios en el lenguaje de consulta incluyen un formato revisado para comandos y funciones, por lo que la consulta proporcionada anteriormente ya no es válida.

    Azure Resource Health supervisa el estado de los recursos en la nube, incluyendo las reglas de alertas de búsqueda de registros. Cuando una regla de alertas de búsqueda de registros es correcta, la regla se ejecuta y la consulta se ejecuta correctamente. Puede usar estado de los recursos para las reglas de alertas de búsqueda de registros para obtener información sobre los problemas que afectan a las reglas de alertas de búsqueda de registros.

  7. ¿Se ha deshabilitado la regla de alertas de búsqueda de registros?

    Si una consulta de regla de alertas de búsqueda de registros no se puede evaluar continuamente durante una semana, Azure Monitor la deshabilita automáticamente.

Además, hay un ejemplo del evento de Registro de actividad que se envía cuando se deshabilita una regla.

Ejemplo de registro de actividad cuando la regla está deshabilitada

{
    "caller": "Microsoft.Insights/ScheduledQueryRules",
    "channels": "Operation",
    "claims": {
        "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/spn": "Microsoft.Insights/ScheduledQueryRules"
    },
    "correlationId": "abcdefg-4d12-1234-4256-21233554aff",
    "description": "Alert: test-bad-alerts is disabled by the System due to : Alert has been failing consistently with the same exception for the past week",
    "eventDataId": "f123e07-bf45-1234-4565-123a123455b",
    "eventName": {
        "value": "",
        "localizedValue": ""
    },
    "category": {
        "value": "Administrative",
        "localizedValue": "Administrative"
    },
    "eventTimestamp": "2019-03-22T04:18:22.8569543Z",
    "id": "/SUBSCRIPTIONS/<subscriptionId>/RESOURCEGROUPS/<ResourceGroup>/PROVIDERS/MICROSOFT.INSIGHTS/SCHEDULEDQUERYRULES/TEST-BAD-ALERTS",
    "level": "Informational",
    "operationId": "",
    "operationName": {
        "value": "Microsoft.Insights/ScheduledQueryRules/disable/action",
        "localizedValue": "Microsoft.Insights/ScheduledQueryRules/disable/action"
    },
    "resourceGroupName": "<Resource Group>",
    "resourceProviderName": {
        "value": "MICROSOFT.INSIGHTS",
        "localizedValue": "Microsoft Insights"
    },
    "resourceType": {
        "value": "MICROSOFT.INSIGHTS/scheduledqueryrules",
        "localizedValue": "MICROSOFT.INSIGHTS/scheduledqueryrules"
    },
    "resourceId": "/SUBSCRIPTIONS/<subscriptionId>/RESOURCEGROUPS/<ResourceGroup>/PROVIDERS/MICROSOFT.INSIGHTS/SCHEDULEDQUERYRULES/TEST-BAD-ALERTS",
    "status": {
        "value": "Succeeded",
        "localizedValue": "Succeeded"
    },
    "subStatus": {
        "value": "",
        "localizedValue": ""
    },
    "submissionTimestamp": "2019-03-22T04:18:22.8569543Z",
    "subscriptionId": "<SubscriptionId>",
    "properties": {
        "resourceId": "/SUBSCRIPTIONS/<subscriptionId>/RESOURCEGROUPS/<ResourceGroup>/PROVIDERS/MICROSOFT.INSIGHTS/SCHEDULEDQUERYRULES/TEST-BAD-ALERTS",
        "subscriptionId": "<SubscriptionId>",
        "resourceGroup": "<ResourceGroup>",
        "eventDataId": "12e12345-12dd-1234-8e3e-12345b7a1234",
        "eventTimeStamp": "03/22/2019 04:18:22",
        "issueStartTime": "03/22/2019 04:18:22",
        "operationName": "Microsoft.Insights/ScheduledQueryRules/disable/action",
        "status": "Succeeded",
        "reason": "Alert has been failing consistently with the same exception for the past week"
    },
    "relatedEvents": []
}

Se desencadenó una alerta de búsqueda de registros cuando no debería

Es posible que una regla de alertas de registro configurada en Azure Monitor se desencadene de forma inesperada. En las secciones siguientes se describen algunos motivos comunes.

  1. ¿Se desencadenó la alerta debido a problemas de latencia?

    Azure Monitor procesa terabytes de registros de clientes globalmente, lo que puede provocar latencia de ingesta de registros. Existen funcionalidades integradas para evitar alertas falsas, pero pueden seguir produciéndose en datos con mucha latencia (en torno a más de 30 minutos) y en datos con picos de latencia.

    Los registros son datos semiestructurados e intrínsecamente con mayor latencia que las métricas. Si experimenta muchos errores en las alertas desencadenadas, considere la posibilidad de usar alertas de métricas. Puede enviar datos al almacén de métricas desde los registros mediante alertas de métricas para registros.

    Las alertas de búsqueda de registros funcionan mejor cuando intenta detectar datos específicos en los registros. Son menos eficaces cuando intenta detectar la falta de datos en los registros, como las alertas sobre el latido de la máquina virtual.

Mensajes de error al configurar reglas de alertas de búsqueda de registros

Consulte las secciones siguientes para ver mensajes de error específicos y sus resoluciones.

No se pudo validar la consulta, ya que necesita permiso para los registros

Si recibe este mensaje de error al crear o editar la consulta de regla de alertas, asegúrese de que tiene permisos para leer los registros de recursos de destino.

  • Permisos necesarios para leer registros en modo de acceso al contexto del área de trabajo: Microsoft.OperationalInsights/workspaces/query/read.
  • Permisos necesarios para leer los registros en el modo de acceso al contexto de recursos (incluido el recurso de Application Insights basado en el área de trabajo): Microsoft.Insights/logs/tableName/read.

Consulte Administración del acceso a las áreas de trabajo de Log Analytics para obtener más información sobre los permisos.

No se admite la frecuencia de un minuto para esta consulta

Hay algunas limitaciones para usar una frecuencia de regla de alertas de un minuto. Al establecer la frecuencia de la regla de alertas en un minuto, se realiza una manipulación interna para optimizar la consulta. Esta manipulación puede provocar un error en la consulta si contiene operaciones no admitidas.

Para obtener una lista de escenarios no admitidos, consulte esta nota.

No se pudo resolver la expresión escalar denominada <>

Este mensaje de error se puede devolver al crear o editar la consulta de regla de alertas si:

  • Se hace referencia a una columna que no existe en el esquema de tabla.
  • Está haciendo referencia a una columna que no se usó en una cláusula de proyecto anterior de la consulta.

Para mitigar esto, puede agregar la columna a la cláusula de proyecto anterior o usar el operador columnifexists.

La API ScheduledQueryRules no se admite para alertas de OMS de solo lectura

Este mensaje de error se devuelve al intentar actualizar o eliminar reglas creadas con la versión heredada de la API mediante Azure Portal.

  1. Edite o elimine la regla mediante programación mediante la API de REST de Log Analytics.
  2. Recomendado: Actualizar las reglas de alerta para usar la API de reglas de consulta programadas (la API heredada está en una ruta de acceso en desuso).

Se alcanzó el límite del servicio de reglas de alertas

Para más información sobre el número de reglas de alerta de búsqueda de registros por suscripción y los límites máximos de recursos, consulte Límites de servicio de Azure Monitor. Consulte Comprobación del número total de reglas de alertas de registro en uso para ver cuántas reglas de alertas de métricas están actualmente en uso. Si ha alcanzado el límite de cuota, los siguientes pasos pueden ayudar a resolver el problema.

  1. Elimine o deshabilite las reglas de alertas de búsqueda de registros que ya no se usan.

  2. Use la división por dimensiones para reducir el número de reglas. Al usar la división por dimensiones, una regla puede supervisar muchos recursos.

  3. Si necesita aumentar el límite de cuota, abra una solicitud de soporte técnico y proporcione la siguiente información:

    • Los identificadores de suscripción y de recurso para los que tiene que aumentar los límites de cuota.
    • El motivo del aumento de la cuota.
    • El límite de cuota solicitado.

Filtrado de tiempo incompleto en consultas ARG y ADX

Al usar consultas de Azure Data Explorer (ADX) o Azure Resource Graph (ARG) en las alertas de búsqueda de registros, es posible que encuentre un problema por el que la configuración "Granularidad de agregación" no aplica un filtro de tiempo a las consultas. Esto podría provocar resultados inesperados y posibles problemas de rendimiento, ya que la consulta devuelve los 30 días, en lugar del intervalo de tiempo previsto.

Para resolver este problema, debe aplicar explícitamente filtros de tiempo en las consultas ARG y ADX. Estos son los pasos para asegurarse de:

  1. Filtrado de tiempo adecuado: identifique el intervalo de tiempo: determine el intervalo de tiempo específico que desea consultar. Por ejemplo, si desea consultar datos de las últimas 24 horas, debe especificar este intervalo de tiempo en la consulta.

  2. Modificar la consulta: agregue un filtro de tiempo a la consulta ARG o ADX para limitar los datos devueltos al intervalo de tiempo deseado. Este es un ejemplo de cómo modificar la consulta:

    // Original query without time filter
    resources
    | where type == "microsoft.compute/virtualmachines"

    // Modified query with time filter
    resources
    | where type == "microsoft.compute/virtualmachines"
    | where timestamp >= ago(24h)
  1. Pruebe la consulta: ejecute la consulta modificada para asegurarse de que devuelve los resultados esperados dentro del intervalo de tiempo especificado.
  2. Actualizar alertas: actualice las alertas de búsqueda de registros para usar la consulta modificada con el filtro de hora explícito. Esto garantizará que las alertas se basen en los datos correctos y no incluyan datos históricos innecesarios. Al aplicar filtros de tiempo explícitos en las consultas ARG y ADX, puede evitar el problema de recuperar datos excesivos y asegurarse de que las alertas de búsqueda de registros sean precisas y eficaces.

Pasos siguientes