En esta página, se explica por qué algunas políticas de alertas podrían comportarse de manera diferente de lo previsto y ofrece posibles soluciones para esas situaciones.
Para obtener información sobre las variables que pueden afectar una política de alertas, 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 los sitios capacidad 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,
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 un disco virtual se construye de modo que es del 100%, se produciría un incidente para el que se creará.
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 ...
Para 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, podrías
agrega 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 incidentes anómalos
Creaste una política de alertas, y la política parece o crear incidentes de forma incorrecta.
Existen diferentes motivos por los que podrías recibir notificaciones de incidentes que parecen ser incorrectos:
Si hay un vacío en los datos, en especial para aquellas políticas de alertas con de ausencia de métrica o “inferior a”, un y se puede crear un incidente que parezca anómalo. Algunas veces, el incidente no muestra la brecha de datos 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 se almacenan varios minutos de datos falta, el gráfico conecta los puntos faltantes para mantener la continuidad visual. Tales un intervalo en los datos subyacentes puede ser suficiente para que una política de alertas crear un incidente.
Los puntos de las métricas basadas en registros pueden llegar tarde y reabastecerse. durante un máximo de 10 minutos. El comportamiento del reabastecimiento de forma eficaz corrige la brecha; la brecha se llena cuando los datos finalmente llegan. Por lo tanto, un vacío en una métrica basada en registros que ya no se puede ver podría tener causaron 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.
Condiciones configuradas para crear un incidente en una sola medición puede dar lugar a incidentes que parecen ser prematuros o incorrectos. Para evitar esta situación, asegurarse de que se requieran múltiples mediciones antes de El incidente se crea mediante la configuración de la ventana para volver a probar de una condición. sea superior al doble de la tasa de muestreo de la métrica.
Por ejemplo, si una métrica se muestrea cada 60 segundos y, luego, establece el período para volver a probar en 3 minutos como mínimo. Si estableces el período para volver a probar el valor más reciente, o el equivalente a 0 segundos una sola medición puede generar un incidente.
Cuando se edita la condición de una política de alertas, puede tardar minutos para que el cambio se propague a través de la infraestructura de alertas. Durante este período, es posible que recibas notificaciones de incidentes que cumpla con las condiciones originales de la política de alertas.
Cuando llegan los datos de series temporales, pueden pasar hasta un minuto se propaguen a través de toda la infraestructura de alertas. Durante este proceso, una política de alertas puede evaluar una condición como si se cumple incluso aunque los datos de las series temporales no se propagaron 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 los 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 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, Monitoring puede determinar el estado
del recurso. Si se sabe que el estado de un recurso está inhabilitado, entonces
La supervisión no cierra los incidentes automáticamente cuando los datos
paradas. 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. Esperas tener abierta la página de detalles. 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 del incidente.
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 llegó la cantidad máxima de incidentes que se puede abrir de forma simultánea.
Se sabe que el estado del recurso que supervisa la política de alertas inhabilitado. La supervisión puede determinar el estado de un recurso cuando este contiene
metadata.system_labels.statey cuando la política de alertas no esté escritas 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 las condiciones proyecto de Google Cloud en el que se creó el incidente, es decir, enumera los proyecto de permisos. Sin embargo, esperas que el incidente incluya el nombre del un proyecto de Google Cloud que almacena las series temporales Monitoring para crear el incidente.
Las opciones de agregación especificadas en la condición de una política de alertas Determinar 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 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 las series temporales que causan el incidente. Para conservar la etiqueta del ID del proyecto, incluye el etiqueta
project_iden el campo de agrupación, o bien no agrupe las series temporales.
No se pudo 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 el incidente estar cerrado; Sin embargo, recibirás 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 se pueden 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 la operación de cierre. 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, puedes recibir una notificación y un incidente para cada serie temporal que causa que se unieron las condiciones que se deben cumplir.
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 (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 envía 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
agregar 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 el etiqueta que quieres mostrar.
Por ejemplo, imagina que creas una política de alertas que supervisa bytes de disco escritos por instancias de VM. Quieres que la documentación enumere el dispositivo que provoca la notificación, así que debes agregar el siguiente campo:
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 función de agregación anoneo garantizando que las selecciones de incluyendevice.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, solo se admite la variable
log.extracted_label.KEYpara 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
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 que reflejan el cambio que realizaste en la definición de la métrica.
Para resolver este problema, fuerza la actualización de la política de alertas editando el el nombre visible de la política.