Soluciona 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, a través de la elección del período de nueva prueba, 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 los sitios capacidad 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 estableciste en la condición. Sin embargo, este de seguridad crea incidentes cuando el uso de disco 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 supervisar discos físicos. En su lugar, estas políticas supervisan todos los discos, incluidos los virtuales, como los siguientes: de bucle invertido. Si se construye un disco virtual de modo que su uso sea del 100%, se creará un incidente para la política.

Por ejemplo, considera el siguiente resultado del comando df de Linux: que muestra el espacio en disco disponible en sistemas de archivos activados, por ejemplo, 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 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.*.

Causas comunes de los incidentes anómalos

Creaste una política de alertas y, al parecer, esta crea 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, en especial para aquellas políticas de alertas con condiciones de límite de ausencia de métrica o “menor que”, se puede crear un incidente que parezca anómalo. A veces, el incidente no muestra la brecha de datos y, a veces, esta se corrige automáticamente:

  • En los gráficos, por ejemplo, es posible que las brechas no aparezcan porque los valores de se interpolan los datos que faltan. Incluso cuando faltan varios minutos de datos, el gráfico conecta los puntos que faltan 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 datos de las métricas basadas en registros pueden llegar tarde y reabastecerse, hasta 10 minutos antes. El comportamiento de reabastecimiento corrige de forma eficaz el intervalo 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 se configuran para crear un incidente en una sola medida pueden generar incidentes que parecen ser prematuros o incorrectos. Para evitar esta situación, asegúrate de que se requieran varias mediciones antes de que se cree un incidente. Para ello, establece la ventana de nueva prueba de una condición para que sea más del doble de la tasa de muestreo de la métrica.

  Por ejemplo, si se toma una muestra de una métrica cada 60 segundos, establece el período de nueva prueba en, al menos, 3 minutos. Si configuras el período de nueva prueba en el valor más reciente o, de manera equivalente, en 0 segundos, una sola medición puede provocar 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, es posible que recibas notificaciones de incidentes que cumplan con las condiciones de la política de alertas original.

• Cuando llegan los datos de las series temporales, estos pueden tardar hasta un minuto en propagarse por toda la infraestructura de alertas. Durante este proceso, una política de alertas podría evaluar que se cumple una condición, aunque los datos de las series temporales no se hayan propagado al gráfico de series temporales. Como resultado, es posible que recibas una notificación aunque el gráfico no indican que la condición se cumple. Para reducir la posibilidad de esta situación, usa un período de alineación de al menos cinco minutos.

El incidente no se cierra cuando dejan de llegar datos

Sigues las instrucciones de Datos parciales de la métrica y configurar una política de alertas para cerrar incidentes cuando los datos dejen de llegar. En algunos casos, los datos dejan de llegar, pero no hay un incidente abierto cerrado automáticamente.

Si el recurso subyacente que supervisa 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 supervisión, la supervisión puede determinar el estado del recurso. Si se sabe que el estado de un recurso está inhabilitado, Monitoring no cierra automáticamente los incidentes cuando dejan de llegar datos. Sin embargo, puedes cerrar estos incidentes de forma manual.

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

Navegarás a la página Incidentes en la consola de Google Cloud y seleccionarás incidente para ver. Se espera que la página de detalles esté abierta. Sin embargo, no se abre la página de detalles y aparece el mensaje "Permiso denegado" hasta que se muestre un mensaje.

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

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

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

No se crea el incidente cuando se cumple la condición

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

Si se cumple alguno de los siguientes criterios después de la condición de la política de alertas esto significa que Monitoring no abre 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. La supervisión puede determinar el estado de un recurso cuando este contiene metadata.system_labels.state y cuando la política de alertas no esté escritas con el lenguaje de consulta de Monitoring.

La lista de detalles del incidente muestra el proyecto incorrecto

Recibirás una notificación y, en el resumen de la condición, se mostrará el proyecto de Google Cloud en el que se creó el incidente, es decir, el proyecto de delimitación. Sin embargo, esperas que el incidente muestre el nombre del proyecto de Google Cloud que almacena las series temporales que provocaron que Monitoring creara 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 alcance. Por ejemplo, si agrupas los datos solo por zona, después de agruparlos, etiqueta que almacena el ID del proyecto.

• Cuando las opciones de agregación preservan 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 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. Accede a la página y haga clic en Cerrar incidente. Esperas que se cierre el incidente. Sin embargo, recibes el siguiente 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 más reciente durante el período de alerta. 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 han sido recibidos dentro del período de alerta.

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

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

Cuando veas el mensaje de error anterior, puedes volver a intentar cerrarlo. y permite que Monitoring cierre el incidente automáticamente.

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

La política de varias condiciones crea varias notificaciones

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

Monitoring envía una notificación y crea un incidente de cada serie temporal que provoca 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 las 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 (se cumple una serie temporal en cada condición) y 6 incidentes y notificaciones (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.

La variable de una etiqueta de métrica es nula

Creas una política de alertas y agregas una variable para una etiqueta de métrica a la sección de documentación. Esperas que las notificaciones muestren el valor de la variable; Sin embargo, el valor se establece en null.

Para resolver esta situación, realiza las siguientes acciones:

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

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

  También debes asegurarte de que tu configuración de agregación conserve el valor de la etiqueta device. Puedes conservar esta etiqueta estableciendo la función de agregación a none o garantizando que las selecciones de incluyen device.

• Verifica la sintaxis y la aplicabilidad de la variable. Para obtener información sobre la sintaxis, consulta Cómo anotar notificaciones con documentación definida por el usuario.

  Por ejemplo, la variable log.extracted_label.KEY solo se admite para las políticas de 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.

No hay datos nuevos después de los cambios en las definiciones de las métricas

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

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