Crie políticas de alerta através da 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 estado potencialmente não saudável no seu sistema.

Este documento descreve o seguinte:

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

Esta funcionalidade só é suportada para projetos do Google Cloud . Para configurações do App Hub, selecione o projeto anfitrião do App Hub ou o projeto de gestão da pasta com apps ativadas.

Estrutura de uma política de alerta

A estrutura AlertPolicy define os componentes de uma política de alertas. Quando cria uma política, especifica valores para os seguintes campos AlertPolicy:

  • displayName: uma etiqueta descritiva para a política.
  • documentation: recomendamos que use este campo para fornecer informações que ajudem os responsáveis pela resposta a incidentes. Para mais informações, consulte o artigo Anote notificações com documentação definida pelo utilizador.

  • userLabels: quaisquer etiquetas definidas pelo utilizador anexadas à política. As políticas de alerta, os incidentes e as notificações apresentam estas etiquetas. Para ver informações sobre a utilização de etiquetas com alertas, consulte o artigo Anote incidentes com etiquetas.

  • conditions[]: uma matriz de estruturas Condition.

  • combiner: Um operador lógico que determina como processar várias condições.

  • notificationChannels[]: uma matriz de nomes de recursos, cada um a identificar um NotificationChannel.

  • alertStrategy: especifica o seguinte:

    • A rapidez com que a monitorização fecha incidentes quando os dados deixam de chegar.
    • Para políticas de alerta baseadas em métricas, se o Monitoring envia uma notificação quando um incidente é fechado.
    • Para políticas de alerta baseadas em métricas, se as notificações repetidas estão ativadas e o intervalo entre essas notificações. Para mais informações, consulte o artigo Configure notificações repetidas para políticas de alerta baseadas em métricas.

Também pode especificar o campo severity quando usa a API Cloud Monitoring e a consola Google Cloud . Este campo permite-lhe definir o nível de gravidade dos incidentes. Se não especificar uma gravidade, o Cloud Monitoring define a gravidade da política de alertas como No Severity.

Existem outros campos que pode usar, consoante as condições que criar.

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

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

projects/PROJECT_ID/alertPolicies/POLICY_ID

Na expressão anterior:

  • PROJECT_ID: o identificador do projeto. Para configurações do App Hub, selecione o projeto anfitrião do App Hub ou o projeto de gestão da pasta com apps ativadas.
  • POLICY_ID: o ID da política de alerta

Tipos de condições na API

A API Cloud Monitoring suporta vários tipos de condições na estrutura Condition. Existem vários tipos de condições para políticas de alerta baseadas em métricas e um para políticas de alerta baseadas em registos. As secções seguintes descrevem os tipos de condições disponíveis.

Condições para políticas de alerta baseadas em métricas

Para criar uma política de alertas que monitorize dados de métricas, incluindo métricas baseadas em registos, pode usar os seguintes tipos de condições:

Condições de métricas baseadas em filtros

As condições MetricAbsence e MetricThreshold usam filtros de monitorização para selecionar os dados de séries cronológicas a monitorizar. Outros campos na estrutura da condição especificam como filtrar, agrupar e agregar os dados. Para mais informações sobre estes conceitos, consulte o artigo Filtragem e agregação: manipular séries cronológicas.

Se usar o tipo de condição MetricAbsence, pode criar uma condição que só é cumprida quando todos os intervalos temporais estão ausentes. Esta condição usa o parâmetro aggregations para agregar várias séries cronológicas numa única série cronológica. Para mais informações, consulte a referência MetricAbsence na documentação da API.

Uma política de alertas de ausência de métricas requer que alguns dados tenham sido escritos anteriormente. Para mais informações, consulte o artigo Crie políticas de alertas de ausência de métricas.

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

Condições de métricas baseadas em PromQL

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

Se usar uma condição PrometheusQueryLanguageCondition, tem de ser a única condição na sua política de alertas. Para mais informações, consulte o artigo Políticas de alerta com PromQL.

Condições para alertas sobre rácios

Pode criar políticas de alerta de limite de métricas para monitorizar a relação de duas métricas. Pode criar estas políticas usando o tipo de condição MetricThreshold ou PrometheusQueryLanguageCondition. Também pode usar o PromQL diretamente na Google Cloud consola. Não pode criar nem gerir condições baseadas em rácios através da interface gráfica para criar condições de limite.

Recomendamos a utilização do PromQL para criar políticas de alerta baseadas em rácios. O PromQL permite criar consultas mais poderosas e flexíveis do que as que pode criar usando o tipo de condição MetricTheshold e os filtros de monitorização. Por exemplo, com uma condição PrometheusQueryLanguageCondition, pode calcular a proporção de uma métrica de indicador para uma métrica delta.

Se usar a condição MetricThreshold, o numerador e o denominador da proporção têm de ter o mesmo MetricKind. Para ver uma lista de métricas e respetivas propriedades, consulte Listas de métricas.

Em geral, é melhor calcular as rácios com base nas séries cronológicas recolhidas para um único tipo de métrica, usando valores de etiquetas. Uma proporção calculada em dois tipos de métricas diferentes está sujeita a anomalias devido a diferentes períodos de amostragem e janelas de alinhamento.

Por exemplo, suponhamos que tem dois tipos de métricas diferentes, uma contagem total de RPCs e uma contagem de erros de RPCs, e quer calcular a proporção de RPCs de contagem de erros em relação ao total de RPCs. As RPCs sem êxito são contabilizadas na série cronológica de ambos os tipos de métricas. Por conseguinte, existe a possibilidade de, quando alinhar as séries cronológicas, uma RPC sem êxito não aparecer no mesmo intervalo de alinhamento para ambas as séries cronológicas. Esta diferença pode acontecer por vários motivos, incluindo os seguintes:

  • Porque existem duas séries cronológicas diferentes a registar o mesmo evento, existem dois valores de contador subjacentes a implementar a recolha e não são atualizados de forma atómica.
  • As taxas de amostragem podem diferir. Quando as séries cronológicas estão alinhadas com um período comum, as contagens de um único evento podem aparecer em intervalos de alinhamento adjacentes nas séries cronológicas para as diferentes métricas.

A diferença no número de valores nos intervalos de alinhamento correspondentes pode gerar valores de rácio error/total sem sentido, como 1/0 ou 2/1.

As proporções de números maiores têm menos probabilidade de resultar em valores sem sentido. Pode obter números maiores através da agregação, quer usando um período de alinhamento que seja mais longo do que o período de amostragem, quer agrupando dados para determinadas etiquetas. Estas técnicas minimizam o efeito de pequenas diferenças no número de pontos num determinado intervalo. Ou seja, uma disparidade de dois pontos é mais significativa quando o número esperado de pontos num intervalo é 3 do que quando o número esperado é 300.

Se estiver a usar tipos de métricas incorporados, pode não ter outra opção senão calcular rácios entre tipos de métricas para obter o valor de que precisa.

Se estiver a criar métricas personalizadas que podem contar a mesma coisa, como RPCs que devolvem o estado de erro, em duas métricas diferentes, considere usar uma única métrica que inclua cada contagem apenas uma vez. Por exemplo, suponhamos que está a contabilizar RPCs e quer acompanhar a proporção de RPCs sem êxito em relação a todas as RPCs. Para resolver este problema, crie um único tipo de métrica para contabilizar os RPCs e use uma etiqueta para registar o estado da invocação, incluindo o estado "OK". Em seguida, cada valor de estado, erro ou "OK", é registado atualizando um único contador para esse caso.

Condição para políticas de alerta baseadas em registos

Para criar uma política de alertas baseada em registos, que lhe envia uma notificação quando uma mensagem correspondente ao seu filtro aparece nas entradas do registo, use o tipo de condição LogMatch. Se usar uma condição LogMatch, tem de ser a única condição na sua política de alertas.

Não tente usar o tipo de condição LogMatch em conjunto com métricas baseadas em registos. As políticas de alerta que monitorizam métricas baseadas em registos são políticas baseadas em métricas. Para mais informações sobre a escolha entre políticas de alerta que monitorizam métricas baseadas em registos ou entradas de registos, consulte o artigo Monitorizar os seus registos.

As políticas de alerta usadas nos exemplos no documento Faça a gestão das políticas de alerta por API são políticas de alerta baseadas em métricas, embora os princípios sejam os mesmos para as políticas de alerta baseadas em registos. Para ver informações específicas sobre políticas de alertas baseadas em registos, consulte o artigo Crie uma política de alertas baseada em registos através da API Monitoring na documentação do Cloud Logging.

Como associar uma política de alerta a uma aplicação do App Hub

Google Cloud gera painéis de controlo que ajudam a monitorizar as suas aplicações do App Hub. Estes painéis de controlo apresentam informações, como dados de registo e métricas, para as suas aplicações, bem como os serviços e as cargas de trabalho que fazem parte da aplicação. As políticas de alerta e os respetivos incidentes também são apresentados nestes painéis de controlo quando essas políticas estão associadas ao serviço ou à carga de trabalho de uma aplicação. Para mais informações sobre a monitorização de aplicações, consulte o artigo Veja a telemetria de aplicações.

Para associar uma política de alertas a uma aplicação do App Hub, anexe etiquetas com as seguintes chaves à sua política:

  • apphub_application_location
  • apphub_application_id
  • apphub_service_id ou apphub_workload_id
Por exemplo, a secção userLabels da representação JSON de uma política de alertas pode ser semelhante à seguinte: 

  "userLabels": {
    "apphub_service_id": "my-service-id",
    "apphub_application_location": "my-app-location",
    "apphub_application_id": "my-app"
  },

Antes de começar

Antes de escrever código contra a API, deve:

  • Conhecer os conceitos gerais e a terminologia usados com as políticas de alerta. Consulte a vista geral dos alertas para mais informações.
  • Certifique-se de que a API Cloud Monitoring está ativada para utilização. Consulte o artigo Ativar a API para mais informações.
  • Se planeia usar bibliotecas cliente, instale as bibliotecas para os idiomas que quer usar. Consulte Bibliotecas cliente para ver detalhes. O suporte da API para alertas só está disponível para C#, Go, Java, Node.js e Python.

  • Se planeia usar a Google Cloud CLI, instale-a. No entanto, se usar a Cloud Shell, a CLI do Google Cloud já está instalada.

    Também são fornecidos exemplos de utilização da interface gcloud. Tenha em atenção que todos os exemplos gcloud partem do princípio de que o projeto atual já foi definido como o destino (gcloud config set project [PROJECT_ID]), pelo que as invocações omitem a flag --project explícita. O ID do projeto atual nos exemplos é a-gcp-project. Para configurações do App Hub, selecione o projeto anfitrião do App Hub ou o projeto de gestão da pasta com apps ativadas.

Crie uma política de alerta

Para criar uma política de alerta num projeto, use o método alertPolicies.create. Para obter informações sobre como invocar este método, os respetivos parâmetros e os dados de resposta, consulte a página de referência alertPolicies.create.

Pode criar políticas a partir de ficheiros JSON ou YAML. A CLI Google Cloud aceita estes ficheiros como argumentos e pode ler ficheiros JSON de forma programática, convertê-los em objetos e criar políticas a partir deles através do método alertPolicies.create.AlertPolicy Se tiver um ficheiro de configuração JSON ou YAML do Prometheus com uma regra de alerta, a CLI gcloud pode migrá-lo para uma política de alerta do Cloud Monitoring com uma condição PromQL. Para mais informações, consulte o artigo Migre regras de alerta e destinatários do Prometheus.

Cada política de alerta pertence a um projeto de âmbito de um âmbito de métricas. Cada projeto pode conter até 2000 políticas. Para chamadas API, tem de fornecer um "ID do projeto"; use o ID do projeto de âmbito de um âmbito de métricas como valor. Nestes exemplos, o ID do projeto de âmbito de um âmbito de métricas é a-gcp-project.

Os exemplos seguintes ilustram a criação de políticas de alerta, mas não descrevem como criar um ficheiro JSON ou YAML que descreva uma política de alerta. Em vez disso, os exemplos partem do princípio de que existe um ficheiro formatado em JSON e ilustram como emitir a chamada API. Para ver exemplos de ficheiros JSON, consulte as Políticas de amostra. Para obter informações gerais sobre a monitorização de rácios de métricas, consulte o artigo Rácios de métricas.

gcloud

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

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

Se for bem-sucedido, este comando devolve o nome da nova política, por exemplo:

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

O ficheiro rising-cpu-usage.json contém o JSON de uma política com o nome a apresentar "Taxa de variação elevada da CPU". Para ver detalhes acerca desta política, consulte a política de taxa de variação.

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

C#

Para se autenticar no Monitoring, configure as Credenciais padrão da aplicação. Para mais informações, consulte o artigo Configure 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 se autenticar no Monitoring, configure as Credenciais padrão da aplicação. Para mais informações, consulte o artigo Configure 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 se autenticar no Monitoring, configure as Credenciais padrão da aplicação. Para mais informações, consulte o artigo Configure 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 se autenticar no Monitoring, configure as Credenciais padrão da aplicação. Para mais informações, consulte o artigo Configure 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 se autenticar no Monitoring, configure as Credenciais padrão da aplicação. Para mais informações, consulte o artigo Configure 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 se autenticar no Monitoring, configure as Credenciais padrão da aplicação. Para mais informações, consulte o artigo Configure 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 tem campos adicionais. A própria política tem os campos name, creationRecord e mutationRecord. Além disso, cada condição na política também recebe um name. Estes campos não podem ser modificados externamente, pelo que não é necessário defini-los quando cria uma política. Nenhum dos exemplos JSON usados para criar políticas as inclui, mas, se as políticas criadas a partir deles forem obtidas após a criação, os campos estarão presentes.

Configure notificações repetidas para políticas de alerta baseadas em métricas

Por predefinição, uma política de alertas baseada em métricas envia uma notificação a cada canal de notificação quando um incidente é aberto. No entanto, pode alterar o comportamento predefinido e configurar uma política de alertas para reenviar notificações para todos ou alguns dos canais de notificação da sua política de alertas. Estas notificações repetidas são enviadas para incidentes com o estado Aberto ou Confirmado. O intervalo entre estas notificações tem de ser, pelo menos, de 30 minutos e, no máximo, de 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 as notificações repetidas.

    Se alterar o valor do campo renotifyInterval quando um incidente para a política de alertas é aberto, ocorre o seguinte:

    • A política de alerta envia outra notificação para o incidente.
    • A política de alerta reinicia o período do intervalo.

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

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

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

Para parar temporariamente as notificações repetidas, crie uma suspensão. Para evitar notificações repetidas, edite a política de alertas através da API e remova o objeto NotificationChannelStrategy.

O que se segue?