Creare criteri di avviso utilizzando l'API

Un criterio di avviso è rappresentato nell'API Cloud Monitoring da un oggetto AlertPolicy, che descrive un insieme di condizioni che indicano uno stato potenzialmente non integro nel tuo sistema.

Questo documento descrive quanto segue:

• Come l'API Monitoring rappresenta i criteri di avviso.
• I tipi di condizioni forniti dall'API Monitoring per i criteri di avviso.
• Come creare una criterio di avviso utilizzando Google Cloud CLI o le librerie client.

Questa funzionalità è supportata solo per i progetti Google Cloud . Per le configurazioni di App Hub, seleziona il progetto host di App Hub o il progetto di gestione della cartella app.

Struttura di un criterio di avviso

La struttura AlertPolicy definisce i componenti di una criterio di avvisoo. Quando crei un criterio, specifichi i valori per i seguenti campi AlertPolicy:

• displayName: un'etichetta descrittiva per la policy.
• documentation: ti consigliamo di utilizzare questo campo per fornire informazioni utili per i responsabili della risposta agli incidenti. Per saperne di più, consulta la pagina Annotare le notifiche con la documentazione definita dall'utente.

• userLabels: eventuali etichette definite dall'utente associate al criterio. Policy di avviso, incidenti e notifiche mostrano queste etichette. Per informazioni sull'utilizzo delle etichette con gli avvisi, vedi Annotare gli incidenti con le etichette.

• conditions[]: un array di strutture Condition.

• combiner: un operatore logico che determina la modalità di gestione di più condizioni.

• notificationChannels[]: un array di nomi di risorse, ognuno dei quali identifica un NotificationChannel.

• alertStrategy: specifica quanto segue:

  • La velocità con cui Monitoring chiude gli incidenti quando i dati smettono di arrivare.
  • Per le policy di avviso basate su metriche, indica se Monitoring invia una notifica quando un incidente viene chiuso.
  • Per le norme di avviso basate su metriche, se le notifiche ripetute sono attive e l'intervallo tra queste notifiche. Per ulteriori informazioni, consulta Configurare le notifiche ripetute per i criteri di avviso basati su metriche.

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à degli incidenti. Se non specifichi una gravità, Cloud Monitoring imposta la gravità del criterio di avviso su No Severity.

A seconda delle condizioni che crei, puoi utilizzare altri campi.

Quando un criterio di avviso contiene una condizione, viene inviata una notifica quando questa condizione viene soddisfatta. Per informazioni sulle notifiche quando i criteri di avviso contengono più condizioni, consulta Criteri con più condizioni e Numero di notifiche per criterio.

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

projects/PROJECT_ID/alertPolicies/POLICY_ID

Nell'espressione precedente:

• PROJECT_ID: l'identificatore del progetto. Per le configurazioni di App Hub, seleziona il progetto host di App Hub o il progetto di gestione della cartella app.
• POLICY_ID: l'ID del criterio di avviso

Tipi di condizioni nell'API

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

Condizioni per i criteri di avviso basati su metriche

Per creare una criterio di avviso che monitori i dati delle metriche, incluse le metriche basate sui log, puoi utilizzare i seguenti tipi di condizioni:

• MetricAbsence
• MetricThreshold
• MonitoringQueryLanguageCondition
• PrometheusQueryLanguageCondition

Condizioni delle metriche basate sui filtri

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

Se utilizzi il tipo di condizione MetricAbsence, puoi creare una condizione soddisfatta solo quando tutte le serie temporali sono assenti. Questa condizione utilizza il parametro aggregations per aggregare più serie temporali in una singola serie temporale. Per saperne di più, consulta il riferimento MetricAbsence nella documentazione dell'API.

Una criterio di avviso per assenza di metriche richiede che alcuni dati siano stati scritti in precedenza. Per saperne di più, consulta Creare policy di avviso per assenza di metriche.

Se vuoi ricevere una notifica in base a un valore previsto, configura il criterio di avviso in modo che utilizzi il tipo di condizione MetricThreshold e imposta il campo 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 una soglia. Per saperne di più, vedi Creare criteri di avviso basati sui valori delle metriche previsti.

Condizioni per le metriche basate su MQL

La condizione MonitoringQueryLanguageCondition utilizza Monitoring Query Language (MQL) per selezionare e manipolare i dati delle serie temporali da monitorare. Puoi creare criteri di avviso 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 condizione nellacriterio di avvisoo. Per ulteriori informazioni, consulta Policy di avviso con MQL.

Condizioni per le metriche basate su PromQL

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

Se utilizzi una condizione PrometheusQueryLanguageCondition, deve essere l'unica condizione nellacriterio di avvisoo. Per ulteriori informazioni, consulta Policy di avviso con PromQL.

Condizioni per gli avvisi sui rapporti

Puoi creare criteri di avviso basati su soglie delle metriche per monitorare il rapporto tra 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 sul rapporto utilizzando l'interfaccia grafica per la creazione di condizioni di soglia.

Ti consigliamo di utilizzare MQL per creare policy di avviso basate sul rapporto. MQL ti consente di creare query più potenti e flessibili rispetto a quelle che puoi creare utilizzando il tipo di condizione MetricTheshold e i filtri di monitoraggio. Ad esempio, con una condizione MonitoringQueryLanguageCondition, puoi calcolare il rapporto tra una metrica di indicatore e una metrica delta. Per esempi, vedi Esempi di criteri di avviso MQL.

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

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

Ad esempio, supponiamo di avere due tipi di metriche diversi, un conteggio totale delle RPC e un conteggio degli errori RPC, e di voler calcolare il rapporto tra le RPC con conteggio degli errori e le RPC totali. Le RPC non riuscite vengono conteggiate nella serie temporale di entrambi i tipi di metriche. Pertanto, quando allinei le serie temporali, è possibile che una RPC non riuscita non venga visualizzata nello stesso intervallo di allineamento per entrambe le serie temporali. Questa differenza può verificarsi per diversi motivi, tra cui:

• Poiché esistono due diverse serie temporali che registrano lo stesso evento, esistono due valori di contatore sottostanti che implementano la raccolta e non vengono aggiornati in modo atomico.
• Le frequenze di campionamento potrebbero essere diverse. Quando le serie temporali sono allineate a un periodo comune, i conteggi di un singolo evento potrebbero essere visualizzati in intervalli di allineamento adiacenti nelle serie temporali per le diverse metriche.

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

È meno probabile che i rapporti tra numeri più grandi generino valori privi di significato. Puoi ottenere numeri più grandi tramite l'aggregazione, utilizzando una finestra di allineamento più lunga del periodo di campionamento o raggruppando i dati per determinate etichette. Queste tecniche riducono al minimo l'effetto di piccole differenze nel numero di punti in un determinato intervallo. ovvero una disparità di due punti è più significativa quando il numero previsto di punti in un intervallo è 3 rispetto a quando il numero previsto è 300.

Se utilizzi tipi di metriche integrati, potresti non avere altra scelta che calcolare i rapporti tra i tipi di metriche per ottenere il valore che ti serve.

Se stai progettando metriche personalizzate che potrebbero conteggiare la stessa cosa, ad esempio le chiamate RPC che restituiscono lo stato di errore, in due metriche diverse, valuta la possibilità di utilizzare una singola metrica, che include ogni conteggio una sola volta. Ad esempio, supponiamo di conteggiare le RPC e di voler monitorare il rapporto tra le RPC non riuscite e tutte le RPC. Per risolvere questo problema, crea un singolo tipo di metrica per conteggiare le RPC e utilizza un'etichetta per registrare lo stato dell'invocazione, incluso lo stato "OK". Quindi, ogni valore di stato, errore 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 corrispondente al tuo filtro viene visualizzato nelle voci di log, utilizza il tipo di condizione LogMatch. Se utilizzi una condizione LogMatch, deve essere l'unica condizione nella criterio di avviso.

Non tentare di utilizzare il tipo di condizione LogMatch in combinazione con metriche basate sui log. I criteri di avviso che monitorano le metriche basate su log sono criteri basati su metriche. Per ulteriori informazioni su come scegliere tra criteri di avviso che monitorano metriche basate su log o voci di log, consulta Monitoraggio dei log.

I criteri di avviso utilizzati negli esempi del documento Gestire i criteri di avviso tramite API sono criteri di avviso basati su metriche, anche se i principi sono gli stessi per i criteri di avviso basati su log. Per informazioni specifiche sulle policy di avviso basate su log, consulta Creare una criterio di avviso basata su log utilizzando l'API Monitoring nella documentazione di Cloud Logging.

Come associare un criterio di avviso a un'applicazione App Hub

Google Cloud genera dashboard che ti aiutano a monitorare le tue applicazioni App Hub. Queste dashboard mostrano informazioni come i dati di log e delle metriche per le tue applicazioni e i servizi e i carichi di lavoro che fanno parte dell'applicazione. In queste dashboard vengono visualizzate anche le policy di avviso e i relativi incidenti, quando le policy sono associate al servizio o al workload di un'applicazione. Per saperne di più sul monitoraggio delle applicazioni, vedi Visualizzare la telemetria delle applicazioni.

Per associare un criterio di avviso a un'applicazione App Hub, aggiungi etichette con le seguenti chiavi al criterio:

• apphub_application_location
• apphub_application_id
• apphub_service_id o apphub_workload_id

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

Prima di iniziare

Prima di scrivere codice per l'API, devi:

• Acquisisci familiarità con i concetti generali e la terminologia utilizzati con le policy di avviso. Per maggiori informazioni, consulta la panoramica degli avvisi.
• Assicurati che l'API Cloud Monitoring sia abilitata all'uso. Per ulteriori informazioni, consulta la sezione Abilitazione dell'API.
• Se prevedi di utilizzare le librerie client, installale per le lingue che vuoi utilizzare. Per maggiori dettagli, consulta la sezione Librerie client. Il supporto delle API per gli avvisi è disponibile solo per C#, Go, Java, Node.js e Python.

• Se prevedi di utilizzare Google Cloud CLI, installala. Tuttavia, se utilizzi Cloud Shell, Google Cloud CLI è già installato.

  Qui sono forniti anche esempi che utilizzano l'interfaccia gcloud. Tieni presente che tutti gli esempi di gcloud presuppongono che il progetto attuale sia già stato impostato come target (gcloud config set project [PROJECT_ID]), quindi le chiamate omettono il flag --project esplicito. L'ID del progetto corrente negli esempi è a-gcp-project. Per le configurazioni di App Hub, seleziona il progetto host di App Hub o il progetto di gestione della cartella app.

• Per ottenere le autorizzazioni necessarie per creare e modificare le policy di avviso utilizzando l'API Cloud Monitoring, chiedi all'amministratore di concederti il ruolo IAM Monitoring AlertPolicy Editor (roles/monitoring.alertPolicyEditor) sul progetto. Per saperne di più sulla concessione dei ruoli, consulta Gestisci l'accesso a progetti, cartelle e organizzazioni.

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

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

• Progetta la tua applicazione in modo da eseguire chiamate API Cloud Monitoring a thread singolo che modificano lo stato di unacriterio di avvisoo in un progettoGoogle Cloud . Ad esempio, chiamate API a thread singolo che creano, aggiornano o eliminano un criterio di avviso.

Crea un criterio di avviso

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

Puoi creare policy da file JSON o YAML. Google Cloud CLI accetta questi file come argomenti e puoi leggere i file JSON in modo programmatico, convertirli in oggetti AlertPolicy e creare policy a partire da questi utilizzando il metodo alertPolicies.create. Se hai un file di configurazione Prometheus JSON o YAML con una regola di avviso, allora gcloud CLI può eseguirne la migrazione a una policy di avviso di Cloud Monitoring con una condizione PromQL. Per maggiori informazioni, consulta la pagina Eseguire la migrazione di regole di avviso e destinatari da Prometheus.

Ogni criterio di avviso appartiene a un progetto di definizione dell'ambito di un ambito delle metriche. Ogni progetto può contenere fino a 2000 norme. Per le chiamate API, devi fornire un "ID progetto"; utilizza l'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 non descrivono come creare un file JSON o YAML che descriva un criterio di avviso. Gli esempi, invece, presuppongono l'esistenza di un file in formato JSON e mostrano come effettuare la chiamata API. Per esempi di file JSON, consulta Policy di esempio. Per informazioni generali sul monitoraggio dei rapporti tra le metriche, consulta Rapporti tra le metriche.

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

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

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);
    }
}

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

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()));
    }
  }
}

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();

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());
}

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. La norma stessa avrà i campi name, creationRecord e mutationRecord. Inoltre, a ogni condizione delle norme 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 la creazione dei criteri li include, ma se i criteri creati a partire da questi vengono recuperati dopo la creazione, i campi saranno presenti.

Configurare notifiche ripetute per i criteri di avviso basati su metriche

Per impostazione predefinita, una criterio di avviso basata su metriche invia una notifica a ogni canale di notifica quando viene aperto un incidente. Tuttavia, puoi modificare il comportamento predefinito e configurare un criterio di avviso per inviare nuovamente le notifiche a tutti o ad alcuni dei canali di notifica per il criterio di avviso. Queste notifiche ripetute vengono inviate per gli incidenti con stato Aperto o Confermato. L'intervallo tra queste notifiche deve essere di almeno 30 minuti e non superiore a 24 ore, espresso in secondi.

Per configurare le notifiche ripetute, aggiungi alla configurazione della criterio di avviso un oggetto AlertStrategy che contenga almeno un oggetto NotificationChannelStrategy. Un oggetto NotificationChannelStrategy ha due campi:

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

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

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

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

Ad esempio, il seguente campione 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 posticipo. Per evitare notifiche ripetute, modifica lacriterio di avvisoo utilizzando l'API e rimuovi l'oggetto NotificationChannelStrategy.

Passaggi successivi

• Gestire i criteri di avviso tramite API
• Creare e gestire i canali di notifica tramite API