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 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, en el período de elección del período de duración, consulta Comportamiento de alertas.

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 estableciste en la condición. Sin embargo, esta política crea incidentes cuando el uso del disco de cada disco físico es inferior al límite.

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 de modo que su utilización sea del 100%, se crearía un incidente para la política.

Por ejemplo, considera la siguiente salida 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 a fin de filtrar las series temporales para los dispositivos de bucle invertido /dev/loop0 y /dev/loop1.

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

Deseas recibir una notificación si una máquina virtual (VM) se reinicia o se cierra, por lo que debes crear una política de alertas que supervise la métrica compute.googleapis.com/instance/uptime. Creas y configuras la condición para generar un incidente cuando no hay datos de métricas. No defines la condición mediante el lenguaje de consulta de Monitoring (MQL)1. No se le notifica cuando la máquina virtual (VM) se reinicia o se apaga.

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 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étricas para determinar si se está ejecutando una instancia de VM. Para obtener información sobre los estados de las instancias de VM, consulta Ciclo de vida de la instancia de VM.

A fin de resolver este problema, crea una política de alertas para supervisar una verificación de tiempo de actividad. Para crear una verificación de tiempo de actividad, tu VM debe tener una dirección IP externa.

Si tu VM no tiene una dirección IP externa, puedes crear una política de alertas con MQL que te notifique que la VM se cerró. Las condiciones definidas por MQL no filtran de manera previa los datos de series temporales según el estado de la instancia de VM. Debido a que MQL no filtra los datos por estados de VM, puedes usarlo para detectar la ausencia de datos de 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 se cierra una VM que supervisa esta condición, tres minutos después, 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.

1: MQL es un lenguaje basado en texto expresivo que se puede usar con las llamadas a la API de Cloud Monitoring y en Google Cloud Console. Para configurar una condición con MQL cuando usas Cloud Console, debes seleccionar 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 notificaciones de incidentes que parecen ser incorrectos:

  • Si hay una brecha en los datos, especialmente para las políticas de alertas con condiciones de ausencia de métricas o del umbral “menor que”, entonces se puede crear un incidente que parezca anómalo. Determinar si existe una brecha en los datos podría no ser fácil. En ocasiones, la brecha se oculta y, a veces, se corrige de forma automática:

    • En los gráficos, por ejemplo, las brechas pueden estar ocultas 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 la continuidad visual. Este intervalo en los datos subyacentes podría 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 10 minutos antes. El comportamiento de reabastecimiento corrige de forma efectiva la brecha. la brecha se rellena cuando finalmente llegan los datos. Por lo tanto, una interrupción en una métrica basada en registros que ya no se puede ver puede haber provocado una política de alertas para crear un incidente.

  • Las condiciones de ausencia de métricas y del umbral "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 está visible en Monitoring.

  • Las condiciones configuradas para crear un incidente en una sola medida pueden generar incidentes que parecen ser prematuros o incorrectos. A fin de evitar esta situación, asegúrate de que se requieran varias medidas antes de crear un incidente mediante la configuración del campo de duración de una condición para que sea 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 3 minutos como mínimo. Si estableces el campo de duración en el valor más reciente, o de forma equivalente a 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 tardar varios minutos en propagarse a través de la infraestructura de alertas. Durante este período, puedes recibir notificaciones de los incidentes que cumplieron las condiciones de la política de alertas original.

La política de condiciones múltiples 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 tener un incidente creado cuando se cumplan todas las condiciones. Sin embargo, recibes varias notificaciones y ves que se crearon varios incidentes.

Cuando una política de alertas contiene varias condiciones unidas por una AND lógica, si esa política se activa, para cada serie temporal que genere el cumplimiento de una condición, la política envía una notificación y crea. 101}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 única 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 permisos

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

Para resolver esta situación, asegúrate de que la función de administración de identidades y accesos (IAM) sea roles/monitoring.viewer o una 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 los permisos necesarios para ver los detalles del incidente.

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 el incidente se cierre. Sin embargo, recibirá el siguiente mensaje de error:

Unable to close incident with active conditions.

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

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

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

Cuando veas el mensaje de error anterior, puedes reintentar 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.

Las notificaciones de webhook fallan

Configura un canal de notificaciones de webhook y espera que se le notifique cuando ocurran incidentes. No recibes 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 administración de identidades y accesos. Cualquier servicio que pueda consultar o escuchar un tema de Pub/Sub puede consumir estas notificaciones. Por ejemplo, las aplicaciones que se ejecutan en App Engine, Cloud Run o las máquinas virtuales de 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 para los firewalls ni el 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 fallas.

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

resource.type="stackdriver_notification_channel"