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

Checklist

Si vous rencontrez des difficultés pour installer ou utiliser l'agent Logging, voici quelques points à vérifier :

  • Si les commandes d'installation de Linux génèrent des erreurs, assurez-vous de 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 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 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-logging-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. 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 des erreurs HTTP 429 s'affichent, vous avez peut-être dépassé vos quotas d'API Logging. Vous pouvez consulter votre quota disponible en sélectionnant API et services > Tableau de bord dans Cloud Console. Choisissez l'API 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 Cloud Monitoring lorsque vous connectez votre compte AWS à un espace de travail.
    • Ne choisissez pas un projet d'espace de travail, sauf 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.

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 les versions v1-5 et ultérieures
  • 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   Cloud Logging
    
  3. Si vous interrogez les deux services, un message d'erreur et un état Running doivent s'afficher :

    • Si vous ne voyez pas l'état Running, l'agent Logging n'est pas en cours d'exécution.
    • Si vous voyez que StackdriverLogging est en cours d'exécution, vous exécutez une version récente de l'agent. Pour déterminer la version spécifique, consultez la section Obtenir le numéro de version.
    • Si vous voyez que 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 Cloud Monitoring lorsque vous connectez votre compte AWS à un espace de travail.
    • Ne choisissez pas un projet d'espace de travail, sauf 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 niveaux d'accès

Pour vérifier les niveaux 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. Dans la section Niveaux d'accès aux API Cloud, cliquez sur Détails pour afficher la liste des API. Recherchez les entrées suivantes :

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

Corriger le problème

Si votre instance Compute Engine ne dispose pas des niveaux d'accès appropriés, ajoutez les niveaux d'accès nécessaires à votre instance.

Le tableau suivant montre les niveaux d'accès spécifiques aux agents Logging et Monitoring :

Niveau 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 [PROJECT_NAME] :

    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 Cloud Logging.
    • Le rôle Rédacteur de métriques Monitoring 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 Cloud 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 admin > IAM. Ajoutez les rôles Logging ou Monitoring appropriés pour donner les autorisations nécessaires à l'agent (ou aux agents) : Logging > Rédacteur de journaux ou Monitoring > Rédacteur de métriques Monitoring.

Valider 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. Les identifiants précédemment valides peuvent être révoqués à l'aide de la section IAM et administration > 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 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 dans la section IAM et administration > 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 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é.
  • Les rôles appropriés n'ont pas été activés pour le compte de service répertorié : Rédacteur de journaux pour l'agent Cloud Logging et Rédacteur de métriques Monitoring pour l'agent Cloud 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.

Vérifier les requêtes d'exclusion de journaux

Affichez les requêtes d'exclusion actives pour vous assurer que les journaux que vous recherchez ne sont pas exclus accidentellement.

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 Cloud 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 qu'un répertoire système, tel que C:\Users\[USERID]\.
Le projet n'a pas activé l'API Vous n'avez pas activé l'API Cloud Logging dans votre projet. Accédez à la console des API et définissez l'état de l'API Cloud Logging sur ACTIVÉE.
La requête comportait des identifiants incorrects
ou
Impossible de récupérer le jeton d'accès (aucun niveau d'accès 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. Consultez la page 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 sur la page IAM de votre projet. Si nécessaire, vous pouvez modifier le niveau d'accès d'une VM existante à l'aide des procédures Modifier le compte de service et les niveaux d'accès d'une instance.
Impossible d'obtenir l'ID du projet L'agent Cloud 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 <faire correspondre **>, ajoutez la ligne suivante :
project_id [YOUR_PROJECT_ID]
Sinon, consultez la section 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. Vous pouvez également utiliser le paramètre postrotate pour redémarrer l'agent.

La taille maximale autorisée pour le journal a été atteinte

Si une ou plusieurs entrées de journal dépassent la taille maximale, vous pouvez trouver des entrées semblables à ce qui suit dans les journaux fluentd :

Dropping 1 log message(s) error_class="Google::Apis::ClientError" error="Invalid request"


ou
Dropping 1 log message(s) error="3:Log entry with size 1000515 bytes exceeds maximum size of 112640 bytes" error_code="3"

Pour résoudre cette erreur, raccourcissez les entrées de journal de manière à ce qu'elles ne dépassent pas la taille maximale. Par exemple, l'extrait de code suivant raccourcit les journaux avec le tag mytag en limitant la quantité de données dans le champ message :

# Cloud Logging only supports log entries that are up to 256 KiB in size.
# Trim the entries to just under that size to avoid dropping them.
<filter [MY_TAG]>
  @type record_transformer
  enable_ruby true
  <record>
    message ${record['message'].length > 256000 ? "[Trimmed]#{record['message'][0..256000]}..." : record['message']}
  </record>
</filter>