Crea criteri di avviso utilizzando l'API

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

Questo documento descrive quanto segue:

  • Il modo in cui l'API Monitoring rappresenta i criteri di avviso.
  • I tipi di condizioni forniti dall'API Monitoring per i criteri di avviso.
  • Scopri come creare un criterio di avviso utilizzando l'interfaccia a riga di comando o le librerie client di Google Cloud.

Struttura di un criterio di avviso

La struttura AlertPolicy definisce i componenti di un criterio di avviso. Quando crei un criterio, utilizzando la console Google Cloud o l'API Monitoring, devi specificare i valori per i seguenti campi AlertPolicy:

  • displayName: un'etichetta descrittiva della norma.
  • documentation: qualsiasi informazione fornita per aiutare gli intervistati. Questo campo è facoltativo. L'oggetto documentation include quanto segue:
    • content: testo definito dall'utente visualizzato nel corpo della notifica.
    • subject: la riga dell'oggetto della notifica. Le righe dell'oggetto non possono superare i 255 caratteri.
  • userLabels: qualsiasi etichetta definita dall'utente associata al criterio. Per informazioni sull'utilizzo delle etichette con gli avvisi, consulta Annota gli avvisi con le etichette.
  • conditions[]: un array di strutture di Condition.
  • combiner: un operatore logico che determina come gestire più condizioni.
  • notificationChannels[]: un array di nomi di risorse, ciascuno dei quali identifica un NotificationChannel.
  • alertStrategy: specifica la velocità con cui Monitoring chiude gli incidenti quando non arrivano i dati. Questo oggetto specifica inoltre se le notifiche ripetute sono abilitate per gli avvisi basati su metriche e l'intervallo tra queste notifiche. Per ulteriori informazioni, consulta Inviare notifiche ripetute.

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

Per impostazione predefinita, i criteri di avviso creati utilizzando l'API Monitoring inviano notifiche quando viene soddisfatta una condizione per l'attivazione del criterio e quando la condizione smette di essere soddisfatta. Non puoi modificare questo comportamento utilizzando l'API Monitoring, ma puoi disattivare le notifiche sulla chiusura degli incidenti modificando il criterio nella console Google Cloud. Per disattivare le notifiche di chiusura degli incidenti, deseleziona l'opzione Invia notifica alla chiusura di un incidente nella sezione delle notifiche e salva il criterio modificato.

Quando crei o modifichi il criterio di avviso, Monitoring imposta anche altri campi, tra cui 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

Le condizioni del criterio di avviso sono la parte più variabile del criterio di avviso.

Tipi di condizioni nell'API

L'API Cloud Monitoring supporta diversi 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 seguenti sezioni descrivono i tipi di condizioni disponibili.

Condizioni per i criteri di avviso basati su metriche

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

Condizioni delle metriche basate su filtri

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

Se utilizzi il tipo di condizione MetricAbsence, puoi creare una condizione che si attivi solo quando tutte le serie temporali sono assenti aggregando le serie temporali in un'unica serie temporale utilizzando aggregations. Consulta il riferimento a MetricAbsence nella documentazione dell'API.

Un criterio di avviso per l'assenza di metriche richiede che alcuni dati siano stati scritti in precedenza; per saperne di più, consulta Creare criteri di avviso per l'assenza di metriche.

Se vuoi creare un avviso basato su una previsione, utilizza il tipo di condizione MetricThreshold e imposta il campo forecastOptions. Se questo campo viene omesso, i dati misurati vengono confrontati con una soglia. Tuttavia, quando questo campo viene impostato, i dati previsti vengono confrontati con una soglia. Per ulteriori informazioni, consulta Creare criteri di avviso relativi ai valori delle metriche previsti.

Condizioni delle 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 per confrontare i valori con una soglia o verificare l'assenza di valori con questo tipo di condizione. Se utilizzi una condizione MonitoringQueryLanguageCondition, deve essere l'unica condizione nel criterio di avviso. Per maggiori informazioni, consulta Criteri di avviso con MQL.

Condizioni delle metriche basate su PromQL

La condizione PrometheusQueryLanguageCondition utilizza le query Prometheus Query Language (PromQL) per selezionare e manipolare i dati delle serie temporali da monitorare. Puoi creare una query semplice o complessa e utilizzare strutture di query come soglie dinamiche, rapporti, confronti di metriche e altro ancora.

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

Condizioni per gli avvisi sui rapporti

Puoi creare criteri di avviso per soglia di 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 le condizioni basate su rapporti utilizzando l'interfaccia grafica per creare condizioni di soglia.

Consigliamo di utilizzare MQL per creare criteri di avviso basati su un rapporto. MQL consente di creare query più efficaci e flessibili di quelle che puoi creare utilizzando il tipo di condizione MetricTheshold e i filtri di Monitoring. Ad esempio, con una condizione MonitoringQueryLanguageCondition, puoi calcolare il rapporto tra una metrica indicatore e una metrica delta. Per alcuni esempi, consulta gli 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, è preferibile calcolare i rapporti in base a serie temporali raccolte per un singolo tipo di metrica, utilizzando i valori delle etichette. Un rapporto calcolato per due diversi tipi di metriche è soggetto ad anomalie dovute ai diversi periodi di campionamento e alle finestre di allineamento.

Ad esempio, supponiamo di avere due diversi tipi di metriche, un conteggio totale delle RPC e un conteggio degli errori RPC, e di voler calcolare il rapporto delle RPC rispetto al totale delle RPC. Le RPC non riuscite vengono conteggiate nella serie temporale di entrambi i tipi di metriche. Pertanto, è possibile che, quando allinei le serie temporali, 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 serie temporali diverse che registrano lo stesso evento, esistono due valori contatore sottostanti che implementano la raccolta e i valori non vengono aggiornati a livello atomico.
  • Le frequenze di campionamento potrebbero essere diverse. Quando le serie temporali sono allineate a un periodo comune, i conteggi per 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 del rapporto error/total senza senso, come 1/0 o 2/1.

I rapporti di numeri più grandi hanno meno probabilità di generare valori incomprensibili. Puoi ottenere numeri più elevati tramite 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 dato intervallo. Ciò significa che 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 usi tipi di metriche integrate, potresti non avere altra scelta che calcolare i rapporti tra i tipi di metriche per ottenere il valore di cui hai bisogno.

Se stai progettando metriche personalizzate che potrebbero conteggiare gli stessi elementi, ad esempio le RPC che restituiscono lo stato di errore, in due metriche diverse, prendi in considerazione una singola metrica, che include ogni conteggio una sola volta. Ad esempio, supponiamo che tu stia conteggiando le RPC e che tu voglia monitorare il rapporto tra le RPC non riuscite e tutte le RPC. Per risolvere il problema, crea un singolo tipo di metrica per conteggiare le RPC e utilizza un'etichetta per registrare lo stato della chiamata, 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 invii una notifica quando nelle voci di log viene visualizzato un messaggio che corrisponde al filtro, utilizza il tipo di condizione LogMatch. Se utilizzi una condizione LogMatch, deve essere l'unica condizione nel criterio di avviso.

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

I criteri di avviso utilizzati negli esempi del documento Gestione dei criteri di avviso sono criteri di avviso basati su metriche, sebbene siano gli stessi di quelli basati su log. Per informazioni specifiche sui criteri di avviso basati su log, consulta Creare un avviso basato su log (API Monitoring) nella documentazione di Cloud Logging.

Prima di iniziare

Prima di scrivere codice nell'API, devi:

  • Acquisisci familiarità con i concetti generali e la terminologia utilizzati con i criteri di avviso. Per ulteriori informazioni, consulta la Panoramica degli avvisi.
  • Assicurati che l'API Cloud Monitoring sia abilitata per l'utilizzo; consulta Abilitazione dell'API per ulteriori informazioni.
  • Se prevedi di utilizzare librerie client, installa le librerie per i linguaggi che vuoi utilizzare. Per i dettagli, consulta Librerie client. 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 è già installato.

    Qui vengono forniti anche esempi di utilizzo dell'interfaccia gcloud. Tieni presente che tutti gli esempi gcloud presuppongono che il progetto corrente sia già stato impostato come destinazione (gcloud config set project [PROJECT_ID]), pertanto le chiamate omettono il flag --project esplicito. L'ID del progetto corrente 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 il ruolo IAM Editor AlertPolicy Monitoring (roles/monitoring.alertPolicyEditor) per il tuo progetto. Per saperne di più sulla concessione dei ruoli, consulta Gestire l'accesso.

    Potresti anche essere in grado di 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 per chiamate API Cloud Monitoring a thread singolo che modificano lo stato di un criterio di avviso in un progetto Google Cloud. Ad esempio, chiamate API a thread singolo che creano, aggiornano o eliminano un criterio di avviso.

crea un criterio di avviso

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

Puoi creare criteri 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 criteri da questi file utilizzando il metodo alertPolicies.create. Se hai un file di configurazione JSON o YAML Prometheus con una regola di avviso, gcloud CLI può eseguirne la migrazione a un criterio di avviso di Cloud Monitoring con una condizione PromQL. Per maggiori informazioni, consulta Eseguire la migrazione delle regole di avviso e dei ricevitori 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 500 criteri. 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.

I seguenti esempi illustrano la creazione di criteri di avviso, ma non descrivono come creare un file JSON o YAML che descrive un criterio di avviso. Gli esempi presuppongono invece che esista un file in formato JSON e illustrano come eseguire la chiamata API. Ad esempio, vedi Criteri di esempio per i file JSON. 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"

In caso di 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 per un criterio con il nome visualizzato "Alta frequenza di modifica della CPU". Per i dettagli su questo criterio, consulta la sezione Criterio di frequenza di modifica.

Consulta il riferimento gcloud alpha monitoring policies create per ulteriori informazioni.

C#

Per eseguire l'autenticazione in Monitoring, configura Credenziali predefinite dell'applicazione. Per maggiori informazioni, consulta Configurare 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 eseguire l'autenticazione in Monitoring, configura Credenziali predefinite dell'applicazione. Per maggiori informazioni, consulta Configurare 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 eseguire l'autenticazione in Monitoring, configura Credenziali predefinite dell'applicazione. Per maggiori informazioni, consulta Configurare 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 eseguire l'autenticazione in Monitoring, configura Credenziali predefinite dell'applicazione. Per maggiori informazioni, consulta Configurare 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 eseguire l'autenticazione in Monitoring, configura Credenziali predefinite dell'applicazione. Per maggiori informazioni, consulta Configurare l'autenticazione per un ambiente di sviluppo locale. 

use Google\Cloud\Monitoring\V3\AlertPolicyServiceClient;
use Google\Cloud\Monitoring\V3\AlertPolicy;
use Google\Cloud\Monitoring\V3\ComparisonType;
use Google\Cloud\Monitoring\V3\AlertPolicy\Condition;
use Google\Cloud\Monitoring\V3\AlertPolicy\Condition\MetricThreshold;
use Google\Cloud\Monitoring\V3\AlertPolicy\ConditionCombinerType;
use Google\Protobuf\Duration;

/**
 * @param string $projectId Your project ID
 */
function alert_create_policy($projectId)
{
    $alertClient = new AlertPolicyServiceClient([
        'projectId' => $projectId,
    ]);
    $projectName = $alertClient->projectName($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,
        ])
    ])]);

    $policy = $alertClient->createAlertPolicy($projectName, $policy);
    printf('Created alert policy %s' . PHP_EOL, $policy->getName());
}

Python

Per eseguire l'autenticazione in Monitoring, configura Credenziali predefinite dell'applicazione. Per maggiori informazioni, consulta Configurare 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à campi name, creationRecord e mutationRecord. Inoltre, a ogni condizione nel criterio viene assegnato anche un name. Questi campi non possono essere modificati esternamente, quindi non è necessario impostarli durante la creazione di un criterio. Nessuno degli esempi JSON utilizzati per la creazione dei criteri li include, ma se i criteri creati da questi vengono recuperati dopo la creazione, i campi saranno presenti.

Passaggi successivi