Dépanner l'agent

Cette page explique comment résoudre les problèmes courants rencontrés lors de l'installation ou de l'interaction avec l'agent Stackdriver Logging.

Checklist

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

  • Si les commandes d'installation Linux génèrent des erreurs, assurez-vous de les préfixer avec 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 StackdriverLogging
      

      Recherchez un service appelé Stackdriver Logging. 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 google-fluentd 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 google-fluentd 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 Cloud Marketplace, où l'agent Stackdriver Logging est désactivé par défaut. Ceci est contrôlé par la clé de métadonnées d'instance google-logging-enable (avec la valeur 0). Pour réactiver l'agent, supprimez cette clé ou définissez la valeur sur 1 (voir 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. Reportez-vous à la section suivante, Réinstaller l'agent.

  • Vérifiez que l'agent a écrit des messages d'erreur dans les journaux.

    • Sous Windows, à partir de la version v1-9, l'agent Logging enregistre ses journaux dans C:\Program Files (x86)\Stackdriver\LoggingAgent\fluentd.log.

      Il n'existe aucun moyen d'obtenir les journaux des versions précédentes de l'agent.

    • Sous Linux, l'agent Logging correspond à un package fluentd et consigne les messages dans /var/log/google-fluentd/google-fluentd.log :

      • Si vous voyez des erreurs HTTP 429, vous avez peut-être dépassé vos quotas d'API Stackdriver Logging. Vous pouvez consulter votre quota disponible en sélectionnant API et services > Tableau de bord dans la console GCP. Choisissez l'API Stackdriver Logging.

      • Si vous rencontrez des problèmes d'accès ou d'autorisation à l'API, reportez-vous à la section Vérifier les identifiants Compute Engine.

  • Si l'agent semble fonctionner normalement, mais que vous n'obtenez pas de données, vous devez alors vérifier que l'agent envoie les données au bon projet. Consultez la section suivante, Vérifier les identifiants Compute Engine.

Vérifier l'installation de l'agent

Pour vérifier que l'installation a réussi, recherchez l'entrée de test de l'agent dans la visionneuse de journaux.

Accéder à la visionneuse de journaux

  1. En haut de la page, sélectionnez le projet contenant votre instance de VM :

    • Pour les instances de VM Compute Engine, choisissez le projet qui contient l'instance de VM.
    • Pour les instances de VM Amazon EC2, choisissez le projet AWS LINK créé par Stackdriver lorsque vous connectez votre compte AWS à un espace de travail.
    • Ne sélectionnez un projet d'espace de travail que s'il contient votre instance de VM Compute Engine.
  2. Dans les onglets de la fenêtre, sélectionnez la ressource de votre instance de VM :

    • Pour Compute Engine, sélectionnez Instance de VM GCE.
    • Pour Amazon EC2, sélectionnez Instance AWS EC2.
    • Sélectionnez syslog (Linux), fluent.info (Windows) ou Tous les journaux.

Si une entrée de journal affiche le message "Successfully sent gRPC to Stackdriver Logging API" (Envoi réussi de gRPC à l'API Stackdriver Logging), l'installation de l'agent est terminée. Ce message est généré une fois lorsque l'agent est installé et à chaque fois que l'agent est redémarré.

Pour en savoir plus sur la visionneuse de journaux, consultez la section Afficher les journaux.

Tester l'agent

Si vous pensez que l'agent ne fonctionne pas, vérifiez qu'il est en cours d'exécution et essayez d'envoyer un message de test à Stackdriver Logging :

Instance Linux

La procédure suivante fonctionne sur les instances de VM Compute Engine et Amazon EC2 exécutant Linux :

  1. Vérifiez que l'agent Logging est en cours d'exécution en exécutant les commandes suivantes sur votre instance de VM :

    ps ax | grep fluentd
    

    Un résultat semblable aux lignes suivantes doit s'afficher :

     2284 ?        Sl     0:00 /opt/google-fluentd/embedded/bin/ruby /usr/sbin/google-fluentd [...]
     2287 ?        Sl    42:44 /opt/google-fluentd/embedded/bin/ruby /usr/sbin/google-fluentd [...]
    
  2. Envoyez un message de journal de test en exécutant la commande suivante sur votre instance de VM :

    logger "Some test message"
    

Instance Windows

L'agent Logging possède deux noms de service Windows :

  • StackdriverLogging pour la version v1-5 ou ultérieure
  • fluentdwinsvc pour les versions antérieures

Vous devez exécuter un seul service d'agent. Exécutez les commandes suivantes sur votre instance de VM à l'aide de PowerShell :

  1. Obtenez l'état des deux services. Si vous savez lequel doit être en cours d'exécution, vous pouvez saisir uniquement le nom de ce service :

    Get-Service StackdriverLogging,fluentdwinsvc
    
  2. Si un service n'est pas en cours d'exécution, un message d'erreur s'affiche. S'il est en cours d'exécution, un message semblable à celui-ci s'affiche :

    Status    Name                DisplayName
    ------    ----                -----------
    Running  StackdriverLogging   Stackdriver Logging
    
  3. Si vous interrogez les deux services, un message d'erreur et un état Running doivent s'afficher :

    • Si l'état Running ne s'affiche pas, l'agent Logging n'est pas en cours d'exécution.
    • Si StackdriverLogging est en cours d'exécution, vous disposez d'une version récente de l'agent. Pour déterminer la version spécifique, consultez la section Obtenir le numéro de version.
    • Si fluentdwinsvc est en cours d'exécution, vous devez mettre à niveau l'agent vers la dernière version.
  4. Droits d'administrateur requis : Si une version de l'agent est en cours d'exécution, envoyez un message de journal de test en exécutant les commandes PowerShell suivantes :

    New-EventLog   -LogName Application -Source "Test Source"
    Write-EventLog -LogName Application -Source "Test Source" -EntryType Information -EventID 1 -Message "Testing 123 Testing."
    

Afficher le message de test

Après avoir envoyé un message de test, affichez-le dans la visionneuse de journaux :

Accéder à la visionneuse de journaux

  1. En haut de la page, sélectionnez le projet contenant votre instance de VM :

    • Pour les instances de VM Compute Engine, choisissez le projet qui contient l'instance de VM.
    • Pour les instances de VM Amazon EC2, choisissez le projet AWS LINK créé par Stackdriver lorsque vous connectez votre compte AWS à un espace de travail.
    • Ne choisissez un projet d'espace de travail que s'il s'agit du projet contenant votre instance de VM Compute Engine.
  2. Dans les onglets de la fenêtre, sélectionnez la ressource de votre instance de VM :

    • Pour Compute Engine, sélectionnez Instance de VM GCE.
    • Pour Amazon EC2, sélectionnez Instance AWS EC2.
    • Sélectionnez syslog (Linux), fluent.info (Windows) ou Tous les journaux.
  3. Une entrée de journal avec votre message de test doit s'afficher. Si tel est le cas, l'agent Logging fonctionne correctement.

Valider les identifiants Compute Engine

Pour qu'une instance de VM Compute Engine exécute l'agent sans identifiants de clé privée, l'instance doit avoir des champs d'application d'accès appropriés, et l'identité du compte de service utilisée par l'instance doit disposer des autorisations IAM appropriées.

Lorsque vous créez une instance de VM, les paramètres de champ d'application et de compte de service par défaut suffisent pour exécuter les agents. Les instances très anciennes ou celles pour lesquelles vous avez modifié les paramètres par défaut peuvent ne pas avoir d'identifiants appropriés.

Vérifier les champs d'application d'accès

Pour vérifier les champs d'application d'accès, procédez comme suit :

  1. Ouvrez la page Compute Engine > Instances de VM :

    Ouvrir la page des instances

  2. Cliquez sur le nom de votre instance de VM. La page d'informations correspondante s'affiche.

  3. Regardez sous la rubrique Champs d'application de l'accès aux API Cloud de la page.

    1. Si vous voyez le texte "L'instance dispose d'un accès API complet à tous les services Google Cloud", vous disposez des champs d'application d'accès appropriés.
    2. Si, à côté de API Stackdriver Logging, vous voyez que vous disposez d'une autorisation d'accès Écriture seule ou Complet, votre instance dispose des champs d'application d'accès appropriés pour l'agent Stackdriver Logging.
    3. Si, à côté de API Stackdriver Monitoring, vous voyez que vous disposez d'une autorisation d'accès Écriture seule ou Complet, votre instance dispose des champs d'application d'accès appropriés pour l'agent Stackdriver Monitoring.

Corriger le problème

Si vous ne disposez pas des champs d'application d'accès appropriés pour votre instance Compute Engine, ajoutez les champs d'application d'accès nécessaires à votre instance.

Le tableau suivant montre les champs d'application relatifs aux agents Stackdriver Logging et Monitoring :

Champ d'application d'accès Autorisations d'agent
https://www.googleapis.com/auth/logging.write Adéquat pour l'agent Logging
https://www.googleapis.com/auth/monitoring.write Adéquat pour l'agent Monitoring

Vérifier les autorisations par défaut du compte de service

Même si votre instance de VM Compute Engine dispose des champs d'application d'accès adéquats, le compte de service par défaut de l'instance peut ne pas fournir les autorisations IAM appropriées pour l'agent.

Pour vérifier les autorisations du compte de service par défaut, commencez par localiser ce compte de service :

  1. Ouvrez le tableau de bord Compute Engine pour votre projet :

    Ouvrir la page Instances Compute Engine

  2. Cliquez sur le nom de votre instance de VM. La page d'informations correspondante s'affiche.

  3. Recherchez la rubrique Compte de service de la page. Le compte de service par défaut pour l'instance s'affiche. Il peut se présenter sous la forme suivante :

    [ID]-compute@developer.gserviceaccount.com
    
  4. Ouvrez la page IAM et administration > IAM pour votre projet. L'en-tête de la page est Autorisations pour le projet [NOM_PROJET] :

    Ouvrir la page IAM

  5. Sélectionnez Afficher par : Membres. Une liste de personnes, de groupes et de comptes de service doit s'afficher. Dans la colonne Rôle figurent les rôles dont dispose chaque membre dans votre projet.

  6. Sur la ligne du compte de service par défaut de votre instance, un ou plusieurs rôles doivent s'afficher :

    • Le rôle Collaborateur est approprié pour tous les agents. Collaborateur est le rôle par défaut attribué aux comptes de service pour Compute Engine.
    • Le rôle Rédacteur de journaux est suffisant pour l'agent Logging. Pour les autres rôles Logging incluant une autorisation en écriture, consultez la section Contrôle d'accès pour Stackdriver Logging.
    • Le rôle Rédacteur de métriques de surveillance est suffisant pour l'agent Monitoring. Pour les autres rôles Monitoring incluant une autorisation en écriture, consultez la section Contrôle d'accès pour Stackdriver Monitoring.

Corriger le problème

Si votre compte de service par défaut ne dispose pas des rôles adéquats, essayez de modifier les rôles de votre compte de service dans la page IAM et administration > IAM. Ajoutez les rôles Logging ou Monitoring appropriés pour donner les autorisations nécessaires à l'agent (aux agents) : Logging > Rédacteur de journaux ou Monitoring > Rédacteur de statistiques de surveillance.

Vérifier les identifiants de clé privée

Sur les instances de VM Compute Engine, vous pouvez configurer l'agent pour qu'il utilise un compte de service autre que celui défini par défaut et disposant des autorisations appropriées. Sur les instances de VM AWS EC2, vous devez configurer l'agent pour qu'il utilise un tel compte de service.

Pour configurer l'agent de cette façon, vous devez créer des identifiants de clé privée pour le compte de service désigné et donner ces identifiants à l'agent. L'agent recherche les identifiants de deux manières :

  1. L'agent recherche une variable d'environnement (GOOGLE_APPLICATION_CREDENTIALS), qui contient le nom d'un fichier, contenant lui-même les identifiants de clé privée.
  2. S'il n'y a pas de variable d'environnement, l'agent recherche les identifiants dans un fichier standard :

Linux

 /etc/google/auth/application_default_credentials.json

Windows

C:\ProgramData\Google\Auth\application_default_credentials.json

Les informations suivantes vous aident à diagnostiquer les problèmes liés aux identifiants de clé privée :

  1. La clé privée est-elle en place ?
  2. La clé privée est-elle toujours valide pour le compte de service ?
  3. Le compte de service a-t-il les rôles requis pour l'agent ?

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 IAM et administration > Comptes de service de la console GCP. 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 GCP, 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 affichées sous la section IAM et administration > Comptes de service de la console GCP.

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 Compute Engine, mais le projet GCP référencé 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 GCP référencé dans le fichier d'identifiants n'est pas le projet de connecteur (nommé AWS Link...) pour votre compte AWS.
  • Le compte de service répertorié n'existe pas. Il a peut-être été supprimé.
  • Le compte de service répertorié n'a pas les rôles appropriés activés : Rédacteur de journaux pour l'agent Stackdriver Logging et Rédacteur de métriques de surveillance pour l'agent Stackdriver Monitoring.
  • 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. Consultez la section Créer des clés de compte de service.

Sinon, vous devez créer un nouveau compte de service comme indiqué à la section Ajouter 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 :

Autres problèmes courants

Le tableau suivant répertorie certains problèmes courants que vous pouvez rencontrer avec l'agent Stackdriver Logging et vous indique comment les résoudre.

Sous Linux, l'agent Logging enregistre les erreurs dans /var/log/google-fluentd/google-fluentd.log. Sous Windows, l'agent Logging enregistre les erreurs dans C:\Program Files (x86)\Stackdriver\LoggingAgent\fluentd.log (à partir de la version v1-9). La classe d'erreur Google::APIClient::ClientError indique qu'il existe un problème avec les autorisations ou l'accès à l'API.

Des erreurs peuvent commencer à s'afficher après l'exécution de l'agent. Par exemple, un utilisateur a peut-être révoqué les autorisations requises de votre projet ou de votre instance de VM.

Erreur Cause Solution
Le programme d'installation de l'agent sur Windows ne s'exécute pas Vous avez peut-être téléchargé le programme d'installation dans un répertoire système. Déplacez le programme d'installation vers un répertoire autre que système, tel que C:\Users\[USERID]\.
Le projet n'a pas activé l'API Vous n'avez pas activé l'API Stackdriver Logging dans votre projet. Accédez à la console de l'API et définissez l'état de l'API Stackdriver Logging sur ACTIVÉ.
La requête comporte des identifiants incorrects
ou
Impossible de récupérer le jeton d'accès (aucun champ d'application configuré ?)
L'instance de VM ne dispose pas d'identifiants appropriés. Si vous utilisez Amazon EC2, vous devez configurer les identifiants sur les instances de VM avant d'installer l'agent. Voir Autoriser l'agent pour configurer les identifiants.
Échec de l'autorisation Les identifiants d'autorisation via une clé privée associés à l'agent Logging ne sont pas configurés correctement. Voir Valider les identifiants de clé privée.
L'appelant n'a pas l'autorisation requise Le compte de service utilisé pour l'autorisation dans votre projet dispose d'autorisations insuffisantes. Il peut s'agir du compte de service par défaut utilisé dans Compute Engine ou App Engine, ou d'un compte de service défini par l'utilisateur pour l'autorisation via une clé privée. Le compte doit avoir l'autorisation Modifications autorisées. Modifiez l'autorisation du compte de service dans la page IAM votre projet. Si nécessaire, vous pouvez modifier le champ d'application d'accès d'une VM existante à l'aide des procédures Modifier le compte de service et les champs d'application d'accès d'une instance.
Impossible d'obtenir l'ID du projet L'agent Stackdriver Logging n'a pas pu obtenir l'ID du projet à partir du fichier d'identifiants de la clé privée d'un compte de service. Pour ajouter ou remplacer un ID de projet pour l'agent, modifiez le fichier de configuration de l'agent, /etc/google-fluentd/google-fluentd.conf, sur votre instance de VM. Dans la section <match **>, ajoutez la ligne suivante :
project_id [YOUR_PROJECT_ID]
Sinon, voir Autoriser l'agent pour corriger ou remplacer les identifiants.
L'agent Logging arrête d'ingérer des journaux en présence de logrotate L'agent Logging peut perdre la trace de son emplacement dans les fichiers d'entrée lorsque logrotate est configuré avec le paramètre copytruncate. Il est préférable d'utiliser le paramètre nocopytruncate pour s'assurer que logrotate déplace les fichiers au lieu de les tronquer. Si vous souhaitez conserver le paramètre copytruncate, la solution de contournement consiste à redémarrer l'agent régulièrement. Autrement, vous pouvez aussi utiliser le paramètre postrotate pour redémarrer l'agent.
Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Stackdriver Logging
Besoin d'aide ? Consultez notre page d'assistance.