Crea criteri di avviso con l'API

Nell'API Cloud Monitoring è rappresentato un criterio di avviso da un oggetto AlertPolicy, che descrive una serie di condizioni che indicano non integro del sistema.

In questo documento vengono descritte le seguenti informazioni:

  • Rappresentazione dei criteri di avviso da parte dell'API Monitoring.
  • I tipi di condizioni forniti dall'API Monitoring criteri di avviso.
  • Come creare un criterio di avviso utilizzando Google Cloud CLI librerie client.

Struttura di un criterio di avviso

La struttura AlertPolicy definisce i componenti di un criterio di avviso. Quando crei un criterio, specifichi i valori per il parametro seguenti campi AlertPolicy:

Puoi anche specificare il campo severity quando utilizzi l'API Cloud Monitoring e la console Google Cloud. Questo campo consente di definire il livello di gravità e i relativi incidenti. Se non specifichi una gravità, Cloud Monitoring imposta la gravità del criterio di avviso su No Severity.

Esistono altri campi che puoi utilizzare, a seconda delle condizioni che crei.

Quando un criterio di avviso contiene una condizione, viene inviata una notifica se la condizione è soddisfatta. Per informazioni sulle notifiche durante gli avvisi contengono più condizioni, consulta Norme con più condizioni e Numero di notifiche per criterio.

Quando crei o modifichi il criterio di avviso, Monitoring imposta anche altri campi, tra cui il campo name. Il valore dell'attributo name è il nome della risorsa per il criterio di avviso, che identifica . Il nome della risorsa ha il seguente formato:

projects/PROJECT_ID/alertPolicies/POLICY_ID

Tipi di condizioni nell'API

L'API Cloud Monitoring supporta vari tipi di condizioni nel Struttura di Condition. Esistono più condizioni per i criteri di avviso basati su metriche e uno per quelli basati su log criteri. Le seguenti sezioni descrivono i tipi di condizioni disponibili.

Condizioni per i criteri di avviso basati su metriche

Creare un criterio di avviso che monitori i dati delle metriche, inclusi quelli basati su log puoi utilizzare i seguenti tipi di condizioni:

Condizioni per le metriche basate su filtri

Le condizioni MetricAbsence e MetricThreshold utilizzano Filtri di Monitoring per selezionare i dati delle serie temporali da monitorare. Gli altri campi nella struttura delle condizioni specificano come filtrare, raggruppare e aggregare i dati. Per ulteriori informazioni su questi concetti, consulta Filtri e aggregazione: manipolazione delle serie temporali.

Se utilizzi il tipo di condizione MetricAbsence, puoi creare una condizione che viene soddisfatta solo quando tutte le serie temporali sono assenti. Questa condizione utilizza Il parametro aggregations per aggregare più serie temporali in un'unica serie temporali. Per ulteriori informazioni, vedi come riferimento a MetricAbsence nella documentazione dell'API.

Un criterio di avviso per l'assenza della metrica richiede la scrittura di alcuni dati in precedenza; Per ulteriori informazioni, vedi Creare criteri di avviso per l'assenza di metriche

Se vuoi ricevere notifiche in base a un valore previsto, configura il criterio di avviso per utilizzare tipo di condizione MetricThreshold e per impostare forecastOptions . Quando questo campo non è impostato, i dati misurati vengono confrontati con una soglia. Tuttavia, quando questo campo è impostato, i dati previsti vengono confrontati con un soglia. Per ulteriori informazioni, vedi Crea criteri di avviso relativi al valore della metrica previsti.

Condizioni delle metriche basate su MQL

La condizione MonitoringQueryLanguageCondition utilizza Monitoring Query Language (MQL) per selezionare e manipolare i dati della serie temporale da monitorare. Puoi creare avvisi Criteri che confrontano i valori con una soglia o verificano l'assenza di valori con questo tipo di condizione. Se utilizzi una condizione MonitoringQueryLanguageCondition, deve essere l'unica nel criterio di avviso. Per ulteriori informazioni, vedi Criteri di avviso con MQL.

Condizioni delle metriche basate su PromQL

La condizione PrometheusQueryLanguageCondition utilizza Prometheus Query Language (PromQL) per selezionare e manipolare i dati delle serie temporali da monitorare. La condizione può calcolare un rapporto di metriche, valutare confronti di metriche e altro ancora.

Se utilizzi una condizione PrometheusQueryLanguageCondition, deve essere l'unica nel criterio di avviso. Per ulteriori informazioni, vedi Criteri di avviso con PromQL.

Condizioni per avvisi sui rapporti

Puoi creare criteri di avviso con soglia di metrica per monitorare di due metriche. Puoi creare questi criteri utilizzando il tipo di condizione MetricThreshold o MonitoringQueryLanguageCondition. Puoi anche utilizzare MQL direttamente nella console Google Cloud. Non puoi creare o gestire condizioni basate su rapporti utilizzando l'interfaccia grafica per la creazione condizioni di soglia.

Ti consigliamo di utilizzare MQL per creare criteri di avviso basati su un rapporto. MQL consente di creare query più potenti e flessibili di quanto tu possa utilizzando il tipo di condizione MetricTheshold Filtri di monitoraggio. Ad esempio, con una condizione MonitoringQueryLanguageCondition, puoi calcolare il rapporto tra una metrica misuratore e una metrica delta. Per alcuni esempi, vedi Esempi di criteri di avviso MQL.

Se utilizzi la condizione MetricThreshold, il numeratore e il denominatore di questo rapporto deve avere lo stesso MetricKind. Per un elenco delle metriche e delle relative proprietà, consulta Elenchi di metriche.

In generale, è meglio calcolare i rapporti in base alle serie temporali raccolte per: un singolo tipo di metrica, usando i valori delle etichette. Un rapporto calcolato su due tipi di metriche diversi sono soggetti ad anomalie dovute a campionamenti diversi periodi e finestre di allineamento.

Ad esempio, supponiamo che tu abbia due tipi di metriche diversi, un valore e un conteggio degli errori RPC e vuoi calcolare il rapporto RPC su RPC totali. Le RPC non riuscite vengono conteggiate nella serie temporale entrambi i tipi di metriche. Pertanto, esiste la possibilità che, quando allinei i tempi una RPC non riuscita non viene visualizzata nello stesso intervallo di allineamento entrambe le serie temporali. Questa differenza può verificarsi per diversi motivi, tra cui:

  • Poiché esistono due diverse serie temporali che registrano lo stesso evento, sono due controvalori sottostanti che implementano la raccolta e che non vengono aggiornati a livello atomico.
  • Le frequenze di campionamento possono variare. Quando le serie temporali sono allineate a un periodo, i conteggi di un singolo evento potrebbero essere visualizzati in un allineamento adiacente intervalli di tempo nella serie temporale per le diverse metriche.

La differenza nel numero di valori negli intervalli di allineamento corrispondenti può Portano a valori di rapporto di error/total privi di senso, come 1/0 o 2/1.

I rapporti di numeri maggiori hanno meno probabilità di generare valori senza senso. Puoi ottenere numeri più grandi tramite aggregazione, utilizzando una finestra di allineamento ovvero maggiore rispetto al periodo di campionamento o raggruppando i dati per determinati etichette. Queste tecniche riducono al minimo l'effetto di piccole differenze nel numero di punti in un intervallo dato. In altre parole, una disparità di due punti è maggiore significativa quando il numero previsto di punti in un intervallo è 3 rispetto a quando il numero previsto è 300.

Se utilizzi i tipi di metriche integrati, potresti non avere altra scelta i rapporti tra i vari tipi di metriche per ottenere il valore di cui hai bisogno.

Se stai progettando metriche personalizzate che potrebbero conteggiare la stessa cosa, ad esempio RPC che restituiscono stato di errore: in due metriche diverse, prendi in considerazione una singola metrica, che include ogni conteggio una sola volta. Ad esempio, supponiamo che che stai conteggiando le RPC e di voler monitorare il rapporto da RPC a tutte le RPC. Per risolvere il problema, creare un singolo tipo di metrica per contare le RPC e utilizzare un'etichetta per registrare stato della chiamata, incluso "OK" . Quindi ogni valore di stato o "OK" viene registrato aggiornando un singolo contatore per quel caso.

Condizione per i criteri di avviso basati su log

Per creare un criterio di avviso basato su log che ti avvisa quando un messaggio il filtro corrispondente al filtro viene visualizzato nelle voci di log, utilizza LogMatch tipo di condizione. Se utilizzi un LogMatch , deve essere l'unica condizione nel criterio di avviso.

Non provare a utilizzare il tipo di condizione LogMatch insieme a quello basato su log metrics. I criteri di avviso che monitorano le metriche basate su log sono basati su metriche criteri. Per ulteriori informazioni sulla scelta tra criteri di avviso monitorare le metriche o le voci di log basate su log, consulta Monitoraggio dei log.

I criteri di avviso utilizzati negli esempi della Il documento Gestisci criteri di avviso per API è basato su metriche avviso anche se i principi sono gli stessi per i criteri di avviso basati su log. Per informazioni specifiche sui criteri di avviso basati su log, consulta Crea un criterio di avviso basato su log utilizzando l'API Monitoring nella documentazione di Cloud Logging.

Prima di iniziare

Prima di scrivere il codice sull'API, devi:

  • Avere familiarità con i concetti generali e la terminologia utilizzata con gli avvisi norme; Per saperne di più, consulta Panoramica degli avvisi informazioni.
  • Assicurati che l'API Cloud Monitoring sia abilitata per l'uso. vedi Per ulteriori informazioni, abilita l'API.
  • Se prevedi di utilizzare le librerie client, installa le librerie per le lingue che vuoi usare; vedi Librerie client per i dettagli. Attualmente, il supporto API per gli avvisi è disponibile solo per C#, Go, Java, Node.js e Python.

  • Se prevedi di utilizzare Google Cloud CLI, installalo. Tuttavia, se utilizzi Cloud Shell, Google Cloud CLI sarà è già installata.

    Qui vengono forniti anche esempi che utilizzano l'interfaccia gcloud. Tieni presente che tutti gli esempi gcloud presuppongono che il progetto attuale abbia già impostato come target (gcloud config set project [PROJECT_ID]) quindi le chiamate omettono il flag --project esplicito. ID del progetto attuale negli esempi è a-gcp-project.

  • Per ottenere le autorizzazioni necessarie per creare e modificare i criteri di avviso utilizzando l'API Cloud Monitoring, chiedi all'amministratore di concederti Ruolo IAM Monitoring AlertPolicy Editor (roles/monitoring.alertPolicyEditor) per il tuo progetto. Per saperne di più sulla concessione dei ruoli, consulta Gestire l'accesso.

    Potresti anche riuscire a ottenere le autorizzazioni richieste tramite la ruoli o altri ruoli predefiniti ruoli.

    Per informazioni dettagliate sui ruoli IAM per Monitoraggio, consulta Controlla l'accesso con Identity and Access Management.

  • Progetta la tua applicazione per chiamate API Cloud Monitoring a thread singolo che lo stato di un criterio di avviso progetto Google Cloud. Ad esempio, chiamate API a thread singolo che creano, aggiornano o eliminare un criterio di avviso.

Crea un criterio di avviso

Per creare un criterio di avviso in un progetto, utilizza alertPolicies.create. Per informazioni su come richiamare questo i relativi parametri e i dati di risposta, consulta la pagina di riferimento alertPolicies.create.

Puoi creare criteri dai file JSON o YAML. Google Cloud CLI accetta questi file come argomenti puoi leggere i file JSON in modo programmatico, convertirli in AlertPolicy oggetti e creare criteri a partire da questi utilizzando il metodo alertPolicies.create. Se un file di configurazione JSON o YAML Prometheus con una regola di avviso, gcloud CLI può eseguirne la migrazione a un Cloud Monitoring con una condizione PromQL. Per ulteriori informazioni, vedi Esegui la migrazione delle regole di avviso e dei destinatari da Prometheus.

Ogni criterio di avviso appartiene a un progetto di definizione dell'ambito relativo a un ambito delle metriche. Ciascuna il progetto può contenere fino a 500 criteri. Per le chiamate API, devi fornire un "ID progetto". utilizza la ID del progetto di definizione dell'ambito di un ambito delle metriche come valore. In questi esempi, l'ID del progetto di definizione dell'ambito di un ambito delle metriche è a-gcp-project.

Gli esempi riportati di seguito illustrano la creazione di criteri di avviso, ma come creare un file JSON o YAML che descriva un criterio di avviso. Gli esempi presuppongono invece che un file in formato JSON e le istruzioni per emettere la chiamata API. Ad esempio, i file JSON, consulta gli esempi di criteri. Per informazioni generali sul monitoraggio dei rapporti delle metriche, consulta Report delle metriche.

gcloud

Per creare un criterio di avviso in un progetto, utilizza il comando gcloud alpha monitoring policies create. L'esempio seguente crea un criterio di avviso in a-gcp-project dal file rising-cpu-usage.json:

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

Se l'esito è positivo, questo comando restituisce il nome del nuovo criterio, ad esempio:

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

Il file rising-cpu-usage.json contiene il codice JSON di un criterio con il nome visualizzato "High CPU rate of change". Per maggiori dettagli su queste norme, consulta Criterio di tasso di modifica.

Consulta le gcloud alpha monitoring policies create di riferimento per ulteriori informazioni.

C#

Per autenticarti a Monitoring, configura Credenziali predefinite dell'applicazione. Per ulteriori informazioni, vedi Configura l'autenticazione per un ambiente di sviluppo locale. 

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

Per autenticarti a Monitoring, configura Credenziali predefinite dell'applicazione. Per ulteriori informazioni, vedi Configura l'autenticazione per un ambiente di sviluppo locale. 


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

Per autenticarti a Monitoring, configura Credenziali predefinite dell'applicazione. Per ulteriori informazioni, vedi Configura l'autenticazione per un ambiente di sviluppo locale. 

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

Per autenticarti a Monitoring, configura Credenziali predefinite dell'applicazione. Per ulteriori informazioni, vedi Configura l'autenticazione per un ambiente di sviluppo locale. 

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

Per autenticarti a Monitoring, configura Credenziali predefinite dell'applicazione. Per ulteriori informazioni, vedi Configura l'autenticazione per un ambiente di sviluppo locale. 

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

Per autenticarti a Monitoring, configura Credenziali predefinite dell'applicazione. Per ulteriori informazioni, vedi Configura l'autenticazione per un ambiente di sviluppo locale. 

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)

L'oggetto AlertPolicy creato avrà campi aggiuntivi. Il criterio stesso avrà name, creationRecord e mutationRecord campi. Inoltre, a ogni condizione del criterio viene assegnato anche un name. Questi campi non possono essere modificati esternamente, quindi non è necessario impostarli quando crei un criterio. Nessuno degli esempi JSON utilizzati per creare i criteri che li includono, ma se i criteri creati da questi vengono recuperati dopo verranno visualizzati i campi.

Configura notifiche ripetute per i criteri di avviso basati sulle metriche

Per impostazione predefinita, un criterio di avviso basato su metriche invia una notifica a ogni notifica al momento dell'apertura di un incidente. Tuttavia, puoi modificare l'impostazione predefinita comportamento e configurare un criterio di avviso per inviare di nuovo le notifiche a tutti alcuni dei canali di notifica per il criterio di avviso. Queste notifiche ripetute vengono inviate per gli incidenti con lo stato Aperto o Confermato. L'intervallo tra queste notifiche deve essere di almeno 30 minuti e non più di 24 ore, espresse in secondi.

Per configurare notifiche ripetute, aggiungi un elemento alla configurazione del criterio di avviso un oggetto AlertStrategy che contiene almeno un oggetto NotificationChannelStrategy oggetto. Un oggetto NotificationChannelStrategy ha due campi:

  • renotifyInterval: l'intervallo, in secondi, tra notifiche.

    Se modifichi il valore del campo renotifyInterval quando viene aperto un incidente per il criterio di avviso, si verifica quanto segue:

    • Il criterio di avviso invia un'altra notifica dell'incidente.
    • Il criterio di avviso riavvia il periodo di intervallo.

  • notificationChannelNames: un array di nomi delle risorse del canale di notifica, ovvero stringhe nel formato projects/PROJECT_ID/notificationChannels/CHANNEL_ID, dove CHANNEL_ID è un valore numerico. Per informazioni su come recuperare l'ID canale, consulta: Elenca i canali di notifica in un progetto.

Ad esempio, il seguente esempio JSON mostra una strategia di avviso configurata per inviare notifiche ripetute ogni 1800 secondi (30 minuti) a un canale di notifica:

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

Per interrompere temporaneamente le notifiche ripetute, crea un posticipazione. A impedire notifiche ripetute, modificare il criterio di avviso utilizzando l'API e rimuovi l'oggetto NotificationChannelStrategy.

Passaggi successivi