Crear políticas de alertas con la API

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 estructuras Condition.

  • combiner: operador lógico que determina cómo gestionar varias condiciones.

  • notificationChannels[]: array de nombres de recursos, cada uno de los cuales identifica un NotificationChannel.

  • 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 o apphub_workload_id
Por ejemplo, la sección 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 de gcloud 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 es a-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.

static void RestorePolicies(string projectId, string filePath)
{
    var policyClient = AlertPolicyServiceClient.Create();
    var channelClient = NotificationChannelServiceClient.Create();
    List<Exception> exceptions = new List<Exception>();
    var backup = JsonConvert.DeserializeObject<BackupRecord>(
        File.ReadAllText(filePath), new ProtoMessageConverter());
    var projectName = new ProjectName(projectId);
    bool isSameProject = projectId == backup.ProjectId;
    // When a channel is recreated, rather than updated, it will get
    // a new name.  We have to update the AlertPolicy with the new
    // name.  Track the names in this map.
    var channelNameMap = new Dictionary<string, string>();
    foreach (NotificationChannel channel in backup.Channels)
    {
    }
    foreach (AlertPolicy policy in backup.Policies)
    {
        string policyName = policy.Name;
        // These two fields cannot be set directly, so clear them.
        policy.CreationRecord = null;
        policy.MutationRecord = null;
        // Update channel names if the channel was recreated with
        // another name.
        for (int i = 0; i < policy.NotificationChannels.Count; ++i)
        {
            if (channelNameMap.ContainsKey(policy.NotificationChannels[i]))
            {
                policy.NotificationChannels[i] =
                    channelNameMap[policy.NotificationChannels[i]];
            }
        }
        try
        {
            Console.WriteLine("Updating policy.\n{0}",
                policy.DisplayName);
            bool updated = false;
            if (isSameProject)
                try
                {
                    policyClient.UpdateAlertPolicy(null, policy);
                    updated = true;
                }
                catch (Grpc.Core.RpcException e)
                when (e.Status.StatusCode == StatusCode.NotFound)
                { }
            if (!updated)
            {
                // The policy no longer exists.  Recreate it.
                policy.Name = null;
                foreach (var condition in policy.Conditions)
                {
                    condition.Name = null;
                }
                policyClient.CreateAlertPolicy(projectName, policy);
            }
            Console.WriteLine("Restored {0}.", policyName);
        }
        catch (Exception e)
        {
            // If one failed, continue trying to update the others.
            exceptions.Add(e);
        }
    }
    if (exceptions.Count > 0)
    {
        throw new AggregateException(exceptions);
    }
}

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.


// restorePolicies updates the project with the alert policies and
// notification channels in r.
func restorePolicies(w io.Writer, projectID string, r io.Reader) error {
	b := backup{}
	if err := json.NewDecoder(r).Decode(&b); err != nil {
		return err
	}
	sameProject := projectID == b.ProjectID

	ctx := context.Background()

	alertClient, err := monitoring.NewAlertPolicyClient(ctx)
	if err != nil {
		return err
	}
	defer alertClient.Close()
	channelClient, err := monitoring.NewNotificationChannelClient(ctx)
	if err != nil {
		return err
	}
	defer channelClient.Close()

	// When a channel is recreated, rather than updated, it will get
	// a new name.  We have to update the AlertPolicy with the new
	// name.  channelNames keeps track of the new names.
	channelNames := make(map[string]string)
	for _, c := range b.Channels {
		fmt.Fprintf(w, "Updating channel %q\n", c.GetDisplayName())
		c.VerificationStatus = monitoringpb.NotificationChannel_VERIFICATION_STATUS_UNSPECIFIED
		updated := false
		if sameProject {
			req := &monitoringpb.UpdateNotificationChannelRequest{
				NotificationChannel: c.NotificationChannel,
			}
			_, err := channelClient.UpdateNotificationChannel(ctx, req)
			if err == nil {
				updated = true
			}
		}
		if !updated {
			req := &monitoringpb.CreateNotificationChannelRequest{
				Name:                "projects/" + projectID,
				NotificationChannel: c.NotificationChannel,
			}
			oldName := c.GetName()
			c.Name = ""
			newC, err := channelClient.CreateNotificationChannel(ctx, req)
			if err != nil {
				return err
			}
			channelNames[oldName] = newC.GetName()
		}
	}

	for _, policy := range b.AlertPolicies {
		fmt.Fprintf(w, "Updating alert %q\n", policy.GetDisplayName())
		policy.CreationRecord = nil
		policy.MutationRecord = nil
		for i, aChannel := range policy.GetNotificationChannels() {
			if c, ok := channelNames[aChannel]; ok {
				policy.NotificationChannels[i] = c
			}
		}
		updated := false
		if sameProject {
			req := &monitoringpb.UpdateAlertPolicyRequest{
				AlertPolicy: policy.AlertPolicy,
			}
			_, err := alertClient.UpdateAlertPolicy(ctx, req)
			if err == nil {
				updated = true
			}
		}
		if !updated {
			req := &monitoringpb.CreateAlertPolicyRequest{
				Name:        "projects/" + projectID,
				AlertPolicy: policy.AlertPolicy,
			}
			if _, err = alertClient.CreateAlertPolicy(ctx, req); err != nil {
				log.Fatal(err)
			}
		}
	}
	fmt.Fprintf(w, "Successfully restored alerts.")
	return nil
}

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.

private static void restoreRevisedPolicies(
    String projectId, boolean isSameProject, List<AlertPolicy> policies) throws IOException {
  try (AlertPolicyServiceClient client = AlertPolicyServiceClient.create()) {
    for (AlertPolicy policy : policies) {
      if (!isSameProject) {
        policy = client.createAlertPolicy(ProjectName.of(projectId), policy);
      } else {
        try {
          client.updateAlertPolicy(null, policy);
        } catch (Exception e) {
          policy =
              client.createAlertPolicy(
                  ProjectName.of(projectId), policy.toBuilder().clearName().build());
        }
      }
      System.out.println(String.format("Restored %s", policy.getName()));
    }
  }
}

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.

const fs = require('fs');

// Imports the Google Cloud client library
const monitoring = require('@google-cloud/monitoring');

// Creates a client
const client = new monitoring.AlertPolicyServiceClient();

async function restorePolicies() {
  // Note: The policies are restored one at a time due to limitations in
  // the API. Otherwise, you may receive a 'service unavailable'  error
  // while trying to create multiple alerts simultaneously.

  /**
   * TODO(developer): Uncomment the following lines before running the sample.
   */
  // const projectId = 'YOUR_PROJECT_ID';

  console.log('Loading policies from ./policies_backup.json');
  const fileContent = fs.readFileSync('./policies_backup.json', 'utf-8');
  const policies = JSON.parse(fileContent);

  for (const index in policies) {
    // Restore each policy one at a time
    let policy = policies[index];
    if (await doesAlertPolicyExist(policy.name)) {
      policy = await client.updateAlertPolicy({
        alertPolicy: policy,
      });
    } else {
      // Clear away output-only fields
      delete policy.name;
      delete policy.creationRecord;
      delete policy.mutationRecord;
      policy.conditions.forEach(condition => delete condition.name);

      policy = await client.createAlertPolicy({
        name: client.projectPath(projectId),
        alertPolicy: policy,
      });
    }

    console.log(`Restored ${policy[0].name}.`);
  }
  async function doesAlertPolicyExist(name) {
    try {
      const [policy] = await client.getAlertPolicy({
        name,
      });
      return policy ? true : false;
    } catch (err) {
      if (err && err.code === 5) {
        // Error code 5 comes from the google.rpc.code.NOT_FOUND protobuf
        return false;
      }
      throw err;
    }
  }
}
restorePolicies();

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.

use Google\Cloud\Monitoring\V3\AlertPolicy;
use Google\Cloud\Monitoring\V3\AlertPolicy\Condition;
use Google\Cloud\Monitoring\V3\AlertPolicy\Condition\MetricThreshold;
use Google\Cloud\Monitoring\V3\AlertPolicy\ConditionCombinerType;
use Google\Cloud\Monitoring\V3\Client\AlertPolicyServiceClient;
use Google\Cloud\Monitoring\V3\ComparisonType;
use Google\Cloud\Monitoring\V3\CreateAlertPolicyRequest;
use Google\Protobuf\Duration;

/**
 * @param string $projectId Your project ID
 */
function alert_create_policy($projectId)
{
    $alertClient = new AlertPolicyServiceClient([
        'projectId' => $projectId,
    ]);
    $projectName = 'projects/' . $projectId;

    $policy = new AlertPolicy();
    $policy->setDisplayName('Test Alert Policy');
    $policy->setCombiner(ConditionCombinerType::PBOR);
    /** @see https://cloud.google.com/monitoring/api/resources for a list of resource.type */
    /** @see https://cloud.google.com/monitoring/api/metrics_gcp for a list of metric.type */
    $policy->setConditions([new Condition([
        'display_name' => 'condition-1',
        'condition_threshold' => new MetricThreshold([
            'filter' => 'resource.type = "gce_instance" AND metric.type = "compute.googleapis.com/instance/cpu/utilization"',
            'duration' => new Duration(['seconds' => '60']),
            'comparison' => ComparisonType::COMPARISON_LT,
        ])
    ])]);
    $createAlertPolicyRequest = (new CreateAlertPolicyRequest())
        ->setName($projectName)
        ->setAlertPolicy($policy);

    $policy = $alertClient->createAlertPolicy($createAlertPolicyRequest);
    printf('Created alert policy %s' . PHP_EOL, $policy->getName());
}

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.

def restore(project_name, backup_filename):
    """Restore alert policies in a project.

    Arguments:
        project_name (str): The Google Cloud Project to use. The project name
            must be in the format - 'projects/<PROJECT_NAME>'.
        backup_filename (str): Name of the file (along with its path) from
            which the alert policies will be restored.
    """
    print(
        "Loading alert policies and notification channels from {}.".format(
            backup_filename
        )
    )
    record = json.load(open(backup_filename, "rt"))
    is_same_project = project_name == record["project_name"]
    # Convert dicts to AlertPolicies.
    policies_json = [json.dumps(policy) for policy in record["policies"]]
    policies = [
        monitoring_v3.AlertPolicy.from_json(policy_json)
        for policy_json in policies_json
    ]
    # Convert dicts to NotificationChannels
    channels_json = [json.dumps(channel) for channel in record["channels"]]
    channels = [
        monitoring_v3.NotificationChannel.from_json(channel_json)
        for channel_json in channels_json
    ]

    # Restore the channels.
    channel_client = monitoring_v3.NotificationChannelServiceClient()
    channel_name_map = {}

    for channel in channels:
        updated = False
        print("Updating channel", channel.display_name)
        # This field is immutable and it is illegal to specify a
        # non-default value (UNVERIFIED or VERIFIED) in the
        # Create() or Update() operations.
        channel.verification_status = (
            monitoring_v3.NotificationChannel.VerificationStatus.VERIFICATION_STATUS_UNSPECIFIED
        )

        if is_same_project:
            try:
                channel_client.update_notification_channel(notification_channel=channel)
                updated = True
            except google.api_core.exceptions.NotFound:
                pass  # The channel was deleted.  Create it below.

        if not updated:
            # The channel no longer exists.  Recreate it.
            old_name = channel.name
            del channel.name
            new_channel = channel_client.create_notification_channel(
                name=project_name, notification_channel=channel
            )
            channel_name_map[old_name] = new_channel.name

    # Restore the alerts
    alert_client = monitoring_v3.AlertPolicyServiceClient()

    for policy in policies:
        print("Updating policy", policy.display_name)
        # These two fields cannot be set directly, so clear them.
        del policy.creation_record
        del policy.mutation_record

        # Update old channel names with new channel names.
        for i, channel in enumerate(policy.notification_channels):
            new_channel = channel_name_map.get(channel)
            if new_channel:
                policy.notification_channels[i] = new_channel

        updated = False

        if is_same_project:
            try:
                alert_client.update_alert_policy(alert_policy=policy)
                updated = True
            except google.api_core.exceptions.NotFound:
                pass  # The policy was deleted.  Create it below.
            except google.api_core.exceptions.InvalidArgument:
                # Annoying that API throws InvalidArgument when the policy
                # does not exist.  Seems like it should throw NotFound.
                pass  # The policy was deleted.  Create it below.

        if not updated:
            # The policy no longer exists.  Recreate it.
            old_name = policy.name
            del policy.name
            for condition in policy.conditions:
                del condition.name
            policy = alert_client.create_alert_policy(
                name=project_name, alert_policy=policy
            )
        print("Updated", policy.name)

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 formato projects/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