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 fornece para políticas de alertas.
  • Como criar uma política de alertas usando a Google Cloud CLI 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, especifique valores para os seguintes campos AlertPolicy:

  • displayName: um rótulo descritivo para a política.
  • documentation: qualquer informação fornecida para ajudar os socorristas. Este campo é opcional. O objeto documentation inclui o seguinte:
    • content: texto definido pelo usuário que aparece no corpo da notificação.
    • subject: a linha de assunto da notificação. As linhas de assunto são limitadas a 255 caracteres.
  • userLabels: qualquer rótulo definido pelo usuário anexado à política. Para informações sobre como usar rótulos com alertas, consulte Anotar alertas com rótulos.
  • conditions[]: uma matriz de estruturas Condition.
  • combiner: um operador lógico que determina como lidar com várias condições.
  • notificationChannels[]: uma matriz de nomes de recursos, cada um identificando um NotificationChannel.
  • alertStrategy: especifica a rapidez com que o Monitoring fecha incidentes quando os dados param de chegar. Esse objeto também especifica se as notificações repetidas estão ativadas para alertas com base em métricas e o intervalo entre essas notificações. Para mais informações, consulte [Enviar notificações repetidas][repeat-notifications].

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 incidentes. Se você não especificar uma gravidade, o Cloud Monitoring vai 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 contiver uma condição, uma notificação será enviada quando ela 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 tipos de condição a seguir:

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 será atendida apenas quando todas as série temporal estiverem ausentes. Essa condição usa o parâmetro aggregations para agregar várias séries temporais em uma única série temporal. Para mais informações, consulte a referência MetricAbsence na documentação da API.

Uma política de alertas 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 sua política de alertas para usar o tipo de condição MetricThreshold e definir o campo forecastOptions. Quando esse campo não é definido, os dados medidos são comparados a um limite. No entanto, quando esse campo é definido, os dados previstos são comparados a um limite. Para mais informações, consulte Criar políticas de alertas previstos com valor de métricas.

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 da métrica com base em PromQL

A condição PrometheusQueryLanguageCondition usa consultas da linguagem de consulta do Prometheus (PromQL, na sigla em inglês) para selecionar e manipular dados de séries temporais para monitoramento. É possível criar uma consulta simples ou complexa e usar estruturas de consulta, como limites dinâmicos, proporções, comparações de métricas e muito mais.

Se você usar uma condição PrometheusQueryLanguageCondition, ela precisará ser a única condição 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. Você também pode 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á sujeita a anomalias devido a períodos de amostragem e janelas de alinhamento distintos.

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.

Proporções de números maiores são menos propensas a resultar em valores sem sentido. É possível conseguir números maiores por agregação, usando uma janela de alinhamento maior que o período de amostragem ou agrupando dados para determinados 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 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 entre políticas de alertas que monitoram métricas com base em registros ou entradas de registro, consulte Como monitorar seus registros.

As políticas de alertas usadas nos exemplos do documento Gerenciar políticas de alertas por API são baseadas em métricas, embora os princípios sejam os mesmos para políticas de alertas com base em registros. Para informações específicas sobre políticas de alertas com base em registros, consulte Criar um alerta 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:

  • Familiarize-se com os conceitos gerais e a terminologia usados com políticas de alertas. Consulte Visão geral de alertas para mais informações.
  • 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 para as linguagens que quer usar. Consulte Bibliotecas de cliente para 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ê usa o Cloud Shell, a Google Cloud CLI já está instalada.

    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.

  • Para ter as permissões necessárias para criar e modificar políticas de alertas usando a API Cloud Monitoring, peça ao administrador para conceder a você o papel de IAM Editor de AlertPolicy do Monitoring (roles/monitoring.alertPolicyEditor) no projeto. Para mais informações sobre como conceder papéis, consulte Gerenciar acesso.

    Também é possível conseguir as permissões necessárias por meio de papéis personalizados ou de outros papéis predefinidos.

    Para informações detalhadas sobre os papéis do IAM para o Monitoring, consulte Controlar o acesso com o Identity and Access Management.

  • Projete seu aplicativo para chamadas da API Cloud Monitoring de linha única que modificam o estado de uma política de alertas em um projeto do Google Cloud. Por exemplo, chamadas de API de linha de execução única que criam, atualizam ou excluem uma política de alertas.

criar uma política de alertas

Para criar uma política de alertas em um projeto, use o método 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 Google Cloud CLI 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 poderá migrá-lo para uma política de alertas do Cloud Monitoring com uma condição do PromQL. Para mais informações, consulte Migrar regras de alerta e receptores 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, os exemplos pressupõem que existe um arquivo formatado em JSON e ilustram como emitir a chamada de API. Para exemplos de arquivos JSON, consulte Políticas de amostra. Para informações gerais sobre o monitoramento de proporções de métricas, consulte Proporções 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 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 com base em métricas

Por padrão, uma política de alertas com base em métricas envia uma notificação para cada canal quando um incidente é aberto. No entanto, é possível alterar o comportamento padrão e configurar uma política de alertas para reenviar notificações a todos ou alguns dos canais de notificação da política. Essas notificações repetidas são enviadas para incidentes com um status "Aberto" ou "Reconhecido". O intervalo entre essas notificações precisa ser de pelo menos 30 minutos a 24 horas, expresso em segundos.

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

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

    Se você alterar o valor do campo renotifyInterval quando um incidente da política de alertas for aberto, ocorrerá o seguinte:

    • A política de alertas envia outra notificação sobre o 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 de 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.

O exemplo JSON a seguir mostra uma estratégia de alertas 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, edite a política de alertas usando a API e remova o objeto NotificationChannelStrategy.

A seguir