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, según la opción del período para volver a probar, por ejemplo, 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 que se te notifique solo cuando el uso de cualquier disco físico supere el umbral que estableciste en la condición. Sin embargo, esta política crea incidentes cuando el uso de 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 supervisar discos físicos. En su lugar, estas políticas supervisan todos los discos, incluidos los discos virtuales, como los dispositivos de bucle invertido. Si un disco virtual se construye de modo que su uso sea del 100%, eso provocaría un incidente para que se cree la política.
Por ejemplo, considera el siguiente resultado del comando df de Linux, que muestra el espacio en el disco disponible en 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 ...
Para este sistema, se debe configurar una política de alertas de uso del disco a fin de 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 cuyas etiqueta device no coincide con la expresión regular ^/dev/loop.*.
Causas comunes de incidentes anómalos
Creaste una política de alertas y la política parece crear incidentes de manera prematura o incorrecta.
Existen diferentes motivos por los que puedes 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 umbral de ausencia de métricas o “inferior a”, se puede crear un incidente que parezca anómalo. A veces, el incidente no muestra la brecha de datos y, otras veces, la brecha de datos se corrige de forma automática:
En los gráficos, por ejemplo, es posible que no aparezcan los espacios vacíos porque los valores de los datos faltantes se interpolan. Incluso cuando faltan varios minutos de datos, el gráfico conecta puntos faltantes para 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 del reabastecimiento corrige de forma eficaz la brecha que 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 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 que están configuradas para crear un incidente en una sola medición pueden generar incidentes que parezcan 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, configura la ventana de repetición de la prueba de una condición para que sea superior al doble de la tasa de muestreo de la métrica.
Por ejemplo, si una métrica se muestrea cada 60 segundos, establece el período para volver a probar en al menos 3 minutos. Si configuras el período para volver a probar el valor más reciente, o de forma equivalente a 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 originales de la política de alertas.
Cuando llegan los datos de series temporales, pueden tardar hasta un minuto en propagarse a través de toda la infraestructura de alerta. Durante este proceso, una política de alertas puede evaluar que una condición se cumple, aunque los datos de la serie temporal no se hayan propagado al gráfico de serie temporal. Como resultado, es posible que recibas una notificación aunque el gráfico no indique que se cumpla la condición. 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 los datos
Sigue las instrucciones en Datos de métricas parciales y configura una política de alertas para cerrar 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 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 Monitoring, 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.
No se pueden ver los detalles del incidente debido a un error de permiso
Navega a la página de incidentes en la consola de Google Cloud y selecciona un incidente para 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 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 Supervisar el visualizador de incidentes de Cloud Console (roles/monitoring.cloudConsoleIncidentViewer) y el visualizador de cuentas de Stackdriver (roles/stackdriver.accounts.viewer).
Para ver todos los detalles del incidente, incluidos los datos de la métrica, 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 del incidente.
No se crea el incidente cuando se cumple la condición
Creaste una política de alertas que tiene una condición. En el gráfico de la política de alertas, se muestra que los datos supervisados infringen la condición, pero no recibiste una notificación ni 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.statey cuando la política de alertas no está escrita con el lenguaje de consulta de Monitoring.
Se muestra el proyecto incorrecto en los detalles del incidente
Recibes 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 muestre el nombre del proyecto de Google Cloud que almacena las series temporales que hicieron 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 enumera el proyecto de permisos. Por ejemplo, si agrupas los datos solo por zona, después de agrupar, 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 del 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_iden el campo de agrupación o no agrupes las series temporales.
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 el incidente se cierre, pero recibes 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 los datos se recibieron 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 reintentar la operación de cierre o dejar que Monitoring cierre de forma automática el incidente.
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 las uniste con un AND lógico. Esperas recibir una notificación y que se cree un incidente cuando se cumplan todas las condiciones. Sin embargo, recibes varias notificaciones y ves que se crean varios incidentes.
Monitoring envía una notificación y crea un incidente para 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 para cada serie temporal que provoque 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 cumplan las condiciones de tu política, podrías recibir entre 2 (se cumple una serie temporal en cada condición) y 6 (todas las series temporales se cumplen en cada condición) incidentes y notificaciones.
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 para 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 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 conservar esta etiqueta, configura la función de agregación comononeo asegúrate de que las selecciones de agrupación incluyandevice.Verifica la sintaxis y la aplicabilidad de la variable. Para obtener información sobre la sintaxis, consulta Anota las notificaciones con la documentación definida por el usuario.
Por ejemplo, la variable
log.extracted_label.KEYsolo es compatible con políticas de alertas basadas en registros. Esta variable siempre se renderiza comonullcuando 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
Puedes cambiar 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 hiciste en la definición de la métrica.
Para resolver este problema, edita el nombre visible de la política de alertas para forzar su actualización.