Criar políticas de alertas usando a API

Uma política de alertas é representada na API Cloud Monitoring por um objeto AlertPolicy, que descreve um conjunto de condições que indicam um status potencialmente não íntegro em seu sistema.

Neste documento, descrevemos o seguinte:

  • Como a API Monitoring representa as políticas de alertas.
  • Os tipos de condições que a API Monitoring oferece para políticas de alerta.
  • Como criar uma política de alertas usando a CLI do Google Cloud ou as bibliotecas de cliente.

Estrutura de uma política de alertas

A estrutura AlertPolicy define os componentes de uma política de alertas. Ao criar uma política, você especifica valores para os seguintes campos AlertPolicy:

  • displayName: um rótulo descritivo para a política.
  • documentation: recomendamos que você use este campo. para fornecer informações que ajudem os responsáveis pela resposta a incidentes. Para mais informações, consulte Anotar notificações com a documentação definida pelo usuário.
  • userLabels: qualquer rótulo definido pelo usuário anexado à política. Para informações sobre como usar rótulos com alertas, consulte Anotar incidentes com rótulos.
  • conditions[]: uma matriz de estruturas Condition.
  • combiner: um operador lógico que determina como lidar com vários pelas condições
  • notificationChannels[]: uma matriz de nomes de recursos, cada um identificando um NotificationChannel.
  • alertStrategy: especifica o seguinte:
    • A rapidez com que o Monitoring fecha incidentes quando os dados param de chegar.
    • Para políticas de alertas com base em métricas, sejam elas envia uma notificação quando um incidente é encerrado.
    • Para políticas de alertas com base em métricas, se notificações repetidas ativadas e o intervalo entre essas notificações. Para mais informações, consulte Configurar notificações repetidas para políticas de alertas com base em métricas.

Também é possível especificar o campo severity ao usar a API Cloud Monitoring e o console do Google Cloud. Esse campo permite definir o nível de gravidade dos sobre possíveis incidentes. Se você não especificar uma gravidade, o Cloud Monitoring definirá a gravidade da política de alertas como No Severity.

Há outros campos que você pode usar, dependendo das condições que criar.

Quando uma política de alertas contém uma condição, uma notificação é enviada se essa condição for atendida. Para informações sobre notificações quando as políticas de alertas contêm várias condições, consulte Políticas com várias condições e Número de notificações por política.

Quando você cria ou modifica a política de alertas, o Monitoring também define outros campos, incluindo o name. O valor do campo name é o nome do recurso da política de alertas, que identifica a política. O nome do recurso tem o seguinte formato:

projects/PROJECT_ID/alertPolicies/POLICY_ID

Tipos de condições na API

A API Cloud Monitoring é compatível com vários tipos de condição na estrutura Condition. Há vários tipos de condição para políticas de alertas com base em métricas e outro para políticas de alertas com base em registros. As seções a seguir descrevem os tipos de condição disponíveis.

Condições para políticas de alertas com base em métricas

Para criar uma política de alertas que monitore dados de métricas, incluindo métricas com base em registros, use os seguintes tipos de condição:

Condições de métrica com base em filtro

As condições MetricAbsence e MetricThreshold usam filtros de monitoramento para selecionar os dados de série temporal a serem monitorados. Outros campos na estrutura da condição especificam como filtrar, agrupar e agregar os dados. Para mais informações sobre esses conceitos, consulte Filtragem e agregação: como manipular séries temporais.

Se você usar o tipo de condição MetricAbsence, poderá criar uma condição que é atendida apenas quando todas as série temporal estão ausentes. Esta condição usa o parâmetro aggregations para agregar várias série temporal em uma única série temporal. Para mais informações, consulte a referência MetricAbsence na documentação da API.

Uma política de alerta de ausência de métrica exige que alguns dados tenham sido gravados anteriormente. Para mais informações, consulte Criar políticas de alertas de ausência de métrica.

Se você quiser receber notificações com base em um valor previsto, configure a política de alertas para usar o tipo de condição MetricThreshold e definir o campo forecastOptions. Quando esse campo não está definido, os dados medidos são comparados a um limite. No entanto, quando este campo é definido, os dados previstos são comparados a uma o limite mínimo. Para mais informações, consulte Criar políticas de alertas de valores de métricas previstas.

Condições de métrica baseadas em MQL

A condição MonitoringQueryLanguageCondition usa a linguagem de consulta do Monitoring (MQL, na sigla em inglês) para selecionar e manipular os dados de séries temporais a serem monitoradas. É possível criar políticas de alerta que comparam valores com um limite ou testar a ausência de valores com esse tipo de condição. Se você usar uma condição MonitoringQueryLanguageCondition, ela precisará ser a única condição na política de alertas. Para mais informações, consulte Políticas de alertas com a MQL.

Condições de métrica baseadas em PromQL

A condição PrometheusQueryLanguageCondition usa consultas da linguagem de consulta do Prometheus (PromQL) para selecionar e manipular dados de séries temporais a serem monitoradas. Sua condição pode calcular uma proporção de métricas, avaliar comparações de métricas e muito mais.

Se você usar uma condição PrometheusQueryLanguageCondition, ela precisará ser a única na política de alertas. Para mais informações, consulte Políticas de alertas com PromQL.

Condições para alertas de proporções

É possível criar políticas de alertas de limite de métricas para monitorar a proporção de duas métricas. É possível criar essas políticas usando o tipo de condição MetricThreshold ou MonitoringQueryLanguageCondition. Também é possível usar o MQL diretamente no console do Google Cloud. Não é possível criar ou gerenciar condições com base em proporção usando a interface gráfica para criar condições de limite.

Recomendamos o uso de MQL para criar políticas de alertas com base em proporção. A MQL permite criar consultas mais eficientes e flexíveis do que é possível criar usando o tipo de condição MetricTheshold e filtros do Monitoring. Por exemplo, com uma condição MonitoringQueryLanguageCondition, é possível calcular a proporção de uma métrica em relação a uma métrica delta. Para mais informações, consulte Exemplos de política de alertas do MQL.

Se você usar a condição MetricThreshold, o numerador e o denominador da proporção precisarão ter os mesmos MetricKind. Para ver uma lista de métricas e suas propriedades, consulte Listas de métricas.

Em geral, é melhor calcular proporções com base em séries temporais coletadas para um único tipo de métrica usando valores de rótulo. Uma proporção calculada em dois tipos de métricas diferentes estão sujeitos a anomalias devido à amostragem diferente períodos e janelas de alinhamento.

Por exemplo, suponha que você tem dois tipos de métrica diferentes, uma contagem total de RPC e uma contagem de erros de RPC, e quer calcular a proporção de contagem de erros de RPC em relação ao total de RPCs. As RPCs malsucedidas são contadas na série temporal dos dois tipos de métricas. Portanto, há uma chance de que, quando você alinha a série temporal, uma RPC malsucedida não apareça no mesmo intervalo de alinhamento para as duas séries temporais. Essa diferença pode ocorrer por vários motivos, incluindo:

  • Como há duas séries temporais diferentes gravando o mesmo evento, há dois valores de contador subjacentes implementando a coleta, e eles não são atualizados atomicamente.
  • As taxas de amostragem podem ser diferentes. Quando as séries temporais estão alinhadas a um período comum, as contagens de um único evento podem aparecer em intervalos de alinhamento adjacentes na série temporal de diferentes métricas.

A diferença no número de valores nos intervalos de alinhamento correspondentes pode levar a valores de proporção error/total ilógicos, como 1/0 ou 2/1.

As proporções de números maiores têm menos probabilidade de resultar em valores sem sentido. É possível conseguir números maiores por agregação, seja usando uma janela de alinhamento que é maior do que o período de amostragem ou agrupando dados de uma rótulos Essas técnicas minimizam o efeito de pequenas diferenças no número de pontos em um determinado intervalo. Ou seja, uma disparidade de dois pontos é mais significativa quando o número esperado de pontos em um intervalo é 3 do que quando o número esperado é 300.

Se você estiver usando tipos de métricas integrados, talvez não tenha opção senão calcular proporções nos tipos de métricas para obter o valor necessário.

Se você estiver criando métricas personalizadas para contar o mesmo resultado (como RPCs que retornam status de erro) em duas métricas diferentes, considere uma única métrica que inclua cada contagem apenas uma vez. Por exemplo, suponha que você esteja contando RPCs e queira rastrear a proporção de RPCs malsucedidas para todas as RPCs. Para resolver esse problema, crie um único tipo de métrica para contar RPCs e use um rótulo para registrar o status da invocação, incluindo o status "OK". Depois, cada valor de status, de erro ou "OK" será registrado ao atualizar um contador único para esse caso.

Condição para políticas de alertas com base em registros

Para criar uma política de alertas baseada em registros, que notifica você quando uma mensagem correspondente ao seu filtro aparecer nas entradas de registro, use o tipo de condição LogMatch. Se você usar uma condição LogMatch, ela precisará ser a única condição na política de alertas.

Não tente usar o tipo de condição LogMatch em conjunto com métricas com base em registros. As políticas de alertas que monitoram métricas com base em registros são políticas baseadas em métricas. Para mais informações sobre como escolher métricas com base em registros ou entradas de registro, consulte Como monitorar seus registros.

As políticas de alertas usadas nos exemplos da O documento Gerenciar políticas de alertas por API se baseia em métricas. alertando mas os princípios são os mesmos das políticas de alertas com base em registros. Para informações específicas sobre políticas de alertas com base em registros, consulte Criar uma política de alertas com base em registros usando a API Monitoring na documentação do Cloud Logging.

Antes de começar

Para escrever código na API, você precisa cumprir estes requisitos:

  • Ter familiaridade com os conceitos gerais e a terminologia usados com alertas policies; consulte Visão geral de alertas para mais informações imprecisas ou inadequadas.
  • Verifique se a API Cloud Monitoring está ativada para uso. Consulte Como ativar a API para mais informações.
  • Se você planeja usar bibliotecas de cliente, instale as bibliotecas para a idiomas que você quer usar. ver Bibliotecas de cliente para mais detalhes. Atualmente, a API é compatível com alertas somente em C#, Go, Java, Node.js e Python.

  • Se você planeja usar a Google Cloud CLI, instale-a. No entanto, se você usar o Cloud Shell, a Google Cloud CLI será já instalado.

    Aqui, também são fornecidos exemplos usando a interface gcloud. Observe que os exemplos gcloud assumem que o projeto atual já foi definido como o destino (gcloud config set project [PROJECT_ID]), portanto, as chamadas omitem a sinalização explícita --project. O código do projeto atual nos exemplos é a-gcp-project.

Criar uma política de alertas

Para criar uma política de alertas em um projeto, use o alertPolicies.create. Para informações sobre como invocar esse método, os parâmetros dele e os dados de resposta, consulte a página de referência alertPolicies.create.

Você pode criar políticas com base em arquivos JSON ou YAML. A CLI do Google Cloud aceita esses arquivos como argumentos, e é possível ler arquivos JSON de maneira programática, convertê-los em objetos AlertPolicy e criar políticas com base neles usando o método alertPolicies.create. Se você tiver um arquivo de configuração JSON ou YAML do Prometheus com uma regra de alerta a CLI gcloud pode migrá-los para um alerta do Cloud Monitoring política com uma condição PromQL. Para mais informações, consulte Migre regras e receptores de alertas do Prometheus.

Cada política de alertas pertence a um projeto de escopo de um escopo de métricas. Cada projeto pode conter até 500 políticas. Para chamadas de API, é preciso fornecer um "ID do projeto". use o ID do projeto de escopo de um escopo de métricas como o valor. Nestes exemplos, o ID do projeto de escopo de um escopo de métricas é a-gcp-project.

Os exemplos a seguir ilustram a criação de políticas de alertas, mas não descrevem como criar um arquivo JSON ou YAML que descreva uma política de alertas. Em vez disso, as amostras presumem que um arquivo formatado em JSON e ilustram como emitir a chamada de API. Para conferir exemplos de arquivos JSON, consulte Políticas de amostra. Para informações gerais sobre o monitoramento de taxas de métricas, consulte Taxas de métricas.

gcloud

Para criar uma política de alertas em um projeto, use o comando gcloud alpha monitoring policies create. O exemplo a seguir cria uma política de alertas em a-gcp-project a partir do arquivo rising-cpu-usage.json:

gcloud alpha monitoring policies create --policy-from-file="rising-cpu-usage.json"

Se bem-sucedido, este comando retornará o nome da nova política. Por exemplo:

Created alert policy [projects/a-gcp-project/alertPolicies/12669073143329903307].

O arquivo rising-cpu-usage.json contém o JSON de uma política com com o nome de exibição "Alta taxa de mudança da CPU". Para mais detalhes sobre essa política, consulte política de taxa de mudança.

Consulte a referência gcloud alpha monitoring policies create para mais informações.

C#

Para autenticar no Monitoring, configure o Application Default Credentials. Para mais informações, consulte Configurar a autenticação para um ambiente de desenvolvimento 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 autenticar no Monitoring, configure o Application Default Credentials. Para mais informações, consulte Configurar a autenticação para um ambiente de desenvolvimento 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 autenticar no Monitoring, configure o Application Default Credentials. Para mais informações, consulte Configurar a autenticação para um ambiente de desenvolvimento 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 autenticar no Monitoring, configure o Application Default Credentials. Para mais informações, consulte Configurar a autenticação para um ambiente de desenvolvimento 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 autenticar no Monitoring, configure o Application Default Credentials. Para mais informações, consulte Configurar a autenticação para um ambiente de desenvolvimento 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 autenticar no Monitoring, configure o Application Default Credentials. Para mais informações, consulte Configurar a autenticação para um ambiente de desenvolvimento 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)

O objeto AlertPolicy criado terá campos adicionais. A própria política terá os campos name, creationRecord e mutationRecord. Além disso, cada condição na política também recebe um name. Esses campos não podem ser modificados externamente. Dessa maneira, não é necessário configurá-los durante a criação de uma política. Nenhum dos exemplos JSON usados para criar políticas os inclui, mas, se as políticas criadas com base neles forem recuperadas depois da criação, os campos estarão presentes.

Configurar notificações repetidas para políticas de alertas baseadas em métricas

Por padrão, uma política de alertas com base em métricas envia uma notificação a cada notificação quando um incidente é aberto. No entanto, é possível mudar o comportamento padrão e configurar uma política de alertas para reenviar notificações para todos ou alguns dos canais de notificação. Essas notificações repetidas são enviadas para incidentes com status de "Aberto" ou "Confirmado". O intervalo entre essas notificações deve ter pelo menos 30 minutos e não mais do que 24 horas, expressas em segundos.

Para configurar notificações repetidas, adicione à configuração da política de alertas um objeto AlertStrategy que contém pelo menos um objeto NotificationChannelStrategy. Um objeto NotificationChannelStrategy tem dois campos:

  • renotifyInterval: o intervalo, em segundos, entre notificações repetidas.

    Se você mudar o valor do campo renotifyInterval quando um incidente da política de alertas for aberto, o seguinte vai acontecer:

    • A política de alertas envia outro do incidente.
    • A política de alertas reinicia o período do intervalo.

  • notificationChannelNames: uma matriz de nomes de recursos do canal de notificação. que são strings no formato projects/PROJECT_ID/notificationChannels/CHANNEL_ID, em que CHANNEL_ID é um valor numérico. Para informações sobre como recuperar o ID do canal, consulte Listar canais de notificação em um projeto

Por exemplo, o exemplo de JSON a seguir mostra uma estratégia de alerta configurada para enviar notificações repetidas a cada 1.800 segundos (30 minutos) para um canal de notificação:

  "alertStrategy": {
    "notificationChannelStrategy": [
      {
        "notificationChannelNames": [
          "projects/PROJECT_ID/notificationChannels/CHANNEL_ID"
        ],
        "renotifyInterval": "1800s"
      }
    ]
  }

Para interromper temporariamente as notificações repetidas, crie um adiamento. Para evitar notificações repetidas, editar a política de alertas usando a API e remova o objeto NotificationChannelStrategy.

A seguir