Dépannage de l'installation de l'agent

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

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.

  • 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 Cloud Console. 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 personnalisées.

        • 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 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 :

  • Pour voir si des données arrivent dans Monitoring, essayez de lire certaines données de la série temporelle. Pour savoir comment procéder, consultez la section Valider la connexion entre agent et projet. Si des données s'affichent, le problème ne vient pas de l'agent.

  • 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 la section Autoriser l'agent. 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 du connecteur AWS. Pour plus d'informations sur les identifiants, consultez la section Autoriser l'agent. 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.

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 :

  1. 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.

  2. Accédez à la page de documentation pour la méthode timeSeries.list :

  3. 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/. Exemple : projects/[YOUR_PROJECT_ID]. Pour les instances Amazon EC2, vous devez utiliser le projet de connecteur AWS pour votre compte Amazon.

    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.

  4. 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": "[GCP-OR-AWS-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.

Valider les identifiants Compute Engine

Utilisez la page Instances de VM Compute Engine de Cloud Console pour vérifier que votre instance de VM Compute Engine dispose des identifiants appropriés 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.

Accéder à la page "Instances Compute Engine"

  1. 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.
  2. 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.
  3. Sur la page Détails de l'instance de VM, regardez sous l'en-tête Niveaux d'accès aux API Cloud :
    1. Si "Autoriser l'accès complet à l'ensemble des API Cloud" s'affiche, vous disposez des identifiants appropriés.
    2. 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.
    3. 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. Les identifiants précédemment valides peuvent être révoqués à l'aide de la section IAM et administration et comptes de service de Cloud Console. 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, 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 compte de service. Faites correspondre ces informations avec celles présentées dans la section IAM et administration et comptes de service de Cloud Console.

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 de connecteur AWS pour 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 l'agent de surveillance et roles/logging.logWriter (Rédacteur de journaux) pour l'agent Logging.
  • 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:

  1. Pour chaque projet connecté contenant des instances devant être autorisées avec une clé privée (projets de connecteur AWS et projets contenant des instances Compute Engine créées sans inclure le champ d'application)monitoring.write ), créez un compte de service et générez une clé privée, s'ils n'existent pas déjà. Suivez ces instructions :

    1. Pour afficher la liste des projets associés au champ d'application des métriques, accédez à Monitoring:

      Accéder à Monitoring

    2. Dans le volet de navigation "Monitoring", sélectionnez Paramètres, puis l'onglet Résumé :

      • Pour AWS, utilisez le lien pour accéder directement à Google Cloud Console pour le projet en question.
      • Pour Google Cloud, identifiez le projet contenant les ressources Compute Engine en question, puis accédez à Google Cloud Console.
    3. Dans Google Cloud Console, accédez à la page Comptes de service IAM.

    4. Créez un compte de service et générez une nouvelle clé privée pour ce compte.

      La méthode la plus simple consiste à télécharger une clé privée avec la configuration adaptée. Vous pouvez obtenir cette clé en modifiant l'URL de la page actuelle : ajoutez &createStackdriverServiceAccount à la fin de celle-ci. Pour plus d'informations, consultez la section Créer un compte de service.

  2. 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 plus d'informations, consultez la section Copier la clé privée sur l'instance.
  3. 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, à savoir :

  • 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 de project-id correspond à celle du projet surveillé pour lequel vous venez de générer des identifiants.

Réinstaller l'agent

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

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 :

    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

  • 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 de 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 de suppression d'unpoint 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 la mémoire tampon du jeton (Linux) :

    Un message d'erreur semblable à celui-ci peut s'afficher dans le fichier journal du système Linux (/var/log/syslog sous Debian / Ubuntu ou /var/log/messages de 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.

L'agent signalé par Google Cloud Console comme installé a été supprimé

Une fois l'agent désinstallé, il peut s'écouler jusqu'à une heure avant que Google Cloud Console ne signale cette modification.