Una política de alertas se representa en la API de Cloud Monitoring con un objeto AlertPolicy
, que describe un conjunto de condiciones que indican un estado potencialmente en mal estado en tu sistema.
En este documento, se describe lo siguiente:
- Cómo representa la API de Monitoring las políticas de alertas
- Los tipos de condiciones que proporciona la API de Monitoring para las políticas de alertas
- Cómo crear una política de alertas con Google Cloud CLI o bibliotecas cliente
Estructura de una política de alertas
La estructura AlertPolicy
define los componentes de una política de alertas. Cuando creas una política, debes especificar valores para los siguientes campos AlertPolicy
:
displayName
: Es una etiqueta descriptiva para la política.documentation
: Te recomendamos que uses este campo para proporcionar información que ayude a los equipos de respuesta a incidentes. Para obtener más información, consulta Cómo anotar notificaciones con documentación definida por el usuario.userLabels
: Cualquier etiqueta definida por el usuario adjunta a la política. Para obtener información sobre el uso de etiquetas con alertas, consulta Cómo anotar incidentes con etiquetas.conditions[]
: Es un array de estructurasCondition
.combiner
: Es un operador lógico que determina cómo controlar varias condiciones.notificationChannels[]
: Es un array de nombres de recursos, cada uno de los cuales identifica unNotificationChannel
.alertStrategy
: Especifica lo siguiente:- La rapidez con la que Monitoring cierra los incidentes cuando dejan de llegar datos
- En el caso de las políticas de alertas basadas en métricas, si Monitoring envía una notificación cuando se cierra un incidente.
- Para las políticas de alertas basadas en métricas, si están habilitadas las notificaciones repetidas y el intervalo entre ellas. Para obtener más información, consulta Configura notificaciones repetidas para políticas de alertas basadas en métricas.
También puedes especificar el campo severity
cuando usas la API de Cloud Monitoring
y la consola de Google Cloud. Este campo te permite definir el nivel de gravedad de los incidentes. Si no especificas una gravedad,
Cloud Monitoring establece la gravedad de la política de alertas en No Severity
.
Existen otros campos que puedes usar, según las condiciones que crees.
Cuando una política de alertas contiene una condición, se envía una notificación cuando se cumple esa condición. Para obtener información sobre las notificaciones cuando las políticas de alertas contienen varias condiciones, consulta Políticas con varias condiciones y Cantidad de notificaciones por política.
Cuando creas o modificas la política de alertas, Monitoring también configura otros campos, incluido el campo name
. El valor del campo name
es el nombre del recurso de la política de alertas, que la identifica. El nombre del recurso tiene el siguiente formato:
projects/PROJECT_ID/alertPolicies/POLICY_ID
Tipos de condiciones en la API
La API de Cloud Monitoring admite una variedad de tipos de condiciones en la estructura Condition
. Existen varios tipos de condiciones para las políticas de alertas basadas en métricas y uno para las políticas de alertas basadas en registros. En las siguientes secciones, se describen los tipos de condiciones disponibles.
Condiciones para las políticas de alertas basadas en métricas
Para crear una política de alertas que supervise los datos de métricas, incluidas las métricasbasadas en registros, puedes usar los siguientes tipos de condiciones:
Condiciones de métricas basadas en filtros
Las condiciones MetricAbsence
y MetricThreshold
usan filtros de supervisión para seleccionar los datos de series temporales que se supervisarán. Otros campos de la estructura de la condición especifican cómo filtrar, agrupar y agregar los datos. Para obtener más información sobre estos conceptos, consulta Filtrado y agregación: manipula series temporales.
Si usas el tipo de condición MetricAbsence
, puedes crear una condición que se cumpla solo cuando no exista ninguna de las series temporales. Esta condición usa el parámetro aggregations
para agregar varias series temporales en una sola. Para obtener más información, consulta la referencia de MetricAbsence
en la documentación de la API.
Una política de alertas de ausencia de métricas requiere que se hayan escrito algunos datos previamente. Para obtener más información, consulta Crea políticas de alertas de ausencia de métricas.
Si deseas recibir notificaciones en función de un valor previsto, configura
tu política de alertas para que use el
tipo de condición MetricThreshold
y establezca el campo forecastOptions
. Cuando no se configura este campo, los datos medidos se comparan con un umbral.
Sin embargo, cuando se configura este campo, los datos previstos se comparan con un umbral. Para obtener más información, consulta Crea políticas de alertas de valores de métricas previstos.
Condiciones de métricas basadas en MQL
La condición MonitoringQueryLanguageCondition
usa el lenguaje de consulta de Monitoring (MQL) para seleccionar y manipular los datos de series temporales que se supervisarán. Puedes crear políticas de alertas que comparen valores con un umbral o prueben la ausencia de valores con este tipo de condición.
Si usas una condición MonitoringQueryLanguageCondition
, esta debe ser la única condición en tu política de alertas. Para obtener más información, consulta Políticas de alertas con MQL.
Condiciones de métricas basadas en PromQL
La condición PrometheusQueryLanguageCondition
usa consultas del lenguaje de consulta de Prometheus (PromQL) para seleccionar y manipular los datos de series temporales que se supervisarán.
Tu condición puede calcular una proporción de métricas,
evaluar comparaciones de métricas y mucho más.
Si usas una condición PrometheusQueryLanguageCondition
, esta debe ser la única condición en tu política de alertas. Para obtener más información, consulta Políticas de alertas con PromQL.
Condiciones para alertar sobre proporciones
Puedes crear políticas de alertas de límite de métrica para supervisar la proporción de dos métricas. Puedes crear estas políticas con el tipo de condición MetricThreshold
o MonitoringQueryLanguageCondition
.
También puedes usar MQL directamente en la consola de Google Cloud. No puedes crear ni administrar condiciones basadas en la proporción con la interfaz gráfica para crear condiciones de umbral.
Te recomendamos que uses MQL para crear políticas de alertas basadas en proporciones.
MQL te permite compilar consultas más potentes y flexibles que con el tipo de condición MetricTheshold
y los filtros de Monitoring.
Por ejemplo, con una condición MonitoringQueryLanguageCondition
, puedes calcular la proporción de una métrica de indicador a una métrica delta. Para ver ejemplos, consulta los ejemplos de políticas de alertas de MQL.
Si usas la condición MetricThreshold
, el numerador y el denominador de la proporción deben tener el mismo MetricKind
.
Para obtener una lista de métricas y sus propiedades, consulta Listas de métricas.
En general, es mejor calcular las proporciones según las series temporales recopiladas para un solo tipo de métrica mediante el uso de valores de etiquetas. Una proporción calculada en dos tipos de métricas diferentes está sujeta a anomalías debido a los diferentes períodos de muestreo y ventanas de alineación.
Por ejemplo, supongamos que tienes dos tipos de métricas, un recuento total de RPC y un recuento de errores de RPC, y deseas calcular la proporción de las RPC del recuento de errores sobre el total de RPC. Las RPC con errores se cuentan en las series temporales de ambos tipos de métricas. Por lo tanto, existe la posibilidad de que, cuando alinees las series temporales, una RPC con errores no aparezca en el mismo intervalo de alineación para ambas series temporales. Esta diferencia puede ocurrir por varias razones, incluidas las siguientes:
- Debido a que hay dos series temporales diferentes que registran el mismo evento, hay dos valores de contador subyacentes que implementan la colección y no se actualizan de manera atómica.
- Las tasas de muestreo pueden variar. Cuando las series temporales están alineadas a un período común, los recuentos de un solo evento pueden aparecer en intervalos de alineación adyacentes en la serie temporal para las diferentes métricas.
La diferencia en la cantidad de valores en los intervalos de alineación correspondientes puede generar valores de proporción error/total
sin sentido, como 1/0 o 2/1.
Es menos probable que las proporciones de números más grandes generen valores sin sentido. Puedes obtener números más grandes por agregación, ya sea mediante una ventana de alineación más larga que el período de muestreo o mediante la agrupación de datos para ciertas etiquetas. Estas técnicas minimizan el efecto de las pequeñas diferencias en la cantidad de puntos en un intervalo determinado. Es decir, una diferencia de dos puntos es más significativa cuando la cantidad de puntos esperados en un intervalo es 3 que cuando la cantidad esperada es 300.
Si usas tipos de métricas integradas, es posible que no tengas más opción que calcular las proporciones entre los tipos de métricas para obtener el valor que necesitas.
Si diseñas métricas personalizadas que pueden contar lo mismo, como las RPC que muestran el estado del error, en dos métricas diferentes, considera una sola métrica, que incluye cada recuento solo una vez. Por ejemplo, supongamos que estás contando RPC y deseas realizar un seguimiento de la proporción de RPC fallidas en todas las RPC. Para resolver este problema, crea un tipo de métrica único para contar las RPC y usa una etiqueta para registrar el estado de la invocación, incluido el estado “Correcto”. Luego, cada valor de estado, error o “Correcto” se registra mediante la actualización de un solo contador para ese caso.
Condición para las políticas de alertas basadas en registros
Para crear una política de alertas basada en registros, que te notifique cuando aparezca un mensaje
que coincida con tu filtro en tus entradas de registro, usa el
tipo de condición LogMatch
. Si usas una condición LogMatch
, esta debe ser la única condición en tu política de alertas.
No intentes usar el tipo de condición LogMatch
junto con las métricasbasadas en registros. Las políticas de alertas que supervisan las métricas basadas en registros son políticasbasadas en métricas. Para obtener más información sobre cómo elegir entre políticas de alertas que supervisen métricas o entradas de registro basadas en registros, consulta Supervisa tus registros.
Las políticas de alertas que se usan en los ejemplos del documento Cómo administrar políticas de alertas a través de la API son políticas de alertas basadas en métricas, aunque los principios son los mismos para las políticas de alertas basadas en registros. Para obtener información específica sobre las políticas de alertas basadas en registros, consulta Crea una política de alertas basada en registros con la API de Monitoring en la documentación de Cloud Logging.
Antes de comenzar
Antes de escribir el código en la API, debes cumplir con lo siguiente:
- Familiarizarte con los conceptos generales y la terminología usada con las políticas de alertas; consulta Descripción general de alertas para obtener más información
- Asegúrate de que la API de Cloud Monitoring esté habilitada para su uso. Consulta Cómo habilitar la API para obtener más información.
- Si planeas usar bibliotecas cliente, instala las bibliotecas de los lenguajes que quieres usar. Consulta Bibliotecas cliente para obtener más información. Actualmente, la asistencia de la API para alertas está disponible solo para C#, Go, Java, Node.js y Python.
Si planeas usar Google Cloud CLI, instálala. Sin embargo, si usas Cloud Shell, Google Cloud CLI ya está instalada.
También se proporcionan aquí los ejemplos que usan la interfaz de
gcloud
. Ten en cuenta que en los ejemplos degcloud
se da por sentado que el proyecto actual ya se estableció como el objetivo (gcloud config set project [PROJECT_ID]
), por lo que las invocaciones omiten la marca--project
explícita. El ID del proyecto actual en los ejemplos esa-gcp-project
.
-
Para obtener los permisos que necesitas para crear y modificar políticas de alertas con la API de Cloud Monitoring, pídele a tu administrador que te otorgue el rol de IAM de editor de AlertPolicy de Monitoring (
roles/monitoring.alertPolicyEditor
) en tu proyecto. Para obtener más información sobre cómo otorgar roles, consulta Administra el acceso a proyectos, carpetas y organizaciones.También puedes obtener los permisos necesarios mediante roles personalizados o cualquier otro rol predefinido.
Para obtener información detallada sobre los roles de IAM para Monitoring, consulta Controla el acceso con Identity and Access Management.
Diseña tu aplicación para que realice llamadas a la API de Cloud Monitoring en un subproceso que modiquen el estado de una política de alertas en un proyecto de Google Cloud. Por ejemplo, llamadas a la API de subproceso único que crean, actualizan o borran una política de alertas.
Crea una política de alertas
Para crear una política de alertas en un proyecto, usa el método alertPolicies.create
. Para obtener información sobre cómo invocar este método, sus parámetros y los datos de respuesta, consulta la página de referencia alertPolicies.create
.
Puedes crear políticas desde archivos JSON o YAML.
Google Cloud CLI acepta estos archivos como argumentos, y puedes leer archivos JSON de manera programática y convertirlos en objetos AlertPolicy
, además de crear políticas a partir de ellos mediante el método alertPolicies.create
. Si
tienes un archivo de configuración JSON o YAML de Prometheus con una regla de alertas, gcloud CLI puede migrarlo a una política de alertas de Cloud Monitoring
con una condición de PromQL. Para obtener más información, consulta Migra reglas de alertas y receptores de Prometheus.
Cada política de alertas pertenece a un proyecto de permisos de un permiso de métricas. Cada proyecto puede contener hasta 500 políticas.
Para las llamadas a la API, debes proporcionar un "ID de proyecto". Usa el ID del proyecto de alcance de un permiso de métricas como valor. En estos ejemplos, el ID del proyecto de permisos de un permiso de métricas es a-gcp-project
.
En los siguientes ejemplos, se ilustra la creación de políticas de alertas, pero no se describe cómo crear un archivo JSON o YAML que describa una política de alertas. En cambio, los ejemplos suponen que existe un archivo con formato JSON y muestran cómo emitir la llamada a la API. Para ver ejemplos de archivos JSON, consulta Políticas de muestra. Para obtener información general sobre la supervisión de las proporciones de las métricas, consulta Proporciones de las métricas.
gcloud
Para crear una política de alertas en un proyecto, usa el comando gcloud alpha monitoring
policies create
. En el siguiente ejemplo, se crea una política de alertas en a-gcp-project
del archivo rising-cpu-usage.json
:
gcloud alpha monitoring policies create --policy-from-file="rising-cpu-usage.json"
Si funciona, este comando muestra el nombre de la política nueva, por ejemplo:
Created alert policy [projects/a-gcp-project/alertPolicies/12669073143329903307].
El archivo rising-cpu-usage.json
contiene el JSON de una política con el nombre visible “Tasa de cambio de CPU alta”. Para obtener más información sobre esta política, consulta Política de tasa de cambio.
Consulta la referencia de gcloud alpha monitoring policies create
para obtener más información.
C#
Para autenticarte en Monitoring, configura las credenciales predeterminadas de la aplicación. Si deseas obtener más información, consulta Configura la autenticación para un entorno de desarrollo local.
Go
Para autenticarte en Monitoring, configura las credenciales predeterminadas de la aplicación. Si deseas obtener más información, consulta Configura la autenticación para un entorno de desarrollo local.
Java
Para autenticarte en Monitoring, configura las credenciales predeterminadas de la aplicación. Si deseas obtener más información, consulta Configura la autenticación para un entorno de desarrollo local.
Node.js
Para autenticarte en Monitoring, configura las credenciales predeterminadas de la aplicación. Si deseas obtener más información, consulta Configura la autenticación para un entorno de desarrollo local.
PHP
Para autenticarte en Monitoring, configura las credenciales predeterminadas de la aplicación. Si deseas obtener más información, consulta Configura la autenticación para un entorno de desarrollo local.
Python
Para autenticarte en Monitoring, configura las credenciales predeterminadas de la aplicación. Si deseas obtener más información, consulta Configura la autenticación para un entorno de desarrollo local.
El objeto AlertPolicy
creado tendrá campos adicionales.
La política en sí tendrá los campos name
, creationRecord
y mutationRecord
. Además, cada condición en la política también recibe un name
.
Estos campos no pueden modificarse de forma externa, por lo que no es necesario configurarlos cuando creas una política. Ninguno de los ejemplos de JSON usados para crear políticas los incluye, pero si las políticas creadas a partir de ellas se recuperan después de la creación, los campos estarán presentes.
Configura notificaciones repetidas para las políticas de alertas basadas en métricas
De forma predeterminada, una política de alertas basada en métricas envía una notificación a cada canal de notificación cuando se abre un incidente. Sin embargo, puedes cambiar el comportamiento predeterminado y configurar una política de alertas para volver a enviar notificaciones a todos o algunos de los canales de notificaciones de tu política de alertas. Estas notificaciones repetidas se envían para incidentes con el estado Abierto o Recibido. El intervalo entre estas notificaciones debe ser de al menos 30 minutos y no más de 24 horas, expresado en segundos.
Para configurar notificaciones repetidas, agrega a la configuración de la política de alertas un objeto AlertStrategy
que contenga al menos un objeto NotificationChannelStrategy
.
Un objeto NotificationChannelStrategy
tiene dos campos:
renotifyInterval
: Es el intervalo, en segundos, entre las notificaciones repetidas.Si cambias el valor del campo
renotifyInterval
cuando se abre un incidente de la política de alertas, ocurrirá lo siguiente:- La política de alertas envía otra notificación por el incidente.
- La política de alertas reinicia el período del intervalo.
notificationChannelNames
: Es un array de nombres de recursos de canales de notificación, que son cadenas con el formatoprojects/PROJECT_ID/notificationChannels/CHANNEL_ID
, en el que CHANNEL_ID es un valor numérico. Para obtener información sobre cómo recuperar el ID del canal, consulta Cómo enumerar los canales de notificación de un proyecto.
Por ejemplo, en la siguiente muestra de JSON, se muestra una estrategia de alerta configurada para enviar notificaciones repetidas cada 1,800 segundos (30 minutos) a un canal de notificaciones:
"alertStrategy": { "notificationChannelStrategy": [ { "notificationChannelNames": [ "projects/PROJECT_ID/notificationChannels/CHANNEL_ID" ], "renotifyInterval": "1800s" } ] }
Para detener temporalmente las notificaciones repetidas, crea una posposición. Para evitar notificaciones repetidas, edita la política de alertas con la API y quita el objeto NotificationChannelStrategy
.
¿Qué sigue?
- Administra las políticas de alertas según la API
- Crea y administra canales de notificación con la API