Créer des règles d'alerte à l'aide de l'API

Une règle d'alerte est représentée dans l'API Cloud Monitoring par un objet AlertPolicy, qui décrit un ensemble de conditions indiquant un état potentiellement non opérationnel dans votre système.

Ce document décrit les éléments suivants:

Comment l'API Monitoring représente les règles d'alerte.
Types de conditions fournies par l'API Monitoring pour les règles d'alerte.
Créer une règle d'alerte à l'aide de la Google Cloud CLI ou des bibliothèques clientes

Structure d'une règle d'alerte

La structure AlertPolicy définit les composants d'une règle d'alerte. Lorsque vous créez une règle, vous spécifiez des valeurs pour les champs AlertPolicy suivants:

displayName : étiquette descriptive de la règle.
documentation : toute information fournie pour aider les personnes recevant la notification. Ce champ est facultatif. L'objet documentation inclut les éléments suivants :
- content: texte défini par l'utilisateur qui apparaît dans le corps de la notification.
- subject: objet de la notification L'objet ne doit pas dépasser 255 caractères.
userLabels: tous les libellés définis par l'utilisateur associés à la règle Pour en savoir plus sur l'utilisation de libellés avec les alertes, consultez Annoter les alertes avec des libellés.
conditions[] : tableau de structures Condition.
combiner : opérateur logique qui détermine comment gérer plusieurs conditions.
notificationChannels[] : tableau de noms de ressources, chacun identifiant une NotificationChannel.
alertStrategy: spécifie la vitesse à laquelle Monitoring ferme les incidents lorsque les données cessent d'arriver. Cet objet spécifie également si les notifications répétées sont activées pour les alertes basées sur des métriques, ainsi que l'intervalle entre ces notifications. Pour en savoir plus, consultez Envoyer des notifications répétées.

Vous pouvez également spécifier le champ severity lorsque vous utilisez l'API Cloud Monitoring et la console Google Cloud. Ce champ vous permet de définir le niveau de gravité des incidents. Si vous ne spécifiez pas de gravité, Cloud Monitoring définit le niveau de gravité de la règle d'alerte sur No Severity.

Vous pouvez utiliser d'autres champs, selon les conditions que vous créez.

Lorsqu'une règle d'alerte contient une condition, une notification est envoyée lorsque cette condition est remplie. Pour en savoir plus sur les notifications lorsque les règles d'alerte contiennent plusieurs conditions, consultez les sections Règles avec plusieurs conditions et Nombre de notifications par règle.

Lorsque vous créez ou modifiez la règle d'alerte, Monitoring définit d'autres champs, y compris le champ name. La valeur du champ name correspond au nom de la ressource pour la règle d'alerte, qui identifie la règle. Le nom de la ressource se présente sous la forme suivante :

projects/PROJECT_ID/alertPolicies/POLICY_ID

Types de conditions dans l'API

L'API Cloud Monitoring est compatible avec divers types de conditions dans la structure Condition. Il existe plusieurs types de conditions pour les règles d'alerte basées sur les métriques, et un type pour les règles d'alerte basées sur les journaux. Les sections suivantes décrivent les types de conditions disponibles.

Conditions pour les règles d'alerte basées sur des métriques

Pour créer une règle d'alerte qui surveille les données de métriques, y compris les métriques basées sur les journaux, vous pouvez utiliser les types de conditions suivants:

Conditions de métriques basées sur des filtres

Les conditions MetricAbsence et MetricThreshold utilisent des filtres Monitoring pour sélectionner les données de séries temporelles à surveiller. D'autres champs de la structure des conditions indiquent comment filtrer, regrouper et agréger les données. Pour en savoir plus sur ces concepts, consultez la section Filtrage et agrégation : manipuler des séries temporelles.

Si vous utilisez le type de condition MetricAbsence, vous pouvez créer une condition qui n'est remplie que lorsque toutes les séries temporelles sont absentes. Cette condition utilise le paramètre aggregations pour agréger plusieurs séries temporelles en une seule. Pour en savoir plus, consultez la documentation de référence sur MetricAbsence dans la documentation de l'API.

Une règle d'alerte d'absence de métrique nécessite que certaines données aient déjà été écrites. Pour en savoir plus, consultez la page Créer des règles d'alerte en cas d'absence de métrique.

Si vous souhaitez recevoir une notification en fonction d'une valeur prévue, configurez votre règle d'alerte pour utiliser le type de condition MetricThreshold et définir le champ forecastOptions. Lorsque ce champ n'est pas défini, les données mesurées sont comparées à un seuil. Toutefois, lorsque ce champ est défini, les données prédites sont comparées à un seuil. Pour en savoir plus, consultez la page Créer des règles d'alerte pour les valeurs de métriques prévues.

Conditions de métriques basées sur MQL

La condition MonitoringQueryLanguageCondition utilise le langage MQL (Monitoring Query Language) pour sélectionner et manipuler les données de séries temporelles à surveiller. Vous pouvez créer des règles d'alerte qui comparent les valeurs par rapport à un seuil ou tester l'absence de valeurs avec ce type de condition. Si vous utilisez une condition MonitoringQueryLanguageCondition, il doit s'agir de la seule condition de votre règle d'alerte. Pour en savoir plus, consultez la page Règles d'alerte avec MQL.

Conditions de métriques basées sur PromQL

La condition PrometheusQueryLanguageCondition utilise des requêtes du langage de requête Prometheus (PromQL) pour sélectionner et manipuler les données de séries temporelles à surveiller. Vous pouvez créer une requête simple ou complexe et utiliser des structures de requête telles que des seuils dynamiques, des ratios, des comparaisons de métriques, etc.

Si vous utilisez une condition PrometheusQueryLanguageCondition, il doit s'agir de la seule condition de votre règle d'alerte. Pour en savoir plus, consultez la page Règles d'alerte avec PromQL.

Conditions d'alerte sur les ratios

Vous pouvez créer des règles d'alerte basées sur un seuil de métrique pour surveiller le ratio de deux métriques. Vous pouvez créer ces règles à l'aide du type de condition MetricThreshold ou MonitoringQueryLanguageCondition. Vous pouvez également utiliser MQL directement dans la console Google Cloud. Vous ne pouvez pas créer ni gérer des conditions basées sur des ratios à l'aide de l'interface graphique pour créer des conditions de seuil.

Nous vous recommandons d'utiliser MQL pour créer des règles d'alerte basées sur des ratios. MQL vous permet de créer des requêtes plus puissantes et flexibles que celles que vous pouvez créer à l'aide du type de condition MetricTheshold et des filtres Monitoring. Par exemple, avec une condition MonitoringQueryLanguageCondition, vous pouvez calculer le ratio entre une métrique de jauge et une métrique delta. Pour obtenir des exemples, consultez les exemples de règles d'alerte MQL.

Si vous utilisez la condition MetricThreshold, le numérateur et le dénominateur du ratio doivent avoir le même MetricKind. Pour obtenir une liste des métriques et de leurs propriétés, consultez la page Listes de métriques.

En général, il est préférable de calculer les ratios en fonction des séries temporelles collectées pour un type de métrique unique, à l'aide de valeurs de libellés. Un ratio calculé sur deux types de métriques différents peut présenter des anomalies dues à des périodes d'échantillonnage et des fenêtres d'alignement différentes.

Par exemple, supposons que vous disposiez de deux types de métriques différents (nombre de RPC total et nombre de RPC en erreur), et que vous souhaitiez calculer le ratio du nombre de RPC en erreur par rapport au nombre de RPC total. Les RPC ayant échoué sont comptabilisés dans la série temporelle des deux types de métriques. Par conséquent, lorsque vous alignez la série temporelle, il se peut qu'un RPC en échec n'apparaisse pas dans le même intervalle d'alignement pour les deux séries temporelles. Cette différence peut se produire pour plusieurs raisons :

Étant donné que deux séries temporelles enregistrent le même événement, deux valeurs de compteur sous-jacentes mettent en œuvre la collection et ne sont pas mises à jour de manière atomique.
Les taux d'échantillonnage peuvent varier. Lorsque les séries temporelles sont alignées sur une période commune, les décomptes d'un seul événement peuvent apparaître dans des intervalles d'alignement adjacents dans la série temporelle des différentes métriques.

La différence du nombre de valeurs dans les intervalles d'alignement correspondants peut générer des valeurs de ratio error/total insensées, telles que 1/0 ou 2/1.

Les ratios de grands nombres sont moins susceptibles de donner des valeurs incompréhensibles. Vous pouvez obtenir des nombres plus importants par agrégation, soit en utilisant une fenêtre d'alignement plus longue que la période d'échantillonnage, soit en regroupant les données pour certains libellés. Ces techniques réduisent l'effet de différences mineures du nombre de points dans un intervalle donné. En d'autres termes, une disparité de deux points est plus importante lorsque le nombre attendu de points dans un intervalle est de 3 par rapport au nombre attendu de 300.

Si vous utilisez des types de métriques intégrés, vous n'aurez peut-être pas d'autre choix que de calculer les ratios sur l'ensemble des types de métriques pour obtenir la valeur souhaitée.

Si vous concevez des métriques personnalisées pouvant comptabiliser la même chose (par exemple, des RPC qui renvoient des états d'erreur) dans deux métriques différentes, envisagez plutôt d'utiliser une seule métrique, qui inclut un décompte à la fois. Par exemple, supposons que vous comptabilisiez les RPC et que vous souhaitiez suivre le ratio entre les RPC ayant échoué et tous les RPC. Pour résoudre ce problème, créez un seul type de métrique pour comptabiliser les RPC et utilisez un libellé pour enregistrer l'état de l'appel, y compris l'état "OK". Chaque valeur d'état (erreur ou état "OK") est ensuite enregistrée en mettant à jour un seul compteur pour ce cas.

Condition pour les règles d'alerte basées sur les journaux

Pour créer une règle d'alerte basée sur les journaux, qui vous avertit lorsqu'un message correspondant à votre filtre apparaît dans vos entrées de journal, utilisez le type de condition LogMatch. Si vous utilisez une condition LogMatch, il doit s'agir de la seule condition de votre règle d'alerte.

N'essayez pas d'utiliser le type de condition LogMatch avec des métriques basées sur les journaux. Les règles d'alerte qui surveillent les métriques basées sur les journaux sont basées sur des métriques. Pour plus d'informations sur le choix entre les règles d'alerte qui surveillent les métriques basées sur les journaux ou les entrées de journal, consultez la page Surveiller vos journaux.

Les règles d'alerte utilisées dans les exemples du document Gérer les règles d'alerte à l'aide d'API sont des règles d'alerte basées sur les métriques, bien que les principes soient les mêmes pour les règles d'alerte basées sur les journaux. Pour en savoir plus sur les règles d'alerte basées sur les journaux, consultez la section Créer une alerte basée sur les journaux à l'aide de l'API Monitoring dans la documentation Cloud Logging.

Avant de commencer

Avant d'écrire du code sur l'API, vous devez :

Vous devez connaître la terminologie et les concepts généraux utilisés avec les règles d'alerte. Pour en savoir plus, consultez la page Présentation des alertes.
Assurez-vous que l'API Cloud Monitoring est activée. Pour en savoir plus, consultez la section Activer l'API.
Si vous prévoyez d'utiliser des bibliothèques clientes, installez-les pour les langages que vous souhaitez utiliser. Pour en savoir plus, consultez la page Bibliothèques clientes. Actuellement, la fonctionnalité d'alerte de l'API n'est compatible qu'avec les langages C#, Go, Java, Node.js et Python.
Si vous prévoyez d'utiliser la Google Cloud CLI, installez-la. Toutefois, si vous utilisez Cloud Shell, Google Cloud CLI est déjà installé.

Remarque :Les commandes de gestion des règles d'alerte et des canaux de notification sont en version alpha dans Google Cloud CLI. Il est donc possible qu'une installation existante ne contienne pas ce composant. Pour installer les composants alpha contenant ces commandes, consultez la section Alertes et Google Cloud CLI.

Des exemples utilisant l'interface gcloud sont également fournis sur cette page. Notez que, dans tous ces exemples gcloud, nous partons du principe que le projet en cours a déjà été défini comme cible (gcloud config set project [PROJECT_ID]). Ainsi, les appels omettent l'option explicite --project. L'ID du projet en cours dans les exemples est a-gcp-project.

Pour obtenir les autorisations nécessaires pour créer et modifier des règles d'alerte à l'aide de l'API Cloud Monitoring, demandez à votre administrateur de vous attribuer le rôle IAM Éditeur Monitoring AlertPolicy (roles/monitoring.alertPolicyEditor) sur votre projet. Pour en savoir plus sur l'attribution de rôles, consultez la section Gérer les accès.

Vous pouvez également obtenir les autorisations requises via des rôles personnalisés ou d'autres rôles prédéfinis.

Pour en savoir plus sur les rôles IAM pour Monitoring, consultez la page Contrôler les accès avec Identity and Access Management.
Concevez votre application pour des appels d'API Cloud Monitoring monothread qui modifient l'état d'une règle d'alerte dans un projet Google Cloud. Par exemple, les appels d'API monothread qui créent, mettent à jour ou suppriment une règle d'alerte.

Créer une règle d'alerte

Pour créer une règle d'alerte dans un projet, utilisez la méthode alertPolicies.create. Pour découvrir comment appeler cette méthode, ses paramètres et les données de réponse, consultez la page de référence alertPolicies.create.

Vous pouvez créer des règles à partir de fichiers JSON ou YAML. La Google Cloud CLI accepte ces fichiers en tant qu'arguments. Vous pouvez lire les fichiers JSON de manière automatisée, les convertir en objets AlertPolicy et créer des règles à partir de ceux-ci à l'aide de la méthode alertPolicies.create. Si vous disposez d'un fichier de configuration Prometheus JSON ou YAML avec une règle d'alerte, la gcloud CLI peut le migrer vers une règle d'alerte Cloud Monitoring avec une condition PromQL. Pour en savoir plus, consultez la section Migrer les règles d'alerte et les destinataires à partir de Prometheus.

Chaque règle d'alerte appartient à un projet de champ d'application d'un champ d'application des métriques. Chaque projet peut contenir jusqu'à 500 règles. Pour les appels d'API, vous devez fournir un "ID de projet". Utilisez l'ID du projet de champ d'application d'un champ d'application des métriques comme valeur. Dans les exemples figurant sur cette page, l'ID du projet de champ d'application d'un champ d'application des métriques est a-gcp-project.

Les exemples suivants illustrent la création de règles d'alerte, mais ils ne décrivent pas comment créer un fichier JSON ou YAML décrivant une règle d'alerte. Au lieu de cela, les exemples supposent l'existence d'un fichier au format JSON et montrent comment émettre l'appel d'API. Pour obtenir des exemples de fichiers JSON, consultez la section Exemples de règles. Pour obtenir des informations générales sur la surveillance des ratios de métriques, consultez la section Ratios de métriques.

gcloud

Pour créer une règle d'alerte dans un projet, exécutez la commande gcloud alpha monitoring policies create. L'exemple suivant crée une règle d'alerte dans a-gcp-project à partir du fichier rising-cpu-usage.json :

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

Si la commande réussit, elle renvoie le nom de la nouvelle règle, par exemple :

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

Le fichier rising-cpu-usage.json contient le code JSON d'une règle portant le nom à afficher "High CPU rate of change" (Haute variation de l'utilisation du processeur). Pour en savoir plus sur cette règle, consultez la section Règle de taux d'évolution.

Pour plus d'informations, consultez la documentation de référence sur gcloud alpha monitoring policies create.

C#

Pour vous authentifier auprès de Monitoring, configurez les identifiants par défaut de l'application. Pour en savoir plus, consultez Configurer l'authentification pour un environnement de développement local.

static void RestorePolicies(string projectId, string filePath)
{
    var policyClient = AlertPolicyServiceClient.Create();
    var channelClient = NotificationChannelServiceClient.Create();
    List<Exception> exceptions = new List<Exception>();
    var backup = JsonConvert.DeserializeObject<BackupRecord>(
        File.ReadAllText(filePath), new ProtoMessageConverter());
    var projectName = new ProjectName(projectId);
    bool isSameProject = projectId == backup.ProjectId;
    // When a channel is recreated, rather than updated, it will get
    // a new name.  We have to update the AlertPolicy with the new
    // name.  Track the names in this map.
    var channelNameMap = new Dictionary<string, string>();
    foreach (NotificationChannel channel in backup.Channels)
    {
    }
    foreach (AlertPolicy policy in backup.Policies)
    {
        string policyName = policy.Name;
        // These two fields cannot be set directly, so clear them.
        policy.CreationRecord = null;
        policy.MutationRecord = null;
        // Update channel names if the channel was recreated with
        // another name.
        for (int i = 0; i < policy.NotificationChannels.Count; ++i)
        {
            if (channelNameMap.ContainsKey(policy.NotificationChannels[i]))
            {
                policy.NotificationChannels[i] =
                    channelNameMap[policy.NotificationChannels[i]];
            }
        }
        try
        {
            Console.WriteLine("Updating policy.\n{0}",
                policy.DisplayName);
            bool updated = false;
            if (isSameProject)
                try
                {
                    policyClient.UpdateAlertPolicy(null, policy);
                    updated = true;
                }
                catch (Grpc.Core.RpcException e)
                when (e.Status.StatusCode == StatusCode.NotFound)
                { }
            if (!updated)
            {
                // The policy no longer exists.  Recreate it.
                policy.Name = null;
                foreach (var condition in policy.Conditions)
                {
                    condition.Name = null;
                }
                policyClient.CreateAlertPolicy(projectName, policy);
            }
            Console.WriteLine("Restored {0}.", policyName);
        }
        catch (Exception e)
        {
            // If one failed, continue trying to update the others.
            exceptions.Add(e);
        }
    }
    if (exceptions.Count > 0)
    {
        throw new AggregateException(exceptions);
    }
}

Go


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

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

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

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

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'objet AlertPolicy créé contiendra des champs supplémentaires. La règle en elle-même contiendra les champs name, creationRecord et mutationRecord. En outre, un champ name est également attribué à chaque condition de la règle. Ces champs ne peuvent pas être modifiés de manière externe, il n'est donc pas nécessaire de les définir lors de la création d'une règle. Aucun des exemples JSON de cette page ne les inclut, mais si les règles créées à partir de ces exemples sont récupérées après leur création, ces champs seront présents.