Solucionar problemas de políticas de alertas

Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

En esta página, se explica por qué algunas políticas de alertas pueden comportarse de manera diferente a lo previsto y se ofrecen posibles soluciones para esas situaciones.

Para obtener información sobre las variables que pueden afectar una política de alertas, por ejemplo, según el período de duración, consulta Comportamiento de las políticas de alertas basadas en métricas.

La política de uso del disco crea incidentes inesperados

Creaste una política de alertas para supervisar la capacidad "usada" de los discos en tu sistema. Esta política supervisa la métrica agent.googleapis.com/disk/percent_used. Esperas recibir una notificación solo cuando el uso de cualquier disco físico supere el límite que configuraste en la condición. Sin embargo, esta política crea incidentes cuando el uso de cada disco físico es inferior al umbral.

Una causa conocida de incidentes inesperados para estas políticas es que las condiciones no están restringidas a la supervisión de discos físicos. En su lugar, estas políticas supervisan todos los discos, incluidos los discos virtuales, como los dispositivos de bucle invertido. Si se construye un disco virtual para que su uso sea del 100%, se generaría un incidente a fin de que se cree la política.

Por ejemplo, considera el siguiente resultado del comando df de Linux, que muestra el espacio en disco disponible en los sistemas de archivos activados para un sistema:

$ df
/dev/root     9983232  2337708  7629140   24%  /
devtmpfs      2524080        0  2524080    0%  /dev
tmpfs         2528080        0  2528080    0%  /dev/shm
...
/dev/sda15     106858     3934   102924    4%  /boot/efi
/dev/loop0      56704    56704        0  100%  /snap/core18/1885
/dev/loop1     129536   129536        0  100%  /snap/google-cloud-sdk/150
...

En este sistema, se debe configurar una política de alertas de uso de disco para filtrar las series temporales de los dispositivos de bucle invertido /dev/loop0 y /dev/loop1. Por ejemplo, puedes agregar el filtro device !=~ ^/dev/loop.*, que excluye todas las series temporales cuya etiqueta device no coincide con la expresión regular ^/dev/loop.*.

La política de tiempo de actividad no crea las alertas esperadas

Si deseas recibir una notificación si una máquina virtual (VM) se reinicia o se apaga, debes crear una política de alertas que supervise la métrica compute.googleapis.com/instance/uptime. Crea y configura la condición para generar un incidente cuando no haya datos de métricas. No defines la condición mediante el lenguaje de consulta de supervisión (MQL)1. No recibes una notificación cuando se reinicia o se apaga la máquina virtual.

Esta política de alertas solo supervisa las series temporales para las instancias de VM de Compute Engine que están en el estado RUNNING. Las series temporales para las VM que están en cualquier otro estado, como STOPPED o DELETED, se filtran antes de que se evalúe la condición. Debido a este comportamiento, no puedes usar una política de alertas con una condición de alerta de ausencia de métrica para determinar si una instancia de VM está en ejecución. Para obtener información sobre los estados de las instancias de VM, consulta la página sobre el ciclo de vida de las instancias de VM.

A fin de resolver este problema, crea una política de alertas para supervisar una verificación de tiempo de actividad. Para extremos privados, usa verificaciones de tiempo de actividad privadas.

Una alternativa a las alertas en las verificaciones de tiempo de actividad es usar políticas de alertas que supervisen la ausencia de datos. Recomendamos usar alertas en las verificaciones de tiempo de actividad en lugar de la ausencia de datos. Estas alertas pueden generar falsos positivos si hay problemas transitorios con la disponibilidad de los datos de Monitoring.

Sin embargo, si no es posible usar verificaciones de tiempo de actividad, puedes crear una política de alertas con MQL que notifique que la VM se cerró. Las condiciones definidas por MQL no filtran previamente los datos de serie temporal según el estado de la instancia de VM. Debido a que MQL no filtra los datos según los estados de las VM, puedes usarlos para detectar la ausencia de datos de las VM que se cerraron.

Considera la siguiente condición de MQL que supervisa la métrica compute.googleapis.com/instance/cpu/utilization:

fetch gce_instance::compute.googleapis.com/instance/cpu/utilization
|absent_for 3m

Si una VM supervisada por esta condición se apaga, tres minutos después, se genera un incidente y se envían las notificaciones. El valor absent_for debe ser de al menos tres minutos.

Para obtener más información sobre MQL, consulta Políticas de alertas con MQL.

1: MQL es un lenguaje expresivo basado en texto que se puede usar con llamadas a la API de Cloud Monitoring y en Google Cloud Console. Para configurar una condición con MQL cuando usas Google Cloud Console, debes seleccionar el Editor de consultas.

Causas comunes de incidentes anómalos

Creaste una política de alertas y la política parece crear incidentes de forma prematura o incorrecta.

Existen diferentes motivos por los que podrías recibir una notificación de incidentes que parecen ser incorrectos:

  • Si hay un intervalo en los datos, en particular para aquellas políticas de alertas con condiciones de ausencia métrica o de “inferior a”, entonces se puede crear un incidente que parece ser anómalo. Determinar si hay un intervalo en los datos podría no ser fácil. A veces, se oculta la brecha y, a veces, se corrige de forma automática:

    • Por ejemplo, los gráficos pueden ocultar los espacios porque los valores de los datos faltantes se interpolan. Incluso cuando faltan varios minutos de datos, el gráfico conecta los puntos que faltan para la continuidad visual. Tal brecha en los datos subyacentes puede ser suficiente para que una política de alertas cree un incidente.

    • Los puntos en las métricas basadas en registros pueden llegar tarde y reabastecerse, hasta después de 10 minutos. El comportamiento de reabastecimiento corrige la brecha de forma efectiva, y se completa cuando los datos finalmente llegan. Por lo tanto, un intervalo en una métrica basada en registros que ya no se puede ver pudo haber provocado que una política de alertas creara un incidente.

  • Las condiciones de límite de ausencia de la métrica y las de "inferior a" se evalúan en tiempo real, con un pequeño retraso de consulta. El estado de la condición puede cambiar entre el momento en que se evalúa y el momento en que el incidente correspondiente es visible en Monitoring.

  • Las condiciones que están configuradas para crear un incidente en una sola medida pueden dar como resultado incidentes que parecen ser prematuros o incorrectos. Para evitar esta situación, asegúrate de que se requieran varias mediciones antes de crear un incidente. Para ello, configura el campo de duración de una condición a fin de que sea más del doble de la tasa de muestreo de la métrica.

    Por ejemplo, si una métrica se muestrea cada 60 segundos, establece la duración en al menos 3 minutos. Si configuras el campo de duración como valor más reciente, o el equivalente en 0 segundos, una sola medición puede causar la creación de un incidente.

  • Cuando se edita la condición de una política de alertas, el cambio puede tomar varios minutos en propagarse a través de la infraestructura de alertas. Durante este período, es posible que recibas notificaciones de incidentes que cumplieron con las condiciones de la política de alertas original.

  • Cuando los datos de las series temporales llegan, puede tomar hasta un minuto hasta que los datos se propaguen a través de toda la infraestructura de alertas. Cuando el período de alineación se establece en un minuto o en la muestra más reciente, la latencia de propagación puede hacer que parezca que la política de alertas se activa de forma incorrecta. Para reducir la posibilidad de esta situación, usa un período de alineación de al menos cinco minutos.

La política de varias condiciones crea varias notificaciones

Creaste una política de alertas que contiene varias condiciones y las uniste con un AND lógico. Esperas recibir una notificación y crear un incidente cuando se cumplan todas las condiciones. Sin embargo, recibes varias notificaciones y ves que se crean varios incidentes.

Cuando una política de alertas contiene varias condiciones que se unen con un AND lógico, si esa política se activa, entonces, por cada serie temporal que dé como resultado una condición, la política enviará una notificación y creará un incidente. Por ejemplo, si tienes una política con dos condiciones y cada condición supervisa una serie temporal, se abren dos incidentes y recibes dos notificaciones.

No puedes configurar Cloud Monitoring para crear un solo incidente y enviar una sola notificación.

Para obtener más información, consulte Notificaciones por incidente.

No se pueden ver los detalles del incidente debido a un error de permiso

Navega a la página de incidentes en Google Cloud Console y selecciona un incidente que desees ver. Esperas tener abierta la página de detalles. Sin embargo, no se puede abrir la página de detalles y se muestra el mensaje "Permiso denegado".

Para resolver esta situación, asegúrate de que tu función de Identity and Access Management (IAM) sea roles/monitoring.viewer o que incluya todos los permisos de esa función. Por ejemplo, las funciones roles/monitoring.editor y roles/monitoring.admin incluyen todos los permisos de la función de visualizador.

Las funciones personalizadas no pueden otorgar el permiso necesario para ver los detalles del incidente.

El proyecto es incorrecto en la lista de detalles del incidente

Cuando recibes una notificación de una alerta, el resumen de la condición muestra el proyecto de Google Cloud en el que se creó la alerta, es decir, muestra el proyecto de permisos. Sin embargo, esperas que el incidente muestre el nombre del proyecto de Google Cloud que almacena las series temporales que causan la activación del incidente.

Las opciones de agregación especificadas en la condición de una política de alertas determinan el proyecto de Google Cloud al que se hace referencia en una notificación:

  • Cuando las opciones de agregación eliminan la etiqueta que almacena el ID del proyecto, la información del incidente enumera el proyecto de permisos. Por ejemplo, si agrupas los datos solo por zona, se quitará la etiqueta que almacena el ID del proyecto después de agruparlos.

  • Cuando las opciones de agregación conservan la etiqueta que almacena el ID del proyecto, las notificaciones de incidentes incluyen el nombre del proyecto de Google Cloud que almacena la serie temporal que genera el incidente. Para conservar la etiqueta del ID del proyecto, no agrupes las series temporales ni incluyas la etiqueta project_id en el campo de agrupación.

No se pudo cerrar un incidente de forma manual

Recibiste una notificación de un incidente en tu sistema. Ve a la página de detalles del incidente y haz clic en Cerrar incidente. Esperas que se cierre el incidente; sin embargo, recibirás el mensaje de error:

Unable to close incident with active conditions.

Solo puedes cerrar un incidente cuando no llega ninguna observación en el período de alerta más reciente. El período de alerta, que suele tener un valor predeterminado de 5 minutos, se define como parte de la condición de la política de alertas y se puede configurar. El mensaje de error anterior indica que los datos se recibieron en el período de alerta.

El siguiente error ocurre cuando no se puede cerrar un incidente debido a un error interno:

Unable to close incident. Please try again in a few minutes.

Cuando veas el mensaje de error anterior, puedes volver a intentar la operación de cierre o permitir que Monitoring cierre el incidente de forma automática.

Para obtener más información, consulta Administra incidentes.

No se reciben notificaciones

Configuras los canales de notificaciones y esperas recibir una notificación cuando se produzcan incidentes. No recibes ninguna notificación.

Para obtener información sobre cómo resolver problemas con las notificaciones de webhook y Pub/Sub, consulta las siguientes secciones de este documento:

Para recopilar información sobre la causa del error, haz lo siguiente:

  1. En la consola de Google Cloud, ve a la página Explorador de registros:

    Ir al Explorador de registros.

  2. Selecciona el proyecto de Cloud adecuado.

  3. Consulta los registros para ver los eventos del canal de notificación:

    1. Expande el menú Log name (Nombre del registro) y selecciona notification_channel_events.
    2. Expande el menú Gravedad y selecciona Error.
    3. Utilice el menú Intervalo de tiempo para seleccionar un intervalo de tiempo.
    4. Haga clic en Ejecutar consulta.

    En los pasos anteriores, se crea la siguiente consulta:

    logName="projects/PROJECT_ID/logs/monitoring.googleapis.com%2Fnotification_channel_events"
    severity=ERROR
    

    Por lo general, la información de fallas se incluye en la línea de resumen y en el campo jsonPayload.

    Por lo general, la línea de resumen y el campo jsonPayload contienen información sobre fallas. Por ejemplo, cuando se produce un error de puerta de enlace, la línea de resumen incluye el mensaje “failed with 502 Bad Gateway”.

No se reciben las notificaciones de webhook que se envían a Google Chat

Configura un canal de notificación de webhook en Cloud Monitoring y, luego, configura el webhook para enviarlo a Google Chat. Sin embargo, no recibes notificaciones o recibes errores 400 Bad Request.

A fin de resolver este problema, configura un canal de notificaciones de Pub/Sub en Cloud Monitoring y, luego, configura un servicio de Cloud Run para convertir los mensajes de Pub/Sub al formato que espera Chat y, luego, entregar la notificación a Google Chat. Para ver un ejemplo de esta configuración, consulta Crea notificaciones personalizadas con Cloud Monitoring y Cloud Run.

No se reciben notificaciones de webhook

Configura un canal de notificación de webhook y espera recibir notificaciones cuando se produzcan incidentes. No recibes ninguna notificación.

Extremo privado

No puedes usar webhooks para las notificaciones, a menos que el extremo sea público.

Para resolver esta situación, usa las notificaciones de Pub/Sub combinadas con una suscripción de extracción a ese tema de notificación.

Cuando configuras un canal de notificaciones de Pub/Sub, las notificaciones de incidentes se envían a una cola de Pub/Sub que tiene controles de Identity and Access Management. Cualquier servicio que pueda consultar o escuchar un tema de Pub/Sub puede consumir estas notificaciones. Por ejemplo, las aplicaciones que se ejecutan en las máquinas virtuales de App Engine, Cloud Run o Compute Engine pueden consumir estas notificaciones.

Si usas una suscripción de extracción, se envía una solicitud a Google que espera que llegue un mensaje. Estas suscripciones requieren acceso a Google, pero no requieren reglas para firewalls ni acceso entrante.

Extremo público

Para identificar por qué falló la entrega, examina las entradas de registro de Cloud Logging en busca de información de error.

Por ejemplo, puedes buscar entradas de registro para el recurso de canal de notificaciones con el Explorador de registros, con un filtro como el siguiente:

resource.type="stackdriver_notification_channel"

No se reciben notificaciones de Pub/Sub

Configuras un canal de notificaciones de Pub/Sub, pero no recibes ninguna notificación de alertas.

Para resolver esta condición, prueba lo siguiente:

  • Asegúrate de que exista la cuenta de servicio de notificaciones. No se envían notificaciones cuando se borra la cuenta de servicio.

    Para verificar que la cuenta de servicio existe, haz lo siguiente:

    1. En Google Cloud Console, ve a la página IAM:

      Ir a IAM

    2. Busca una cuenta de servicio que tenga la siguiente convención de nombres:

      service-PROJECT_NUMBER@gcp-sa-monitoring-notification.iam.gserviceaccount.com

      Si esta cuenta de servicio no aparece en la lista, selecciona Incluir asignaciones de funciones proporcionadas por Google, como se muestra en la siguiente captura de pantalla:

      Selecciona la opción Incluir asignaciones de roles proporcionadas por Google.

    Para crear una cuenta de servicio de notificaciones, haz lo siguiente:

    1. En Google Cloud Console, selecciona Monitoring.

      Ir a Monitoring

    2. Haz clic en Alertas y, luego, en Editar canal de notificaciones.

    3. En la sección Pub/Sub, haz clic en Agregar nuevo.

      El cuadro de diálogo Canal de Pub/Sub creado muestra el nombre de la cuenta de servicio que creó Monitoring.

    4. Haz clic en Cancelar.

    5. Otorga los permisos de la cuenta de servicio para publicar tus temas de Pub/Sub como se describe en Autoriza la cuenta de servicio.

  • Asegúrate de que la cuenta de servicio de notificaciones esté autorizada para enviar notificaciones de los temas de interés de Pub/Sub.

    Para ver los permisos de una cuenta de servicio, puedes usar Google Cloud Console o el comando de Google Cloud CLI:

    • En la página de IAM en Google Cloud Console, se enumeran las funciones para cada cuenta de servicio.
    • En la página Temas de Pub/Sub en Google Cloud Console, se enumera cada tema. Cuando seleccionas un tema, la pestaña Permisos enumera las funciones otorgadas a las cuentas de servicio.
    • Para enumerar todas las cuentas de servicio y sus funciones, ejecuta el siguiente comando de Google Cloud CLI:

      gcloud projects get-iam-policy PROJECT_ID
      

      La siguiente es una respuesta parcial para este comando:

          serviceAccount:service-PROJECT_NUMBER@gcp-sa-monitoring-notification.iam.gserviceaccount.com
             role: roles/monitoring.notificationServiceAgent
           - members:
             [...]
             role: roles/owner
           - members:
             - serviceAccount:service-PROJECT_NUMBER@gcp-sa-monitoring-notification.iam.gserviceaccount.com
             role: roles/pubsub.publisher
      

      La respuesta del comando incluye solo funciones, no incluye autorización por tema.

    • Para enumerar las vinculaciones de IAM para un tema específico, ejecuta el siguiente comando:

      gcloud pubsub topics get-iam-policy TOPIC
      

      La siguiente es una respuesta de muestra para este comando:

          bindings:
          - members:
            - serviceAccount:service-PROJECT_NUMBER@gcp-sa-monitoring-notification.iam.gserviceaccount.com
            role: roles/pubsub.publisher
          etag: BwXPRb5WDPI=
          version: 1
      

    Para obtener información sobre cómo autorizar la cuenta de servicio de notificaciones, consulta Autoriza la cuenta de servicio.