Una política de alertas se representa en la API Cloud Monitoring mediante un objeto AlertPolicy
, que describe un conjunto de condiciones que indican un estado potencialmente incorrecto en tu sistema.
En este documento se describe lo siguiente:
- Cómo representa la API Monitoring las políticas de alertas.
- Los tipos de condiciones que proporciona la API Monitoring para las políticas de alertas.
- Cómo crear una política de alertas con la CLI de Google Cloud o las bibliotecas de cliente.
Esta función solo se admite en proyectos de Google Cloud . En el caso de las configuraciones de App Hub, seleccione el proyecto host de App Hub o el proyecto de gestión de la carpeta habilitada para aplicaciones.
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 los valores de los siguientes campos de AlertPolicy
:
displayName
: una etiqueta descriptiva de la política.documentation
: te recomendamos que uses este campo para proporcionar información que ayude a los responsables de responder a incidentes. Para obtener más información, consulta Anotar notificaciones con documentación definida por el usuario.userLabels
: cualquier etiqueta definida por el usuario que se haya adjuntado a la política. Las políticas de alertas, los incidentes y las notificaciones muestran estas etiquetas. Para obtener información sobre cómo usar etiquetas con alertas, consulta el artículo Anotar incidentes con etiquetas.conditions[]
: una matriz de estructurasCondition
.combiner
: operador lógico que determina cómo gestionar varias condiciones.notificationChannels[]
: 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, indica si Monitoring envía una notificación cuando se cierra un incidente.
- En el caso de las políticas de alertas basadas en métricas, si las notificaciones repetidas están habilitadas y el intervalo entre ellas. Para obtener más información, consulta Configurar notificaciones repetidas para políticas de alertas basadas en métricas.
También puedes especificar el campo severity
cuando uses la API Cloud Monitoring y la consola Google Cloud . Este campo te permite definir el nivel de gravedad de los incidentes. Si no especificas una gravedad, Cloud Monitoring asignará el valor No Severity
a la gravedad de la política de alertas.
Puede usar otros campos en función de las condiciones que cree.
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 Número de notificaciones por política.
Cuando creas o modificas la política de alertas, Monitoring también define otros campos, incluido el campo name
. El valor del campo name
es el nombre del recurso de la política de alertas, que identifica la política. El nombre del recurso tiene el siguiente formato:
projects/PROJECT_ID/alertPolicies/POLICY_ID
En la expresión anterior:
- PROJECT_ID: identificador del proyecto. En el caso de las configuraciones de App Hub, seleccione el proyecto host de App Hub o el proyecto de gestión de la carpeta habilitada para aplicaciones.
- POLICY_ID: el ID de la política de alertas
Tipos de condiciones en la API
La API Cloud Monitoring admite varios tipos de condiciones en la estructura Condition
. Hay 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 de las políticas de alertas basadas en métricas
Para crear una política de alertas que monitorice datos de métricas, incluidas las métricas basadas en registros, puedes usar los siguientes tipos de condiciones:
Condiciones de métricas basadas en filtros
Las condiciones MetricAbsence
y MetricThreshold
usan filtros de monitorización para seleccionar los datos de series temporales que se van a monitorizar. 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, consulte Filtrado y agregación: manipular series temporales.
Si usas el tipo de condición MetricAbsence
, puedes crear una condición que se cumpla solo cuando falten todas 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 por ausencia de métricas requiere que se hayan escrito algunos datos previamente. Para obtener más información, consulta Crear políticas de alertas por ausencia de métricas.
Si quieres 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 define el campo forecastOptions
. Si no se define este campo, los datos medidos se comparan con un umbral.
Sin embargo, cuando se define este campo, los datos previstos se comparan con un umbral. Para obtener más información, consulta Crear políticas de alertas de valores de métricas previstos.
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 van a monitorizar.
Tu condición puede calcular una proporción de métricas, evaluar comparaciones de métricas y más.
Si usas una condición PrometheusQueryLanguageCondition
, debe ser la única condición de tu política de alertas. Para obtener más información, consulta Políticas de alertas con PromQL.
Condiciones para recibir alertas sobre ratios
Puede crear políticas de alertas de umbral de métricas para monitorizar la proporción de dos métricas. Puede crear estas políticas usando el tipo de condición MetricThreshold
o PrometheusQueryLanguageCondition
.
También puedes usar PromQL directamente en la Google Cloud consola. No puede crear ni gestionar condiciones basadas en ratios mediante la interfaz gráfica para crear condiciones de umbral.
Te recomendamos que uses PromQL para crear políticas de alertas basadas en ratios.
PromQL te permite crear consultas más potentes y flexibles que las que puedes crear con el tipo de condición MetricTheshold
y los filtros de Monitoring.
Por ejemplo, con una condición PrometheusQueryLanguageCondition
, puede calcular la proporción de una métrica de tipo Gauge con respecto a una métrica de tipo Delta.
Si usas la condición MetricThreshold
, el numerador y el denominador de la relación deben tener el mismo MetricKind
.
Para ver una lista de métricas y sus propiedades, consulte Listas de métricas.
En general, es mejor calcular las ratios en función de las series temporales recogidas para un solo tipo de métrica usando valores de etiqueta. Una ratio calculada a partir de dos tipos de métricas diferentes está sujeta a anomalías debido a los diferentes periodos de muestreo y ventanas de alineación.
Por ejemplo, supongamos que tiene dos tipos de métricas diferentes: un recuento total de RPCs y un recuento de errores de RPCs. Quiere calcular la proporción de RPCs con errores con respecto al total de RPCs. Las llamadas a RPC fallidas se contabilizan en las series temporales de ambos tipos de métricas. Por lo tanto, es posible que, al alinear las series temporales, una RPC fallida no aparezca en el mismo intervalo de alineación para ambas series temporales. Esta diferencia puede deberse a varios motivos, entre los que se incluyen los siguientes:
- Como 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 forma atómica.
- Las frecuencias de muestreo pueden ser diferentes. Cuando las series temporales se alinean en un periodo común, los recuentos de un solo evento pueden aparecer en intervalos de alineación adyacentes en las series temporales de las diferentes métricas.
La diferencia en el número de valores de los intervalos de alineación correspondientes puede dar lugar a 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 den lugar a valores sin sentido. Puedes obtener cifras más altas mediante la agregación, ya sea usando una ventana de alineación que sea más larga que el periodo de muestreo o agrupando los datos de determinadas etiquetas. Estas técnicas minimizan el efecto de las pequeñas diferencias en el número de puntos de un intervalo determinado. Es decir, una disparidad de dos puntos es más significativa cuando el número esperado de puntos en un intervalo es 3 que cuando es 300.
Si usas tipos de métricas integrados, es posible que no tengas más remedio que calcular ratios entre tipos de métricas para obtener el valor que necesitas.
Si diseña métricas personalizadas que pueden contabilizar lo mismo (por ejemplo, las llamadas a procedimientos remotos que devuelven un estado de error) en dos métricas diferentes, le recomendamos que utilice una sola métrica que incluya cada recuento solo una vez. Por ejemplo, supongamos que estás contando llamadas a procedimientos remotos y quieres monitorizar la proporción de llamadas a procedimientos remotos fallidas con respecto a todas las llamadas a procedimientos remotos. Para solucionar este problema, crea un solo tipo de métrica para contar las llamadas a procedimientos remotos y usa una etiqueta para registrar el estado de la invocación, incluido el estado "OK". A continuación, se registra cada valor de estado (error u "OK") actualizando un contador único para ese caso.
Condición de las políticas de alertas basadas en registros
Para crear una política de alertas basada en registros que te avise cuando aparezca un mensaje que coincida con tu filtro en las entradas de registro, usa el tipo de condición LogMatch
. Si usas una condición LogMatch
, debe ser la única condición de tu política de alertas.
No intentes usar el tipo de condición LogMatch
junto con métricas basadas en registros. Las políticas de alertas que monitorizan métricas basadas en registros son políticas basadas en métricas. Para obtener más información sobre cómo elegir entre políticas de alertas que monitorizan métricas basadas en registros o entradas de registro, consulta Monitorizar tus registros.
Las políticas de alertas que se usan en los ejemplos del documento Gestionar políticas de alertas mediante 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 el artículo Crear una política de alertas basada en registros con la API Monitoring de la documentación de Cloud Logging.
Cómo asociar una política de alertas a una aplicación de App Hub
Google Cloud genera paneles de control que te ayudan a monitorizar tus aplicaciones de App Hub. Estos paneles muestran información como datos de registro y métricas de tus aplicaciones, así como los servicios y las cargas de trabajo que forman parte de la aplicación. Las políticas de alertas y sus incidentes también se muestran en estos paneles de control cuando esas políticas están asociadas al servicio o a la carga de trabajo de una aplicación. Para obtener más información sobre la monitorización de aplicaciones, consulta el artículo Ver la telemetría de las aplicaciones.
Para asociar una política de alertas a una aplicación de App Hub, añade etiquetas con las siguientes claves a tu política:
apphub_application_location
apphub_application_id
apphub_service_id
oapphub_workload_id
userLabels
de la representación JSON de una política de alertas podría ser como la siguiente:
"userLabels": { "apphub_service_id": "my-service-id", "apphub_application_location": "my-app-location", "apphub_application_id": "my-app" },
Antes de empezar
Antes de escribir código para la API, debes hacer lo siguiente:
- Familiarízate con los conceptos generales y la terminología que se usan en las políticas de alertas. Consulta el artículo Introducción a las alertas para obtener más información.
- Asegúrate de que la API Cloud Monitoring esté habilitada para su uso. Consulta el artículo sobre cómo habilitar la API para obtener más información.
- Si tienes previsto usar bibliotecas de cliente, instala las bibliotecas de los lenguajes que quieras usar. Consulta la sección Bibliotecas de cliente para obtener más información. La asistencia de la API para las alertas solo está disponible en C#, Go, Java, Node.js y Python.
Si tienes pensado usar Google Cloud CLI, instálalo. Sin embargo, si usas Cloud Shell, Google Cloud CLI ya está instalado.
También se proporcionan ejemplos en los que se usa la interfaz
gcloud
. Ten en cuenta que en todos los ejemplos degcloud
se da por hecho que el proyecto actual ya se ha definido como el de destino (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
. En el caso de las configuraciones de App Hub, seleccione el proyecto host de App Hub o el proyecto de gestión de la carpeta habilitada para aplicaciones.
-
Para obtener los permisos que necesitas para crear y modificar políticas de alertas mediante la API Cloud Monitoring, pide a tu administrador que te conceda el rol de gestión de identidades y accesos Editor de AlertPolicy de Monitoring (
roles/monitoring.alertPolicyEditor
) en tu proyecto. Para obtener más información sobre cómo conceder roles, consulta el artículo Gestionar el acceso a proyectos, carpetas y organizaciones.También puedes conseguir los permisos necesarios a través de roles personalizados u otros roles predefinidos.
Para obtener información detallada sobre los roles de gestión de identidades y accesos de Monitoring, consulta Controlar el acceso con Gestión de Identidades y Accesos.
Diseña tu aplicación para que las llamadas a la API Cloud Monitoring que modifiquen el estado de una política de alertas en unGoogle Cloud proyecto se realicen en un solo hilo. Por ejemplo, llamadas a la API de un solo hilo que crean, actualizan o eliminan una política de alertas.
Crear 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 a partir de archivos JSON o YAML.
La CLI de Google Cloud acepta estos archivos como argumentos y puedes leer archivos JSON de forma programática, convertirlos en objetos AlertPolicy
y crear políticas a partir de ellos
con el método alertPolicies.create
. Si tienes un archivo de configuración JSON o YAML de Prometheus con una regla de alerta, la CLI de gcloud puede migrarlo a una política de alertas de Cloud Monitoring con una condición PromQL. Para obtener más información, consulta el artículo sobre cómo migrar reglas de alertas y receptores de Prometheus.
Cada política de alertas pertenece a un proyecto de ámbito de un ámbito de métricas. Cada proyecto puede contener hasta 2000 políticas.
En las llamadas a la API, debe proporcionar un "ID de proyecto". Use el ID del proyecto de ámbito de un ámbito de métricas como valor. En estos ejemplos, el ID del proyecto de ámbito de un ámbito de métricas es a-gcp-project
.
En los siguientes ejemplos se muestra cómo crear políticas de alertas, pero no se describe cómo crear un archivo JSON o YAML que describa una política de alertas. En su lugar, los ejemplos parten de la base de que existe un archivo con formato JSON y muestran cómo hacer la llamada a la API. Para ver archivos JSON de ejemplo, consulta Políticas de ejemplo. Para obtener información general sobre la monitorización de ratios de métricas, consulta Ratios de 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
a partir del archivo rising-cpu-usage.json
:
gcloud alpha monitoring policies create --policy-from-file="rising-cpu-usage.json"
Si se ejecuta correctamente, este comando devuelve el nombre de la nueva política. 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 "High CPU rate of change" (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. Para obtener más información, consulta el artículo Configurar la autenticación en un entorno de desarrollo local.
Go
Para autenticarte en Monitoring, configura las credenciales predeterminadas de la aplicación. Para obtener más información, consulta el artículo Configurar la autenticación en un entorno de desarrollo local.
Java
Para autenticarte en Monitoring, configura las credenciales predeterminadas de la aplicación. Para obtener más información, consulta el artículo Configurar la autenticación en un entorno de desarrollo local.
Node.js
Para autenticarte en Monitoring, configura las credenciales predeterminadas de la aplicación. Para obtener más información, consulta el artículo Configurar la autenticación en un entorno de desarrollo local.
PHP
Para autenticarte en Monitoring, configura las credenciales predeterminadas de la aplicación. Para obtener más información, consulta el artículo Configurar la autenticación en un entorno de desarrollo local.
Python
Para autenticarte en Monitoring, configura las credenciales predeterminadas de la aplicación. Para obtener más información, consulta el artículo Configurar la autenticación en un entorno de desarrollo local.
El objeto AlertPolicy
creado tendrá campos adicionales.
La propia política tendrá los campos name
, creationRecord
y mutationRecord
. Además, a cada condición de la política se le asigna un name
.
Estos campos no se pueden modificar externamente, por lo que no es necesario definirlos al crear una política. Ninguno de los ejemplos de JSON que se usan para crear políticas los incluye, pero, si se recuperan las políticas creadas a partir de ellos después de la creación, los campos estarán presentes.
Configurar notificaciones repetidas para 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 que vuelva a enviar notificaciones a todos o a algunos de los canales de notificación de tu política de alertas. Estas notificaciones repetidas se envían en caso de incidentes con el estado Abierto o Confirmado. El intervalo entre estas notificaciones debe ser de al menos 30 minutos y no más de 24 horas, expresado en segundos.
Para configurar las notificaciones repetidas, añade 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
: intervalo, en segundos, entre notificaciones repetidas.Si cambia el valor del campo
renotifyInterval
cuando se abre un incidente de la política de alertas, ocurre lo siguiente:- La política de alertas envía otra notificación sobre el incidente.
- La política de alertas reinicia el periodo del intervalo.
notificationChannelNames
: array de nombres de recursos de canales de notificaciones, que son cadenas con el formatoprojects/PROJECT_ID/notificationChannels/CHANNEL_ID
, donde CHANNEL_ID es un valor numérico. Para obtener información sobre cómo recuperar el ID del canal, consulta List notification channels in a project (Listar canales de notificación en un proyecto).
Por ejemplo, en el siguiente ejemplo de JSON se muestra una estrategia de alertas configurada para enviar notificaciones repetidas cada 1800 segundos (30 minutos) a un canal de notificación:
"alertStrategy": { "notificationChannelStrategy": [ { "notificationChannelNames": [ "projects/PROJECT_ID/notificationChannels/CHANNEL_ID" ], "renotifyInterval": "1800s" } ] }
Para detener temporalmente las notificaciones repetidas, crea una alarma. Para evitar que se envíen notificaciones repetidas, edita la política de alertas mediante la API y elimina el objeto NotificationChannelStrategy
.
Siguientes pasos
- Gestionar políticas de alertas mediante APIs
- Crear y gestionar canales de notificación mediante APIs