Résoudre les problèmes liés à l'agent Monitoring

Cette page vous aide à diagnostiquer les problèmes liés à l'installation ou à l'exécution de l'agent Monitoring.

Remarque : Si le message suivant s'affiche sur une machine virtuelle (VM) Linux, vous pouvez l'ignorer en toute sécurité :

Need to set
  STACKDRIVER_API_KEY in /etc/sysconfig/stackdriver Not starting. Configuration
  error.

Ce message est émis par un ancien service qui sera progressivement remplacé. Ce message est anodin et finira par disparaître.

Checklist

Si vous rencontrez des problèmes pour installer ou utiliser l'agent Monitoring, procédez comme suit :

Si les commandes d'installation de Linux génèrent des erreurs, veillez à leur ajouter le préfixe sudo.
Vérifiez que le service d'agent est en cours d'exécution sur votre instance de VM.
- Pour une VM Windows, exécutez la commande PowerShell suivante :
```
Get-Service -Name StackdriverMonitoring
```
  Recherchez un service appelé Stackdriver Monitoring. Si l'agent n'est pas en cours d'exécution, vous devrez peut-être le redémarrer.
- Pour une VM Linux, exécutez la commande suivante :
```
sudo service stackdriver-agent status
```
  Si l'agent n'est pas en cours d'exécution, vous devrez peut-être le redémarrer à l'aide de la commande suivante :
```
sudo service stackdriver-agent restart
```
  Si le redémarrage échoue et que le journal affiche "Désactivé via les métadonnées", il se peut que vous exécutiez une image à partir de Google Cloud Marketplace, où l'agent Logging est désactivé par défaut. Cette opération est contrôlée par la clé de métadonnées d'instance google-monitoring-enable (avec la valeur 0). Pour réactiver l'agent, supprimez cette clé ou définissez la valeur sur 1 (consultez la section Définir des métadonnées d'instance).
  
  Si l'agent n'est pas désactivé via les métadonnées, réinstallez-le. Pour en savoir plus sur ce processus, consultez la section Réinstaller l'agent Monitoring.
Vérifiez que l'agent a écrit des messages d'erreur dans les journaux.
- Sous Windows, l'agent Monitoring écrit des messages dans le journal des événements Windows.
- Sous Linux, l'agent Monitoring correspond à un package collectd et consigne les messages dans /var/log/syslog ou /var/log/messages. Les messages du journal comportent le préfixe collectd ou stackdriver-agent :
  - Si des erreurs HTTP 429 s'affichent, vous avez peut-être dépassé vos quotas d'API Monitoring. Vous pouvez consulter votre quota disponible en sélectionnant API et services > Tableau de bord dans la console Google Cloud. Choisissez l'API Monitoring.
  - Si vous rencontrez des problèmes de proxy, vérifiez que vous avez correctement configuré votre proxy HTTP. Ces instructions figurent dans la section Effectuer l'installation sous Linux et Windows.
  - Si vous rencontrez des problèmes d'accès ou d'autorisation en lien avec l'API, ou si vous voyez des messages d'erreur tels que "Impossible de déterminer le point de terminaison collectd", reportez-vous à la section suivante, Valider le projet et les identifiants.
  - Si les messages d'erreur "Combinaison type/plug-in non acceptée" ou "ID collectd non accepté" s'affichent dans les journaux, vous envoyez peut-être des métriques d'agent non compatibles. Cela peut se produire dans les scénarios suivants :
    - Vous avez modifié l'une des configurations de l'application tierce de l'agent. Pour annuler les modifications, vous pouvez réinstaller la configuration du plug-in spécifique en suivant les instructions de la page de documentation correspondante. Si vous souhaitez envoyer ces métriques à Monitoring à l'aide de l'agent, essayez de les convertir en métriques définies par l'utilisateur.
    - L'un des plug-ins de l'applications tierce envoie de nouvelles métriques qui ne sont pas disponibles dans Monitoring. Consultez la page d'assistance pour savoir comment envoyer une requête afin d'examiner et de catégoriser ces métriques.
Si l'agent semble fonctionner normalement, mais que vous n'obtenez pas de données ou que vos règles d'alerte ne fonctionnent pas comme prévu, vous devez vérifier que l'agent envoie les données au projet approprié. Pour en savoir plus, consultez la section suivante, Valider le projet et les identifiants.

Valider le projet et les identifiants

Si l'agent Monitoring signale des erreurs d'accès ou d'autorisation, ou si l'agent semble fonctionner normalement mais qu'il n'y a pas de données, ou que vos règles d'alerte ne fonctionnent pas comme prévu, vérifiez que les identifiants de l'instance de VM sont corrects et qu'ils se rapportent au bon projet :

Si vous utilisez une instance de VM Compute Engine avec des identifiants standards (sans clé privée), il est peu probable que les données se trouvent dans le mauvais projet. Toutefois, vos identifiants risquent de ne pas être suffisants. Pour en savoir plus sur les identifiants, consultez Autoriser l'agent Monitoring. Pour valider vos identifiants, consultez la section Valider les identifiants Compute Engine.
Si vous utilisez une instance de VM Amazon EC2 ou si vous utilisez des identifiants de clé privée sur votre instance Compute Engine, ces identifiants peuvent ne pas être valides ou provenir du mauvais projet. Pour les comptes AWS, le projet utilisé par l'agent doit être le projet Google Cloud auquel vous envoyez les métriques. Pour en savoir plus sur les identifiants, consultez la section Autoriser l'agent Monitoring. Pour valider vos identifiants, consultez la section Valider les identifiants de clé privée.

Si vous n'avez toujours pas résolu votre problème, consultez la section Réinstaller l'agent.

Vérifier les identifiants Compute Engine

Utilisez la page Instances de VM Compute Engine de la console Google Cloud pour vérifier que votre instance de VM Compute Engine dispose des identifiants adéquats pour l'agent Monitoring. Les identifiants sont généralement ajoutés dans le compte de service par défaut de toutes les nouvelles instances de VM Compute Engine, mais il est possible d'écraser ces valeurs par défaut lors de la création d'une instance.

Dans la console Google Cloud, accédez à la page Instances de VM :

Accéder à la page Instances de VM

Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Compute Engine.

Si nécessaire, modifiez le projet Google Cloud actuel pour qu'il soit associé à votre instance de VM Compute Engine. Par exemple, si vous êtes invité à activer la facturation, cela signifie que le projet en cours ne contient aucune instance de VM Compute Engine.
Sur la page Instances de VM, cliquez sur le nom de votre instance de VM. La page des détails relatifs à votre instance de VM s'affiche.
Sur la page Informations sur l'instance de VM, regardez sous l'en-tête Niveaux d'accès aux API Cloud :
- Si "Autoriser l'accès complet à l'ensemble des API Cloud" s'affiche, vous disposez des identifiants appropriés.
- Si vous voyez à côté de API Stackdriver Monitoring, un nom plus ancien pour l'API Cloud Monitoring, l'autorisation Écriture seule ou Complète, vous disposez des identifiants appropriés.
- Dans tous les autres cas, le compte de service par défaut de votre instance ne dispose pas des identifiants requis par l'agent. Pour utiliser l'agent sur votre instance, vous devez ajouter des identifiants de clé privée pour votre compte de service. Pour savoir comment procéder, consultez la section Ajouter des identifiants.

Si vous disposez des identifiants par défaut corrects, passez à l'étape Effectuer l'installation sous Linux et Windows.

Vérifier les identifiants de clé privée

Pour vérifier que des identifiants de clé privée valides sont installés sur votre instance de VM, assurez-vous d'abord que le fichier d'identifiants existe à l'emplacement prévu, puis que les informations contenues dans le fichier d'identifiants sont valides. Il est possible de révoquer des identifiants précédemment valides sous la section IAM et administration > Comptes de service de la console Google Cloud. En cas d'absence d'identifiants valides, consultez la section Ajouter des identifiants pour remplacer les identifiants existants ou en ajouter de nouveaux.

Des identifiants sont-ils présents ?

Pour voir si des identifiants de clé privée pour votre compte de service sont présents dans votre instance, exécutez les commandes Linux suivantes sur celle-ci :

sudo cat $GOOGLE_APPLICATION_CREDENTIALS
sudo cat /etc/google/auth/application_default_credentials.json

Si l'une des commandes affiche un fichier comme celui présenté ci-dessous, votre instance peut contenir des identifiants de clé privée valides. Si les deux commandes affichent un fichier, le fichier indiqué par GOOGLE_APPLICATION_CREDENTIALS est celui qui sera utilisé.

{
  "type": "service_account",
  "project_id": "{your-project-id}",
  "private_key_id": "{your-private-key-id}",
  "private_key": "{your-private-key}",
  "client_email": "{your-project-number}-{your-key}@developer.gserviceaccount.com",
  "client_id": "{your-client-id}",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://accounts.google.com/o/oauth2/token",
  "auth_provider_x509_cert_url": "{x509-cert-url}",
  "client_x509_cert_url": "{client-x509-cert-url}"
}

Si aucun fichier d'identifiants n'est présent, reportez-vous à la section Ajouter des identifiants.

Les identifiants sont-ils valides ?

Dans le fichier d'identifiants, le champ project_id correspond à votre projet Google Cloud, client_email identifie le compte de service dans le projet et private_key_id identifie la clé privée dans le service compte. Faites correspondre ces informations avec celles affichées dans la section IAM et administration > Comptes de service de la console Google Cloud.

Le fichier d'identifiants n'est pas valide si l'une des conditions suivantes est remplie :

Vous êtes en train de vérifier une instance de VM Compute Engine, mais le projet Google Cloud spécifié dans le fichier d'identifiants n'est pas celui qui contient votre instance.
Vous êtes en train de vérifier une instance Amazon EC2, mais le projet Google Cloud indiqué dans le fichier d'identifiants n'est pas le projet Google Cloud auquel vous envoyez les métriques depuis votre compte AWS.
Le compte de service répertorié n'existe pas. Il a peut-être été supprimé.
Les rôles appropriés n'ont pas été activés pour le compte de service répertorié. Celui-ci doit comporter au moins les rôles roles/monitoring.metricWriter (Rédacteur de métriques de surveillance) pour la collecte des métriques et roles/logging.logWriter (Rédacteur de journaux) pour l'écriture des journaux.
La clé privée n'existe pas. Elle a peut-être été révoquée.

Si le compte de service est correct, mais que la clé privée a été révoquée, vous pouvez créer une nouvelle clé privée et la copier sur votre instance. Sinon, vous devez créer un nouveau compte de service comme indiqué à la section Ajouter des identifiants.

Générer des identifiants

Si les identifiants ne sont pas valides, procédez comme suit :

Pour chaque projet connecté contenant des instances devant être autorisées avec une clé privée (instances Compute Engine créées sans inclure le niveau d'accès https://www.googleapis.com/auth/monitoring.write) : Créer un compte de service et générer une clé privée, s'ils n'existent pas déjà. Suivez les instructions ci-dessous :
1. Accédez à la page Paramètres dans la console Google Cloud.
  Accéder aux paramètres
  
  Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Monitoring.
2. Sélectionnez l'onglet Champ d'application de la métrique.
3. Identifiez le projet contenant les ressources Compute Engine concernées et accédez à la console Google Cloud.
4. Accédez à la page Comptes de service IAM de la console Google Cloud, sélectionnez votre projet Google Cloud, créez un compte de service, puis générez une nouvelle clé privée pour ce compte de service.
  Pour effectuer ces étapes, effectuez l'une des opérations suivantes :
  - Accédez à la page Comptes de service IAM, sélectionnez votre projet Google Cloud, puis suivez les étapes décrites dans la section Créer un compte de service :
    
    Accéder à la page Comptes de service IAM
  - Cliquez sur le bouton suivant, puis sélectionnez votre projet Google Cloud :
    
    Créer un compte de service et télécharger la clé
    
    Le bouton précédent automatise le processus de création et de téléchargement d'une clé sur votre système local pour le compte de service spécifique à l'agent. Si nécessaire, le processus crée également le compte de service requis et s'assure qu'il dispose des autorisations appropriées. Les comptes de service spécifiques à un agent portent un nom semblable à stackdriver-1234@PROJECT_ID.iam.gserviceaccount.com. Vous êtes informé de l'achèvement de ces actions avec une boîte de dialogue semblable à celle-ci :
  Remarque : Les comptes de service peuvent posséder un maximum de 10 clés. Pour en savoir plus, consultez la section Limites.
Remplacez la clé privée sur les instances correspondant au compte de service en question.
- Sous Linux, remplacez la clé privée située dans /etc/google/auth/application_default_credentials.json.
- Sous Windows, remplacez la clé privée située dans C:\ProgramData\Google\Auth\application_default_credentials.json. Pour en savoir plus, consultez la section Copier la clé privée sur l'instance.
Redémarrer l'agent
- Sous Linux, exécutez sudo service stackdriver-agent restart.
- Sous Windows, accédez à la console de gestion du service et redémarrez le service Cloud Monitoring.

Si vous avez plusieurs projets nécessitant de nouvelles clés privées, répétez cette procédure pour chacun d'eux.

Pour vérifier que la clé privée est correcte, consultez la section Des identifiants sont-ils présents ?, et, Plus précisément :

Lisez le fichier JSON de clé privée sur l'instance, par exemple (sous Linux) : sudo cat /etc/google/auth/application_default_credentials.json
assurez-vous que la valeur du champ project_id correspond à celle du projet surveillé pour lequel vous venez de générer des identifiants.

Valider les données de l'agent

Pour vérifier que l'agent envoie correctement les métriques, utilisez la méthode timeSeries.list de l'API Monitoring pour rechercher les données de série temporelle récentes dans l'instance de VM. Vous pouvez appeler la méthode à l'aide de l'explorateur d'API sur la page de documentation de la méthode. Si vous ne voyez aucune donnée, il se peut que l'agent envoie des données au mauvais projet. Pour vérifier cela, consultez la section Valider le projet et les identifiants.

Voici des instructions détaillées concernant l'utilisation de la méthode timeSeries.list :

Déterminez l'ID de l'instance de VM sur laquelle vous avez installé l'agent :
- Instances Compute Engine : accédez à la page des détails de Compute Engine correspondant à votre instance. Au bas de la page, cliquez sur Requête/Réponse REST équivalente. L'ID est un nombre à 19 chiffres.
- Instances Amazon EC2 : l'ID de chaque instance est indiqué dans la liste des instances. L'ID ressemble à i-1a2b3c4d.
Accédez à la page de documentation pour la méthode timeSeries.list :
Remplissez le formulaire de l'explorateur d'API :
1. Définissez le nom du projet contenant votre instance de VM, précédé de projects/. Par exemple, projects/[YOUR_PROJECT_ID].
2. Définissez le filtre sur la ligne suivante pour choisir une métrique d'agent à partir de votre instance de VM. Copiez-le et collez-le dans l'explorateur d'API, puis modifiez l'ID d'instance de VM :
```
metric.type = "agent.googleapis.com/memory/bytes_used" AND resource.label.instance_id = "[YOUR-VM-INSTANCE-ID]"
```
3. Définissez la durée de l'intervalle de recherche. Si vous souhaitez définir un intervalle d'environ cinq minutes, procédez comme suit :
  - Définissez interval.endTime sur l'heure GMT actuelle, que vous pouvez trouver en accédant à la page time.is/GMT. L'heure doit respecter le format suivant : Ne mettez pas l'heure entre guillemets :
```
2016-10-31T14:10:00Z
```
  - Définissez interval.startTime environ cinq minutes avant l'heure de fin, en utilisant le même format.
4. Laissez tous les autres champs vides.
Cliquez sur Exécuter.

Vous devriez voir une sortie semblable à ce qui suit.

{
 "timeSeries": [
  {
   "metric": {
    "labels": {
     "state": "buffered"
    },
    "type": "agent.googleapis.com/memory/bytes_used"
   },
   "resource": {
    "type": "[INSTANCE-TYPE]",
    "labels": {
     "instance_id": "[YOUR-VM-INSTANCE-ID]",
     "zone": "[YOUR-INSTANCE-ZONE]",
     "project_id": "[YOUR-PROJECT-ID]"
    }
   },
   "metricKind": "GAUGE",
   "valueType": "DOUBLE",
   "points": [
    {
     "interval": {
      "startTime": "[START_TIME]",
      "endTime": "[END_TIME]"
     },
     "value": {
      "doubleValue": 27451392
     }
    },
    ...

Si l'appel d'API renvoie des données de série temporelle à partir de votre instance de VM, comme indiqué ci-dessus, votre agent fonctionne correctement et vous avez terminé.

Si vous ne voyez aucune donnée de série temporelle, vérifiez les points suivants :

Si votre appel d'API génère un message d'erreur, cela n'indique pas un problème d'agent. Assurez-vous que les champs de l'explorateur d'API sont remplis correctement :
- Les erreurs "Argument non valide" indiquent probablement un problème lié à l'orthographe et au format de l'ID du projet, du filtre ou des deux horodatages.
  
  Les exigences liées aux arguments d'horodatage dépendent du type de métrique que vous spécifiez. Un type de métrique enregistre les données GAUGE, DELTA ou CUMULATIVE. Pour en savoir plus, consultez la page MetricKind.
  
  Pour les métriques DELTA et CUMULATIVE, les heures de début et de fin sont obligatoires, et l'heure de fin doit être ultérieure à l'heure de début. Ces genres de métriques enregistrent les modifications mesurées au fil du temps. Par conséquent, les heures de début et de fin doivent définir un intervalle différent de zéro.
- Les erreurs "Non autorisé" peuvent signifier que vous avez mal orthographié l'ID du projet.
- Les erreurs "Introuvable" peuvent indiquer que vous avez omis le préfixe projects/ requis dans le champ "nom".
Corrigez les problèmes et réessayez l'appel d'API.
Si l'appel d'API réussit, mais que vous ne voyez qu'une réponse vide, { }, vérifiez que le filtre et l'intervalle de temps sont corrects. Les erreurs de format des horodatages peuvent entraîner l'absence de données. Si tout semble correct, mais que vous n'obtenez aucune donnée, l'agent n'envoie pas de données de métrique, ou du moins pas au projet que vous attendez. Cela peut indiquer un problème d'identifiant. Pour en savoir plus, consultez la section Valider les identifiants de clé privée.

Réinstaller l'agent Monitoring

L'installation de la version la plus récente de l'agent peut résoudre de nombreux problèmes :

Si vous êtes certain que le problème n'est pas lié aux identifiants, vous pouvez passer directement à l'étape Effectuer l'installation sous Linux et Windows.
Pour une installation complète de l'agent et des identifiants requis, consultez la section Installer l'agent Monitoring.

Déterminer les VM Linux sur lesquelles l'agent est installé

Exécutez l'une des requêtes suivantes pour voir quelles VM Linux exécutent l'agent :
- API Explorer
- Explorateur de métriques
Notez que pour chaque requête, vous devez saisir le nom de votre projet et ajuster les délais.

Redémarrer automatiquement l'agent

Vous pouvez configurer un script pour vérifier si l'agent est en cours d'exécution, puis redémarrer celui-ci en cas de plantage.

Par exemple, sous Linux, vous pouvez créer l'entrée crontab suivante pour vérifier l'état de l'agent toutes les cinq minutes :

  */5 * * * * /bin/pidof stackdriver-collectd >/dev/null 2>&1 || /usr/sbin/service stackdriver-agent restart >/dev/null 2>&1

Problèmes connus

Les sections suivantes décrivent les problèmes connus de l'agent Monitoring.

Problème d'accès aux données de traitement (Windows)

Un message d'erreur d'agent de ce type peut s'afficher dans le journal des événements Windows :

Read access denied for processes: Registry (84), smss.exe (264), csrss.exe (376), wininit.exe (448), csrss.exe (456), services.exe (580), NisSrv.exe (3008), MsMpEng.exe (3624), csrss.exe (7044)

Ce message indique que l'agent n'a pas accès à ces données sur votre système. Pour ne plus voir ce message, vous pouvez accorder à l'utilisateur SYSTEM les autorisations nécessaires pour lire les données des processus pour les processus et services répertoriés dans les messages d'erreur. Si vous n'avez pas besoin de ces données, vous pouvez ignorer ces messages d'information en toute sécurité.

Problèmes liés au cache de métadonnées (Linux)

Un message d'erreur de ce type peut s'afficher dans le fichier journal du système Linux (/var/log/syslog sur Debian/Ubuntu ou /var/log/messages sur Red Hat/CentOS/SLES) :

collectd[25571]: uc_update: Value too old: name = myhost/processes-all/ps_vm;
value time = 1511345468.180; last cache update = 1511345468.180;
write_gcm: wg_update_stats failed.
write_gcm: uc_update returned an error.

Ces messages sont des avertissements inoffensifs et ne indiquent pas la perte de données. Ces messages sont générés par la mise en œuvre actuelle du plug-in de processus en cas d'incohérence d'horodatage.

Problème lié à la suppression d'un point de données à valeur infinie (Linux)

Un message d'erreur de ce type peut s'afficher dans le fichier journal du système Linux (/var/log/syslog sur Debian/Ubuntu ou /var/log/messages sur Red Hat/CentOS/SLES) :

write_gcm: can not take infinite value

Ce message indique la suppression d'un point de données dont le format est incorrect. Il est normalement inoffensif et peut être ignoré.

Problème de limitation de la clé de métadonnées (Linux)

Un message d'erreur de ce type peut s'afficher dans le fichier journal du système Linux (/var/log/syslog sur Debian/Ubuntu ou /var/log/messages sur Red Hat/CentOS/SLES) :

collectd[7440]:match_throttle_metadata_keys: uc_meta_data_add returned an error
collectd[7440]:match_throttle_metadata_keys: mtg_update_stats failed

Ce message indique que la mise à jour de l'état de la limitation de mémoire échoue une fois. Il est normalement inoffensif, mais peut indiquer que l'agent manque de mémoire, en particulier s'il se produit fréquemment.

Problème lié au quota de l'API Cloud Monitoring (Linux)

Un message d'erreur de ce type peut s'afficher dans le fichier journal du système Linux (/var/log/syslog sur Debian/Ubuntu ou /var/log/messages sur Red Hat/CentOS/SLES) :

collectd[25198]: write_gcm: Unsuccessful HTTP request 429

Ce message indique que la limite de quota de l'API Cloud Monitoring a été atteinte. Consultez le guide Quota pour en savoir plus sur la gestion de votre limite de quota.

Utilisation élevée de la mémoire en raison d'un faible `COLLECTD_INTERVAL` (Linux)

Vous constaterez peut-être une utilisation intensive de la mémoire de l'agent lorsque la valeur COLLECTD_INTERVAL est configurée pour être plus courte que la valeur par défaut 60 seconds, par exemple 10 seconds. Il s'agit d'une limitation connue de l'agent, car il envoie des requêtes en série à partir d'un seul thread. Pour limiter ce phénomène, envisagez de réduire COLLECTD_INTERVAL uniquement pour un sous-ensemble de métriques requises, et conservez le reste des métriques à l'intervalle par défaut.

Problème de dépassement de tampon de jeton (Linux)

Un message d'erreur de ce type peut s'afficher dans le fichier journal du système Linux (/var/log/syslog sous Debian / Ubuntu ou /var/log/messages sur Red Hat / CentOS / SLES) :

write_gcm: Error or buffer overflow when building auth_header
write_gcm: wg_oauth2_get_auth_header failed.
write_gcm: wg_transmit_unique_segment failed.
write_gcm: wg_transmit_unique_segments failed. Flushing.

Ces messages indiquent que l'agent de surveillance doit être mis à niveau vers la version 6.1.2 ou ultérieure.

La valeur "Origine" du dépôt a été modifiée (Linux)

Un message d'erreur semblable au suivant peut s'afficher lors de la mise à niveau de l'agent, de l'installation de l'agent ou de l'exécution de apt-get update sur Debian/Ubuntu Linux :

E: Repository 'https://packages.cloud.google.com/apt google-cloud-monitoring-buster-all InRelease' changed its 'Origin' value from 'google-cloud-monitoring-buster' to 'namespaces/cloud-ops-agents-artifacts/repositories/google-cloud-monitoring-buster-all'
E: Repository 'https://packages.cloud.google.com/apt google-cloud-monitoring-buster-all InRelease' changed its 'Label' value from 'google-cloud-monitoring-buster' to 'namespaces/cloud-ops-agents-artifacts/repositories/google-cloud-monitoring-buster-all'

Ce message indique que le cache du dépôt de packages a peut-être divergé par rapport à sa source. Pour ce faire, exécutez la commande suivante :

apt-get --allow-releaseinfo-change update

Ensuite, exécutez la mise à niveau ou installez à nouveau l'application.

Agent supprimé, signalé par Google Cloud Console comme étant installé

Une fois que vous avez désinstallé l'agent, un délai d'une heure peut être nécessaire pour que Google Cloud Console signale cette modification.

L'agent Monitoring n'apparaît pas dans la liste Désinstaller un programme de Windows

Pour désinstaller l'agent Monitoring lorsqu'il ne figure pas dans la liste Désinstaller un programme du panneau de configuration Windows, exécutez uninstall.exe à partir du répertoire dans lequel vous l'avez installé.

Résoudre les problèmes liés à l'agent Monitoring

Checklist

Valider le projet et les identifiants

Vérifier les identifiants Compute Engine

Vérifier les identifiants de clé privée

Des identifiants sont-ils présents ?

Les identifiants sont-ils valides ?

Générer des identifiants

Valider les données de l'agent

Réinstaller l'agent Monitoring

Déterminer les VM Linux sur lesquelles l'agent est installé

Redémarrer automatiquement l'agent

Problèmes connus

Problème d'accès aux données de traitement (Windows)

Problèmes liés au cache de métadonnées (Linux)

Problème lié à la suppression d'un point de données à valeur infinie (Linux)

Problème de limitation de la clé de métadonnées (Linux)

Problème lié au quota de l'API Cloud Monitoring (Linux)

Utilisation élevée de la mémoire en raison d'un faible COLLECTD_INTERVAL (Linux)

Problème de dépassement de tampon de jeton (Linux)

La valeur "Origine" du dépôt a été modifiée (Linux)

Agent supprimé, signalé par Google Cloud Console comme étant installé

L'agent Monitoring n'apparaît pas dans la liste Désinstaller un programme de Windows

Utilisation élevée de la mémoire en raison d'un faible `COLLECTD_INTERVAL` (Linux)