En esta página se explica por qué algunas políticas de alertas pueden comportarse de forma diferente a la prevista y se ofrecen posibles soluciones para esas situaciones.
Para obtener información sobre las variables que pueden afectar a una política de alertas, como la elección de la ventana de repetición de pruebas, consulta Comportamiento de las políticas de alertas basadas en métricas.
La política de utilización del disco crea incidentes inesperados
Has creado una política de alertas para monitorizar la capacidad "usada" de los discos de tu sistema. Esta política monitoriza la métrica agent.googleapis.com/disk/percent_used.
Solo quieres recibir una notificación cuando el uso de un disco físico supere el umbral que has definido en la condición. Sin embargo, esta política está creando incidencias cuando la utilización del disco de cada disco físico es inferior al umbral.
Una causa conocida de incidentes inesperados en estas políticas es que las condiciones no se limitan a la monitorización de discos físicos. En su lugar, estas políticas monitorizan todos los discos, incluidos los virtuales, como los dispositivos de bucle de retorno. Si se crea un disco virtual de forma que su utilización sea del 100%, se producirá un incidente para que se cree 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 montados de 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 utilización del disco para filtrar las series temporales de los dispositivos de bucle de retorno /dev/loop0 y /dev/loop1. Por ejemplo, puede añadir el filtro device !=~ ^/dev/loop.*, que excluye todas las series temporales cuyo valor de device no coincida con la expresión regular ^/dev/loop.*.
Causas habituales de los incidentes anómalos
Has creado una política de alertas y parece que crea incidentes de forma prematura o incorrecta.
Hay varios motivos por los que puede que recibas notificaciones de incidentes que parecen incorrectas:
Si hay un vacío en los datos, sobre todo en las 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 falta de datos y, en otras ocasiones, se corrige automáticamente:
Por ejemplo, en los gráficos, es posible que no aparezcan huecos porque los valores de los datos que faltan se interpolan. Aunque falten varios minutos de datos, el gráfico conecta los puntos que faltan para que la visualización sea continua. Esta laguna 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 rellenarse con datos anteriores, hasta 10 minutos después. El comportamiento de relleno corrige la falta de datos, que se completa cuando llegan los datos. Por lo tanto, una laguna 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 umbral de ausencia de métricas y "menor que" se evalúan en tiempo real, con un pequeño retraso en la 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 se muestra en Monitoring.
Las condiciones configuradas para crear un incidente en una sola medida pueden dar lugar a incidentes que parezcan prematuros o incorrectos. Para evitar esta situación, compruebe que se requieren varias mediciones antes de que se cree un incidente. Para ello, defina la ventana de repetición de pruebas de una condición de forma que sea más del doble de la frecuencia de muestreo de la métrica.
Por ejemplo, si una métrica se muestrea cada 60 segundos, define la ventana de repetición de la prueba en al menos 3 minutos. Si asignas el valor Valor más reciente a la ventana de repetición de pruebas o, lo que es lo mismo, 0 segundos, una sola medición puede provocar 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 por la infraestructura de alertas. Durante este periodo, es posible que recibas notificaciones de incidentes que cumplan las condiciones de la política de alertas original.
Cuando llegan los datos de serie temporal, pueden tardar hasta un minuto en propagarse por toda la infraestructura de alertas. Durante este proceso, una política de alertas puede evaluar que se cumple una condición aunque los datos de la serie temporal no se hayan propagado al gráfico de la serie temporal. Por lo tanto, es posible que recibas una notificación aunque el gráfico no indique que se cumple la condición. Para reducir la posibilidad de que se produzca esta situación, usa un periodo de alineación de al menos cinco minutos.
El cambio de nombre de la etiqueta del centro de aplicaciones
metadata.system_labels.apphub_host_project_idametadata.system_labels.apphub_application_containerpuede provocar que se generen algunos incidentes nuevos y que algunos incidentes abiertos no se cierren.No tienes que hacer nada. Las alertas se cierran automáticamente cuando dejan de llegar datos, una vez que ha transcurrido el periodo de cierre automático. Para obtener más información, consulta Datos de métricas parciales.
El incidente no se cierra cuando dejan de llegar datos
Sigue las instrucciones de la sección Datos de métricas parciales y configura una política de alertas para cerrar los incidentes cuando dejen de llegar datos. En algunos casos, los datos dejan de llegar, pero el incidente abierto no se cierra automáticamente.
Si el recurso subyacente monitorizado por una política de alertas contiene la etiqueta metadata.system_labels.state y esa política no se ha escrito con el lenguaje de consulta de Monitoring, Monitoring puede determinar el estado del recurso. Si se sabe que el estado de un recurso es inhabilitado, Monitoring no cierra automáticamente los incidentes cuando dejan de llegar datos. Sin embargo, puedes cerrar estos incidentes manualmente.
No se pueden ver los detalles del incidente debido a un error de permisos
Ve a la página de incidentes de la Google Cloud consola y selecciona un incidente para verlo. 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 ver todos los detalles de un incidente, excepto los datos de métricas, comprueba que tengas los roles de Gestión de Identidades y Accesos (IAM) de lector de incidentes de la consola de Cloud Monitoring (roles/monitoring.cloudConsoleIncidentViewer) y lector de cuentas de Stackdriver (roles/stackdriver.accounts.viewer).
Para ver todos los detalles de los incidentes, incluidos los datos de métricas, y poder confirmar o cerrar incidentes, compruebe que tiene los roles de gestión de identidades y accesos de lector de Monitoring (roles/monitoring.viewer) y editor de incidentes de la consola de Cloud Monitoring (roles/monitoring.cloudConsoleIncidentEditor).
Los roles personalizados no pueden conceder el permiso necesario para ver los detalles de las incidencias.
No se crea ningún incidente cuando se cumple la condición
Has creado una política de alertas con una condición. El gráfico de la política de alertas muestra que los datos monitorizados infringen la condición, pero no has recibido ninguna notificación y no se ha creado ningún incidente.
Si se cumple alguno de los siguientes criterios después de que se cumpla 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 ha alcanzado el número máximo de incidentes que puede abrir simultáneamente.
Se sabe que el estado del recurso que monitoriza la política de alertas está inhabilitado. La monitorización puede determinar el estado de un recurso cuando este contiene la etiqueta
metadata.system_labels.statey cuando la política de alertas no se escribe con Monitoring Query Language.
La lista de detalles del incidente muestra un proyecto incorrecto
Recibes una notificación y el resumen de la condición muestra elGoogle Cloud proyecto en el que se ha creado el incidente, es decir, el proyecto de ámbito. Sin embargo, esperas que el incidente muestre el nombre del proyecto Google Cloud que almacena la serie temporal que ha provocado que Monitoring cree el incidente.
Las opciones de agregación especificadas en la condición de una política de alertas determinan el Google Cloud proyecto 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 ámbito. Por ejemplo, si agrupa los datos solo por zona, después de agruparlos, se quitará 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 incidentes incluyen el nombre del Google Cloud proyecto que almacena la serie temporal que provoca el incidente. Para conservar la etiqueta del ID de proyecto, incluya la etiqueta
project_iden el campo de agrupación o no agrupe las series temporales.
No se puede cerrar un incidente manualmente
Has recibido 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 se reciban observaciones en el periodo de alerta más reciente. El periodo 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 han recibido datos en el periodo de alerta.
Se produce el siguiente error 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 cerrar la operación o dejar que Monitoring cierre el incidente automáticamente.
Para obtener más información, consulta Gestionar incidencias.
Una política con varias condiciones crea varias notificaciones
Has creado una política de alertas que contiene varias condiciones y las has unido con el operador lógico AND. 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 han creado varios incidentes.
Monitoring envía una notificación y crea un incidente por cada serie temporal que provoque que se cumpla una condición. Por lo tanto, si tienes políticas de alertas con varias condiciones, es posible que recibas una notificación y un incidente por cada serie temporal que provoque que se cumplan las condiciones combinadas.
Por ejemplo, supongamos que tiene una política de alertas con dos condiciones, donde cada condición monitoriza 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ás recibir entre 2 (se cumple una serie temporal en cada condición) y 6 (se cumplen todas las series temporales en cada condición) notificaciones e incidencias.
No puedes configurar Monitoring para que cree un solo incidente y envíe una sola notificación.
Para obtener más información, consulta Notificaciones por incidencia.
La variable de una etiqueta de métrica es nula
Crea una política de alertas y añade 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, pero el valor es null.
Para solucionar este problema, prueba lo siguiente:
Verifica que los ajustes de agregación de la política de alertas conserven la etiqueta que quieres mostrar.
Por ejemplo, supongamos que creas una política de alertas que monitoriza los bytes de disco escritos por las instancias de VM. Quieres que la documentación muestre el dispositivo que está provocando la notificación, por lo que añades al campo de documentación lo siguiente:
device: ${metric.label.device}.También debe verificar que la configuración de agregación conserve el valor de la etiqueta
device. Para conservar esta etiqueta, puedes definir la función de agregación comononeo verificar que las selecciones de agrupación incluyandevice.Verifica la sintaxis y la aplicabilidad de la variable. Para obtener información sobre la sintaxis, consulta Anotar notificaciones con documentación definida por el usuario.
Por ejemplo, la variable
log.extracted_label.KEYsolo se admite en las políticas de alertas basadas en registros. Esta variable siempre se representa comonullcuando una política de alertas monitoriza una métrica, incluso una métrica basada en registros.
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, modificando el filtro que has usado en una métrica basada en registros, y la política de alertas no refleja el cambio que has hecho en la definición de la métrica.
Para solucionar este problema, fuerza la actualización de la política de alertas editando el nombre visible de la política.
No se puede crear una política de alertas en la API porque falta una métrica
Hace poco creaste una métrica y, después, hiciste referencia a ella cuando intentaste crear una política de alertas en la API Cloud Monitoring. Sin embargo, el comando de la API falla y muestra el siguiente error:
Error 404: Cannot find metric(s) that match type = "METRIC_NAME". If a metric was created recently, it could take up to 10 minutes to become available. Please try again soon.
Para solucionar este problema, espere al menos diez minutos y vuelva a enviar la solicitud de la API.
El gráfico de la política de alertas no muestra la infracción del umbral
Has recibido una notificación de que se ha abierto un incidente en tu política de alertas. Sin embargo, cuando accede a la página de detalles de la política, el gráfico no indica que se haya superado el umbral.
Para resolver esta situación, prueba a acortar el periodo del gráfico. Puedes acortar el periodo con el selector de periodo de la barra de herramientas o resaltando los periodos en el gráfico con el puntero.
Los gráficos tienen una resolución limitada y es posible que no muestren todas las mediciones de algunos periodos.