Ce document explique comment utiliser l'API Cloud Monitoring pour créer, modifier, supprimer, répertorier et obtenez des règles d'alerte basées sur les métriques de manière programmatique. Ces exemples montrent comment utiliser la Google Cloud CLI et les bibliothèques clientes. Ce contenu ne concerne pas 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 Surveiller vos journaux
Ces tâches peuvent également être effectuées à l'aide de la console Google Cloud. pour plus d'informations, consultez les documents suivants:
- Créer des règles d'alerte basées sur le seuil de métrique dans la console Google Cloud
- Gérer les règles d'alerte dans la console Google Cloud
À propos des règles d'alerte
Une règle d'alerte est représentée par un objet AlertPolicy
, qui décrit un ensemble de conditions indiquant un état potentiellement non opérationnel dans votre système. Les règles d'alerte peuvent référencer des canaux de notification, ce qui vous permet d'indiquer comment vous souhaitez être informé lorsqu'une règle d'alerte est déclenchée.
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
.
La ressource AlertPolicy
prend en charge cinq opérations :
- Créer de nouvelles règles
- Supprimer des règles existantes
- Récupérer des règles spécifiques
- Récupérer toutes les règles
- Modifier les règles existantes
Les règles d'alertes peuvent être au format JSON ou YAML, ce qui vous permet d'enregistrer des règles dans des fichiers, et d'utiliser ces fichiers pour les sauvegarder et les restaurer. Avec Google Cloud CLI, vous pouvez créer des stratégies à partir de fichiers dans l'un ou l'autre format. Avec l'API REST, vous ne pouvez créer des règles qu'à partir de fichiers JSON. Consultez la section Exemples de règles pour une sélection de règles d'alerte au format JSON.
Les exemples suivants utilisent l'interface gcloud
et l'API pour illustrer ces cas d'utilisation de base. Ces exemples supposent l'existence d'un programme qui utilise l'API pour implémenter un système de sauvegarde et de restauration pour les règles d'alerte. Des exemples plus complets sont présentés dans la section Exemples : Sauvegarder et restaurer.
Avant de commencer
Avant d'écrire du code sur l'API, vous devez :
- Connaître la terminologie et les concepts généraux utilisés dans le cadre des alertes policies; voir Vue d'ensemble des alertes pour en savoir plus des informations.
- 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 bibliothèques pour le dans les langues que vous souhaitez utiliser ; voir 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é.
Des exemples utilisant l'interface
gcloud
sont également fournis sur cette page. Notez que, dans tous ces exemplesgcloud
, 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 esta-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 accorder le rôle IAM Éditeur de règles d'alerte Monitoring (
roles/monitoring.alertPolicyEditor
) dans votre projet. Pour en savoir plus sur l'attribution de rôles, consultez la page Gérer l'accès aux projets, aux dossiers et aux organisations.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 Contrôlez les accès avec Identity and Access Management.
Concevez votre application pour des appels d'API Cloud Monitoring monothread qui modifier l'état d'une règle d'alerte projet Google Cloud. Par exemple, les appels d'API monothread qui créent, mettent à jour ou supprimer 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
alertPolicies.create
. Pour savoir comment appeler cette
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 programmatique et les convertir en AlertPolicy
objets, et créer des stratégies à partir de ceux-ci
à l'aide de la méthode alertPolicies.create
. Si vous
disposer d'un fichier de configuration Prometheus JSON ou YAML avec une règle d'alerte ;
la gcloud CLI peut la migrer vers un système d'alerte
avec une condition PromQL. Pour en savoir plus, consultez la page Migrer des règles d'alerte et des récepteurs depuis Prometheus.
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 une règle d'alerte. Au lieu de cela, les exemples supposent qu'un fichier au format JSON et ils illustrent comment émettre l'appel d'API. Pour obtenir des exemples de fichiers JSON, consultez Exemples de règles. Pour obtenir des informations générales sur les ratios de surveillance des métriques, consultez 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 dont le nom à afficher est "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.
Go
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.
Java
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.
Node.js
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.
PHP
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.
Python
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.
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.
Répertorier et obtenir des règles d'alerte
Pour récupérer la liste des règles d'un projet, utilisez la méthode alertPolicies.list
.
Utilisez cette méthode pour répertorier vos règles et appliquer une action à chacune d'entre elles, les sauvegarder par exemple. Cette méthode est également compatible avec les options filter
et orderBy
, qui permettent de restreindre et de trier les résultats. Pour en savoir plus, consultez la page Trier et filtrer.
Si vous recherchez une règle spécifique dont vous connaissez le nom, récupérez-la à l'aide de la méthode alertPolicies.get
. Le nom d'une règle correspond à la valeur du champ name
de l'objet AlertPolicy
, et non pas du champ displayName
. Le nom d'une règle est au format projects/[PROJECT_ID]/alertPolicies/[POLICY_ID]
, par exemple :
projects/a-gcp-project/alertPolicies/12669073143329903307
gcloud
Pour répertorier toutes les règles d'alerte d'un projet, exécutez la commande gcloud alpha monitoring
policies list
:
gcloud alpha monitoring policies list
Si la commande list
aboutit, elle fournit la liste au format YAML de toutes les règles du projet spécifié. Par exemple,
avec le nom à afficher "High CPU rate of change" ("Haute variation de l'utilisation du processeur")
du projet a-gcp-project
est listé comme ceci :
parmi les autres règles listées:
---
combiner: OR
conditions:
- conditionThreshold:
aggregations:
- alignmentPeriod: 900s
perSeriesAligner: ALIGN_PERCENT_CHANGE
comparison: COMPARISON_GT
duration: 180s
filter: metric.type="compute.googleapis.com/instance/cpu/utilization" AND resource.type="gce_instance"
thresholdValue: 0.5
trigger:
count: 1
displayName: CPU usage is increasing at a high rate
name: projects/a-gcp-project/alertPolicies/12669073143329903307/conditions/12669073143329903008
creationRecord:
mutateTime: '2018-03-26T18:52:39.363601689Z'
mutatedBy: [USER@DOMAIN]
displayName: High CPU rate of change
enabled: true
mutationRecord:
mutateTime: '2018-03-26T18:52:39.363601689Z'
mutatedBy: [USER@DOMAIN]
name: projects/a-gcp-project/alertPolicies/12669073143329903307
---
Pour répertorier une seule règle d'alerte, utilisez plutôt gcloud alpha monitoring policies
describe
et spécifiez son nom. Par exemple, la commande suivante ne renvoie que la liste mentionnée ci-dessus :
gcloud alpha monitoring policies describe projects/a-gcp-project/alertPolicies/12669073143329903307
Pour plus d'informations, consultez la documentation de référence sur gcloud alpha monitoring policies list
et describe
. La commande describe
correspond à la méthode alertPolicies.get
dans l'API.
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.
Go
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.
Java
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.
Node.js
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.
PHP
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.
Python
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.
Supprimer une règle d'alerte
Pour supprimer une règle d'un projet, utilisez la méthode alertPolicies.delete
et indiquez le nom de la règle d'alerte à supprimer.
gcloud
Pour supprimer une règle d'alerte, utilisez gcloud alpha monitoring policies
delete
et spécifiez son nom. Par exemple,
la commande suivante permet de supprimer
avec le nom à afficher "High CPU rate of change" ("Haute variation de l'utilisation du processeur"):
gcloud alpha monitoring policies delete projects/a-gcp-project/alertPolicies/12669073143329903307
Pour plus d'informations, consultez la documentation de référence sur gcloud alpha monitoring policies delete
.
Modifier une règle d'alerte
Pour modifier une règle d'alerte, utilisez la méthode alertPolicies.patch
(dans l'API REST).
D'autres mises en œuvre d'API et l'interface gcloud
appellent update
plutôt que patch
.
Une opération de mise à jour peut remplacer entièrement la règle existante ou modifier un sous-ensemble de champs. Une opération de mise à jour nécessite un nouvel objet AlertPolicy
et, de manière facultative, un masque de champ.
Si un masque de champ est spécifié, tous les champs répertoriés qu'il comporte sont mis à jour avec les valeurs de la règle fournie. Si la règle n'inclut pas un champ mentionné par le masque de champ, ce champ reprend sa valeur par défaut. Tout champ non spécifié dans le masque de champ conserve sa valeur précédente.
Si aucun masque de champ n'est spécifié, la règle existante est remplacée par celle fournie, mais son nom (projects/[PROJECT_ID]/alertPolicies/[POLICY_ID]
) est réutilisé. Toutes les conditions de la nouvelle règle dont la valeur name
comprend une valeur pour CONDITION_ID
conserveront les mêmes noms. Sinon, de nouveaux noms de condition et de règles sont créés.
Lorsque vous mettez à jour des règles avec la ligne de commande gcloud
, des options de ligne de commande sont utilisées pour spécifier les champs à mettre à jour, plutôt qu'un masque de champ.
Pour en savoir plus, consultez la page sur gcloud alpha monitoring policies update
.
Activer ou désactiver une règle d'alerte
Pour activer ou désactiver une règle, modifiez la valeur du champ booléen enabled
de l'objet AlertPolicy
. Notez qu'après avoir activé une règle, celle-ci peut toujours être déclenchée par les données collectées tandis qu'elle était désactivée.
gcloud
Pour désactiver une règle d'alerte, exécutez la commande gcloud alpha monitoring policies update
et spécifiez l'option --no-enabled
. La commande suivante désactive la règle d'alerte "High CPU rate of change" ("Haute variation de l'utilisation du processeur") dans le projet a-gcp-project
:
gcloud alpha monitoring policies update projects/a-gcp-project/alertPolicies/12669073143329903307 --no-enabled
Pour activer la règle, exécutez la même commande et spécifiez l'option --enabled
.
Pour plus d'informations, consultez la documentation de référence sur gcloud alpha monitoring policies update
. La commande update
correspond à la méthode alertPolicies.patch
dans l'API REST.
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.
Go
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.
Java
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.
Node.js
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.
PHP
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.
Python
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.
Mettre à jour les canaux de notification dans une règle d'alerte
Vous pouvez également mettre à jour les canaux de notification référencés par une règle d'alerte. Les règles d'alerte emploient des canaux de notification en les désignant par leur nom. Les canaux doivent donc exister avant de pouvoir être utilisés dans une règle d'alerte.
Créez et gérez de manière automatisée des canaux de notification à l'aide des ressources NotificationChannel
et NotificationChannelDescriptors
.
Dans cette section, nous partons du principe que ces canaux existent déjà. Vous y trouverez également des exemples d'utilisations de ces API.
Pour plus d'informations sur les objets canaux de notification, consultez Créer et gérer des canaux de notification par API
gcloud
Pour modifier les canaux de notification d'une règle d'alerte, exécutez la commande gcloud alpha monitoring policies update
. Plusieurs indicateurs sont associés aux canaux de notification, vous permettant de supprimer, de remplacer ou d'ajouter des canaux de notification.
Par exemple, la règle dénommée "High CPU rate of change" ("Haute variation de l'utilisation du processeur") dans le projet a-gcp-project a été créée sans canal de notification.
Pour ajouter un canal de notification à cette règle, exécutez la commande gcloud alpha monitoring
policies update
et spécifiez le canal à ajouter avec l'option --add-notification-channels
:
gcloud alpha monitoring policies update projects/a-gcp-project/alertPolicies/12669073143329903307 \
--add-notification-channels="projects/a-gcp-project/notificationChannels/1355376463305411567"
Pour plus d'informations, consultez la documentation de référence sur gcloud alpha monitoring policies update
. La commande update
correspond à la méthode alertPolicies.patch
dans l'API REST.
Le canal de notification ajouté ici doit déjà exister. voir Pour en savoir plus, créez un canal de notification.
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.
Go
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.
Java
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.
Node.js
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.
PHP
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.
Python
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.
Modifier la documentation dans une règle d'alerte
Une règle peut fournir de la documentation lors des incidents et des notifications qui lui sont associés. Utilisez ce champ pour inclure des informations permettant aux personnes recevant la notification de comprendre et de gérer au mieux le problème indiqué par la règle d'alerte. La documentation est incluse dans les notifications par e-mail et les autres types de notification, le cas échéant. Certains types de canaux peuvent ne pas l'inclure.
gcloud
Pour ajouter de la documentation à une stratégie ou remplacer la documentation existante, utilisez lagcloud alpha monitoring policies update
et indiquez la valeur
Indicateur --documentation-format="text/markdown"
(seul format compatible)
et soit sur l'option --documentation
(pour saisir la valeur à partir de la ligne de commande)
ou l'option --documentation-from-file
(pour lire la valeur d'un fichier).
Par exemple, la règle dénommée "High CPU rate of change" ("Haute variation de l'utilisation du processeur") dans le projet a-gcp-project a été créée sans documentation.
La commande suivante définit le champ documentation
de la règle spécifiée sur le contenu du fichier cpu-usage-doc.md
:
gcloud alpha monitoring policies update projects/a-gcp-project/alertPolicies/12669073143329903307 \
--documentation-format="text/markdown" \
--documentation-from-file="cpu-usage-doc.md"
Pour plus d'informations, consultez la documentation de référence sur gcloud alpha monitoring policies update
. La commande update
correspond à la méthode alertPolicies.patch
dans l'API REST.
Ajouter une règle d'alerte à un tableau de bord
Pour afficher le résumé d'une règle d'alerte à condition unique sur un tableau de bord personnalisé, ajoutez un widget AlertChart
au tableau de bord.
Vous utilisez la méthode dashboards.create
pour un nouveau tableau de bord et la méthode dashboards.patch
pour un tableau de bord existant.
Si vous spécifiez une règle d'alerte à plusieurs conditions,
le widget AlertChart
n'affiche pas de données.
Pour en savoir plus sur l'utilisation de ces méthodes d'API, consultez Créer et gérer des tableaux de bord à l'aide d'API
Exemples : Sauvegarder et restaurer
Tous les exemples d'API présentés ici supposent une application à même d'enregistrer dans un fichier les règles d'alerte d'un projet et de les restaurer, dans un autre projet le cas échéant. Si les projets désignés pour la sauvegarde et la restauration sont différents, l'application procède en réalité à une exportation et à une importation des règles d'alerte d'un projet à un autre.
Cette section présente le code pour la sauvegarde et la restauration de règles en contexte, plutôt que sous la forme d'un ensemble d'extraits isolés.
Sauvegarder des règles
L'opération de sauvegarde est simple. L'ensemble des règles d'alerte et des canaux de notification de chaque projet sont collectés et enregistrés dans un stockage externe au format JSON.
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.
Go
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.
Java
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.
Node.js
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.
PHP
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.
Python
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.
Restaurer des règles sauvegardées
Le processus de restauration est plus complexe que la sauvegarde initiale. Vous pouvez restaurer le projet que vous avez sauvegardé à l'origine. Mais vous pouvez également restaurer un projet différent, ce qui revient à une importation de règles d'alerte.
Dans le cas d'une restauration du même projet, toutes les règles et tous les canaux existants sont mis à jour, à condition qu'ils existent toujours. Si ce n'est pas le cas, elles sont recréées. Dans les règles sauvegardées, les champs en lecture seule, tels que les enregistrements de création et de mutation, sont effacés par le processus de restauration avant que les règles et les notifications ne soient recréées.
Vous pouvez vous servir d'une règle enregistrée dans un projet pour créer une autre règle dans ce même projet, ou une règle similaire dans un autre projet. Toutefois, vous devez d'abord apporter les modifications suivantes à la copie de la règle enregistrée :
- Supprimez les champs suivants des canaux de notification :
name
verificationStatus
- Créez les canaux de notification avant d'y faire référence dans les règles d'alerte (les nouveaux identifiants des canaux sont nécessaires).
- Supprimez les champs suivants de toute règle d'alerte que vous recréez :
name
condition.name
creationRecord
mutationRecord
Si la règle est recréée dans un nouveau projet, le nom de toutes les conditions des règles sauvegardées est effacé, ainsi que les enregistrements de création et de mutation.
De plus, lorsqu'un canal de notification est recréé dans un projet différent, il reçoit un nouveau nom. Le processus de restauration doit donc faire correspondre les anciens noms des canaux avec leurs nouveaux noms, puis remplacer les anciens par les nouveaux.
Outre la modification des noms des canaux de notification, la valeur du champ verificationStatus
ne peut pas être définie lors de la création ou de la mise à jour du canal. C'est pourquoi on lui donne une valeur sentinelle unspecified
(non spécifié). Une fois les canaux restaurés dans un nouveau projet, leur fonctionnement doit faire l'objet d'une vérification.
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.
Go
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.
Java
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.
Node.js
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.
PHP
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.
Python
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.
Alertes et Google Cloud CLI
Dans la Google Cloud CLI, le groupe de commandes pour gérer les règles d'alerte
canal de notification est monitoring
, qui est en version alpha.
Le groupe monitoring
est disponible dans le composant alpha
.
Ces commandes commenceront donc toutes par :
gcloud alpha monitoring
Pour vérifier si le composant alpha
est installé, exécutez cette commande :
gcloud components list
Si le composant alpha
n'est pas installé, exécutez cette commande pour l'installer :
gcloud components install alpha
Si vous possédez le composant alpha
, recherchez le groupe monitoring
en exécutant la commande suivante :
gcloud alpha monitoring --help
Si le groupe monitoring
n'est pas inclus, Google Cloud CLI vous invite à l'ajouter :
You do not currently have this command group installed.
[...]
Do you want to continue (Y/n)? y