Solucionar problemas de políticas de alertas

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

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

La variable de una etiqueta de métrica es nula

Crea una política de alertas y agrega una variable para una etiqueta de métrica a la sección de documentación. Esperarás que las notificaciones muestren el valor de la variable. Sin embargo, el valor está establecido en null.

Para resolver esta situación, haz lo siguiente:

Asegúrate de que la configuración de agregación para la política de alertas conserve la etiqueta que deseas mostrar.

Por ejemplo, supongamos que creas una política de alertas que supervisa los bytes del disco que escriben las instancias de VM. Si quieres que la documentación enumere el dispositivo que causa la notificación, agrega lo siguiente al campo de documentación: device: ${metric.label.device}.

También debes asegurarte de que la configuración de agregación conserve el valor de la etiqueta device. Para preservar esta etiqueta, configura la función de agregación en none o asegúrate de que las selecciones de agrupación incluyan device.
Verifica la sintaxis y aplicabilidad de la variable. Para obtener información sobre la sintaxis, consulta Anota alertas con la documentación definida por el usuario.

Por ejemplo, la variable log.extracted_label.KEY solo es compatible con alertas basadas en registros. Esta variable siempre se renderiza como null cuando una política de alertas supervisa una métrica, incluso una métrica basada en registros.

La política de uso de discos 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 umbral que configuraste en la condición. Sin embargo, esta política crea incidentes cuando el uso del disco de cada disco físico es menor que el 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 crea un disco virtual de modo que su uso sea del 100%, eso provocaría que se cree un incidente para la política.

Por ejemplo, considera el siguiente resultado del comando df de Linux, que muestra el espacio en el 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 del 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

Deseas recibir notificaciones si una máquina virtual (VM) se reinicia o se apaga, por lo que debes crear una política de alertas que supervise la métrica compute.googleapis.com/instance/uptime. Debes crear y configurar la condición para generar un incidente cuando no haya datos de métricas. No defines la condición con el Lenguaje de consulta de Monitoring (MQL)¹. No recibirás notificaciones cuando la máquina virtual (VM) se reinicie o se apague.

Esta política de alertas solo supervisa las series temporales de las instancias de VM de Compute Engine que están en estado RUNNING. Las series temporales de 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 Ciclo de vida de la instancia de VM.

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

Una posible alternativa a las alertas de las verificaciones de tiempo de actividad es usar políticas de alertas que supervisen la ausencia de datos. Recomendamos generar alertas sobre las verificaciones de tiempo de actividad en lugar de la ausencia de datos: las alertas de ausencia 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 te notifique que la VM se cerró. Las condiciones definidas por MQL no filtran previamente los datos de series temporales en función del estado de la instancia de VM. Debido a que MQL no filtra los datos por estado de la VM, puedes usarlo para detectar la ausencia de datos de las VMs 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 más tarde, se genera un incidente y se envían 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.

¹: MQL es un lenguaje expresivo basado en texto que se puede usar con las llamadas a la API de Cloud Monitoring y en la consola de Google Cloud. Para configurar una condición con MQL cuando usas la consola de Google Cloud, debes usar el editor de código.

La política de recuento de solicitudes no crea las alertas esperadas

Quieres supervisar la cantidad de solicitudes completadas. Creaste una política de alertas que supervisa la métrica serviceruntime.googleapis.com/api/request_count, pero no recibes notificaciones cuando la cantidad de solicitudes supera el umbral que configuraste.

El período de alineación máximo para la métrica de recuento de solicitudes es de 7 horas y 30 minutos.

Para resolver este problema, verifica el valor del período de alineación en tu política de alertas. Si el valor es más largo que el máximo de esta métrica, reduce el período de alineación para que no sea más de 7 horas y 30 minutos.

Causas comunes de incidentes anómalos

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

Existen diferentes motivos por los que podrías recibir notificaciones de incidentes que parecen ser incorrectos:

Si hay un intervalo en los datos, particularmente para esas políticas de alertas con condiciones de umbral de ausencia de métrica o “inferior a”, se puede crear un incidente que parezca anómalo. A veces, el incidente no muestra la brecha de datos y, a veces, la brecha de datos se corrige automáticamente:
- En los gráficos, por ejemplo, es posible que no aparezcan brechas porque los valores de los datos faltantes están interpolados. Incluso cuando faltan varios minutos de datos, el gráfico conecta los puntos faltantes para mantener la continuidad visual. Este intervalo en los datos subyacentes puede ser suficiente para que una política de alertas cree un incidente.
- Los puntos de las métricas basadas en registros pueden llegar tarde y reabastecerse, por hasta 10 minutos antes. El comportamiento de reabastecimiento corrige de forma efectiva el intervalo; este se completa cuando llegan los datos. Por lo tanto, un intervalo en una métrica basada en registros que ya no se puede ver podría 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 configuradas para crear un incidente en una sola medición pueden generar incidentes que parezcan prematuras o incorrectas. Para evitar esta situación, asegúrate de que se requieran varias mediciones antes de que se cree un incidente. Para ello, configura el campo de duración de una condición como más del doble de la tasa de muestreo de la métrica.

Por ejemplo, si se muestrea una métrica cada 60 segundos, establece la duración en, al menos, 3 minutos. Si configuras el campo de duración en valor más reciente, o una cantidad equivalente de 0 segundos, una sola medición puede hacer que se cree un incidente.
Cuando se edita la condición de una política de alertas, el cambio puede tardar varios minutos en propagarse a través de la infraestructura de alertas. Durante este período, es posible que recibas notificaciones de incidentes que cumplan con las condiciones originales de la política de alertas.
Cuando llegan los datos de series temporales, puede tardar hasta un minuto en propagarse por 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.

No se cierra el incidente cuando dejan de llegar los datos

Sigue las instrucciones en Datos parciales de la métrica y configura una política de alertas para cerrar los incidentes cuando dejan de llegar los datos. En algunos casos, los datos dejan de llegar, pero un incidente abierto no se cierra automáticamente.

Si el recurso subyacente supervisado por una política de alertas contiene la etiqueta metadata.system_labels.state, y si esa política no está escrita con el Lenguaje de consulta de Monitoring, entonces Monitoring puede determinar el estado del recurso. Si se sabe que el estado de un recurso está inhabilitado, Monitoring no cierra los incidentes de forma automática cuando dejan de llegar los datos. Sin embargo, puedes cerrar estos incidentes de forma manual.

La política de varias condiciones crea varias notificaciones

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

Monitoring envía una notificación y crea un incidente para cada serie temporal que hace que se cumpla una condición. Como resultado, cuando tienes políticas de alertas con varias condiciones, es posible que recibas una notificación y un incidente por cada serie temporal que haga que se cumplan las condiciones unidas.

Por ejemplo, tienes una política de alertas con dos condiciones, en la que cada condición supervisa 3 series temporales. La política envía una notificación solo cuando se cumplen ambas condiciones. Cuando se cumplen las condiciones de tu política, podrías recibir entre 2 incidentes y notificaciones (una serie temporal se cumple en cada condición) y 6 (todas las series temporales se cumplen en cada condición).

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

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

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

Navega a la página Incidentes en la consola de Google Cloud y selecciona un incidente para verlo. Esperas tener abierta la página de detalles. Sin embargo, la página de detalles no se abre y aparece el mensaje "Permiso denegado".

Para ver todos los detalles del incidente, excepto los datos de métricas, asegúrate de tener las funciones de Identity and Access Management (IAM) de Visualizador de incidentes de Cloud Console de Monitoring (roles/monitoring.cloudConsoleIncidentViewer) y Visualizador de cuentas de Stackdriver (roles/stackdriver.accounts.viewer).

Para ver todos los detalles de incidentes, incluidos los datos de métricas, y poder confirmar o cerrar incidentes, asegúrate de tener las funciones de IAM de visualizador de Monitoring (roles/monitoring.viewer) y editor de incidentes de Cloud Console de Monitoring (roles/monitoring.cloudConsoleIncidentEditor).

Los roles personalizados no pueden otorgar el permiso necesario para ver los detalles de incidentes.

El incidente no se crea cuando se cumple la condición

Creaste una política de alertas que tiene una condición. El gráfico de alertas muestra que los datos supervisados infringen la condición, pero no recibiste una notificación y no se creó un incidente.

Si se cumple alguno de los siguientes criterios después de que se cumple la condición de la política de alertas, Monitoring no abrirá el incidente.

La política de alertas está pospuesta.
La política de alertas está inhabilitada.
La política de alertas alcanzó la cantidad máxima de incidentes que puede abrir de forma simultánea.
Se sabe que el estado del recurso que supervisa la política de alertas está inhabilitado. Monitoring puede determinar el estado de un recurso cuando este contiene la etiqueta metadata.system_labels.state y cuando la política de alertas no está escrita con el lenguaje de consulta de Monitoring.

La lista de detalles del incidente es el proyecto incorrecto

Recibirás una notificación y el resumen de la condición enumera el proyecto de Google Cloud en el que se creó el incidente, es decir, enumera el proyecto de permisos. Sin embargo, esperas que el incidente enumere el nombre del proyecto de Google Cloud que almacena la serie temporal que hizo que Monitoring cree el 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 muestra el proyecto de permisos. Por ejemplo, si agrupas los datos solo por zona, luego de la agrupación, se quita la etiqueta que almacena el ID del proyecto.
Cuando las opciones de agregación conservan la etiqueta que almacena el ID del proyecto, las notificaciones de incidente incluyen el nombre del proyecto de Google Cloud que almacena la serie temporal que causa el incidente. Para conservar la etiqueta del ID del proyecto, incluye la etiqueta project_id en el campo de agrupación o no agrupes las series temporales.

No se puede 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. Se espera que se cierre el incidente. Sin embargo, recibirás el siguiente mensaje de error:

Unable to close incident with active conditions.

Solo puedes cerrar un incidente cuando no llegan observaciones 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 se recibieron datos dentro del período de alerta.

El siguiente error se produce 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 dejar que Monitoring cierre el incidente de forma automática.

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

No se reciben las notificaciones

Configuras los canales de notificaciones y esperas que te notifiquen cuando se produzcan incidentes. No recibirás ninguna notificación.

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

No se reciben las notificaciones de webhook
No se reciben las notificaciones de Pub/Sub

Para recopilar información sobre la causa de la falla, haz lo siguiente:

En el panel de navegación de la consola de Google Cloud, elige Logging y, luego, Explorador de registros:
Ir al Explorador de registros
Selecciona el proyecto de Google Cloud adecuado.
Consulta los registros para ver los eventos del canal de notificaciones:
1. Expande el menú Nombre del registro y selecciona notification_channel_events.
2. Expande el menú Gravedad y selecciona Error.
3. Opcional: Para seleccionar un intervalo de tiempo personalizado, usa el selector de intervalo de tiempo.
4. Haz 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.

La línea de resumen y el campo jsonPayload suelen contener información sobre fallas. Por ejemplo, cuando se produce un error de puerta de enlace, la línea de resumen incluye “Falló con 502 Bad Gateway”.

No hay datos nuevos después de cambiar las definiciones de las métricas

Cambias la definición de una métrica definida por el usuario, por ejemplo, si modificas el filtro que usaste en una métrica basada en registros, y la política de alertas no refleja el cambio que realizaste en la definición de la métrica.

Para resolver este problema, edita el nombre visible de la política de alertas para que se actualice.

No se reciben las notificaciones de webhook que se enviaron a Google Chat

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

Para resolver este problema, configura un canal de notificaciones de Pub/Sub en Monitoring y, luego, configura un servicio de Cloud Run para convertir los mensajes de Pub/Sub en el formato que espera Chat y, luego, envía 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 las notificaciones de webhook

Configuras un canal de notificaciones de webhook y esperas que te notifiquen cuando se produzcan incidentes. No recibirás ninguna notificación.

Extremo privado

No puedes usar webhooks para 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 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 a que llegue un mensaje. Estas suscripciones requieren acceso a Google, pero no requieren reglas de firewall ni de acceso entrante.

Extremo público

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

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

resource.type="stackdriver_notification_channel"

No se reciben las notificaciones de Pub/Sub

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

Para resolver esta condición, prueba lo siguiente:

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

Para verificar que la cuenta de servicio exista, haz lo siguiente:
1. En el panel de navegación de la consola de Google Cloud, elige 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.
Si la cuenta de servicio de notificaciones no existe, debes comenzar el proceso de creación del canal de notificaciones de Pub/Sub para que Monitoring cree la cuenta de servicio:
1. En el panel de navegación de la consola de Google Cloud, elige Monitoring y, luego, Alertas:
  Ir a las Alertas
2. Haz clic en Editar canales de notificaciones.
3. En la sección Pub/Sub, haz clic en Agregar nuevo.
  
  Monitoring crea la cuenta de servicio de notificaciones cuando no existe una. En el cuadro de diálogo Create Pub/Sub Channel, se muestra el nombre de la cuenta de servicio de notificaciones.
  
  Nota: No necesitas terminar de crear el canal de notificaciones de Pub/Sub para que Monitoring cree la cuenta de servicio de notificaciones.
4. Si no deseas agregar un canal de notificaciones, haz clic en Cancelar. De lo contrario, termina de crear el canal de notificaciones y haz clic en Agregar canal.
5. Otorga a la cuenta de servicio permisos para publicar tus temas de Pub/Sub:
  1. En una pestaña del navegador nueva, abre el documento Crea un canal de notificaciones.
  2. Selecciona la pestaña Pub/Sub y, luego, sigue los pasos de la sección Autorizar cuenta de servicio de la página.
Asegúrate de que la cuenta de servicio de notificaciones esté autorizada para enviar notificaciones sobre los temas de interés de Pub/Sub.

Para ver los permisos de una cuenta de servicio, puedes usar la consola de Google Cloud o el comando de Google Cloud CLI:
- En la página IAM de la consola de Google Cloud, se enumeran los roles para cada cuenta de servicio.
- En la página Temas de Pub/Sub en la consola de Google Cloud, se enumera cada tema. Cuando seleccionas un tema, en la pestaña Permisos se enumeran 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 solo incluye funciones, no incluye la autorización por tema.
- A fin de enumerar las vinculaciones de IAM para un tema específico, ejecuta el siguiente comando:
```
gcloud pubsub topics get-iam-policy TOPIC
```
  A continuación, se muestra una respuesta de ejemplo 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.