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

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. La clé de métadonnées d'instance google-logging-enable contrôle l'état d'activation de l'agent Logging. Une valeur de 0 désactive l'agent. Pour réactiver l'agent, supprimez la clé google-logging-enable ou définissez sa valeur sur 1. Pour en savoir plus, consultez la section Créer une instance avec l'agent Logging désactivé.

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

• 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 la console Google Cloud. 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.

• Si l'autorisation de l'agent échoue, vérifiez si les identifiants de votre clé privée sont manquants ou non valides.

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 l'explorateur de journaux.

1. Dans la console Google Cloud, accédez à la page Explorateur de journaux.

   Accéder à l'explorateur de journaux

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

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

   • Pour les instances de VM Compute Engine, choisissez le projet Google Cloud qui contient l'instance de VM.
   • Pour les instances de VM Amazon EC2, choisissez le projet Google Cloud auquel vous envoyez les journaux.

3. 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 l'explorateur de journaux, consultez la page Utiliser l'explorateur de 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 :

Trouver votre message de test

Après avoir envoyé un message de test, affichez-le dans l'explorateur de journaux :

1. Dans la console Google Cloud, accédez à la page Explorateur de journaux.

   Accéder à l'explorateur de journaux

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

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

   • Pour les instances de VM Compute Engine, choisissez le projet Google Cloud qui contient l'instance de VM.
   • Pour les instances de VM Amazon EC2, choisissez le projet Google Cloud auquel vous envoyez les journaux.

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

4. Une entrée de journal avec votre message de test doit s'afficher. Si tel est le cas, l'agent Logging fonctionne correctement.

Vérifier 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.

Échec du chargement des identifiants par défaut

En cas de défaillances de Could not load the default credentials dans le fichier journal de Logging, cela signifie que l'agent peut ne pas se connecter au serveur de métadonnées Compute Engine.

Le journal d'erreurs ressemble à ceci :

Starting google-fluentd 1.8.4: /opt/google-fluentd/embedded/lib/ruby/gems/2.6.0/gems/googleauth-0.9.0/lib/googleauth/application_default.rb:74:in `get_application_default': Could not load the default credentials. Browse to (RuntimeError) https://developers.google.com/accounts/docs/application-default-credentials for more information.

Ce problème peut être causé par la configuration d'un proxy personnalisé dans la VM. Pour résoudre ce problème, reportez-vous à la section Instructions de configuration du proxy pour exclure le serveur de métadonnées Compute Engine (metadata.google.internal ou 169.254.169.254) du passage par le proxy. Si l'erreur persiste, supprimez le compte de service Compute Engine par défaut de la VM, puis ajoutez-le à nouveau.

Vérifier les niveaux d'accès

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

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

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é d'API Stackdriver Logging, un ancien nom de l'API Cloud Logging, est affichée une autorisation en Écriture seule ou Totale, les niveaux d'accès de votre instance sont appropriés pour l'agent Cloud Logging.
   3. Si, à côté d'API Stackdriver Monitoring, un ancien nom de l'API Cloud Monitoring, est affichée une autorisation en Écriture seule ou Totale, les niveaux d'accès de votre instance sont 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 :

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

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

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. Dans la console Google Cloud, accédez à la page IAM :

   Accéder à IAM

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

5. Sélectionnez Afficher par : Comptes principaux. 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 compte principal 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. Le rôle Éditeur peut être automatiquement attribué au compte de service par défaut, selon la configuration de vos règles d'administration.
   • 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.

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 emplacement par défaut :

   Linux

   /etc/google/auth/application_default_credentials.json
   

   Windows

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

3. Si l'emplacement par défaut ne contient pas les identifiants, l'agent utilise les identifiants par défaut de l'application à partir du serveur de métadonnées.

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.

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}"
}

Les différences entre les configurations d'identifiants peuvent entraîner l'utilisation d'identifiants différents de ceux requis par votre service. Par exemple, si vous définissez un emplacement d'identifiant personnalisé dans GOOGLE_APPLICATION_CREDENTIALS dans le shell de connexion, mais que vous ne définissez pas cette variable dans la configuration de service de l'agent, le service recherche l'emplacement par défaut plutôt que dans votre emplacement personnalisé.

Pour examiner ou modifier la variable d'environnement des identifiants, accédez à GOOGLE_APPLICATION_CREDENTIALS ou définissez-le dans /etc/default/google-fluentd.

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 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 Compute Engine, mais le projet Google Cloud référencé dans le fichier d'identifiants n'est pas celui qui contient votre instance.
• Vous vérifiez une instance Amazon EC2, mais le projet Google Cloud référencé dans le fichier d'identifiants n'est pas celui auquel vous envoyez des journaux.
• 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.

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.

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 vos requêtes d'exclusion actives pour vous assurer que les journaux que vous recherchez ne sont pas accidentellement exclus.

Vérifier le pare-feu

Pour voir si votre instance a accès à logging.googleapis.com, exécutez la commande Linux suivante sur votre instance :

curl -sSL 'https://logging.googleapis.com/$discovery/rest?version=v2' | head

La commande peut prendre un certain temps lorsque le pare-feu bloque le trafic sortant. Exemple de résultat indiquant un problème de pare-feu :

curl: (7) Failed to connect to 2607:f8b0:4001:c03::5f: Network is unreachable

Pour savoir comment configurer des règles de trafic sortant, consultez la page Règles de pare-feu.

Réinstaller l'agent

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

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.

Limitation du débit des journaux

Le débit maximal de journaux que l'agent Logging peut traiter est conditionné par le processeur. L'utilisation de processeur a tendance à augmenter lorsque le débit des journaux augmente. Cependant, l'agent avec la configuration par défaut ne peut utiliser qu'un seul cœur de processeur. Ainsi, lorsque le débit de journaux augmente, l'agent peut atteindre une limite d'utilisation du processeur. Si ces pics ne sont que temporaires, l'agent Logging met les journaux en mémoire tampon et finit éventuellement par les traiter. Si le débit des journaux reste systématiquement élevé, les journaux en attente risquent de dépasser la capacité de mémoire tampon et d'être perdus.

En règle générale, lorsque chaque entrée de journal correspond à environ 1000 octets de texte brut et ne contient aucun traitement de format supplémentaire, l'agent Logging atteint la limite de processeur unique à environ 5500 entrées de journal par seconde. Si les entrées de journal nécessitent un traitement avancé, par exemple l'analyse JSON ou Regex, le nombre maximum d'entrées de journal par seconde peut être inférieur.

Si vous avez besoin d'un débit de journaux plus élevé, vous pouvez envisager d'utiliser l'agent Ops. Sous Linux, pour des entrées de journal contenant environ 1000 octets de texte brut et ne nécessitant aucun traitement supplémentaire, l'agent Ops peut traiter environ 160 000 entrées de journal par seconde.

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>

Les journaux sont dupliqués

LogEntry.insertID est ajouté dans le pipeline de traitement de l'agent. Si insertID a des valeurs différentes parmi les journaux en double, cela indique que les journaux sont placés plusieurs fois dans la queue de fichiers journaux. Cela peut se produire en cas de rotation des journaux, ou lorsque le fichier de position est manquant ou corrompu. Pour éviter ce problème, assurez-vous que les fichiers de position des entrées in_tail ne sont pas configurés pour se trouver dans le dossier /var/log ou dans tout autre dossier pour lequel la rotation des journaux est activée.

Le pipeline de journalisation s'appuie également sur le champ LogEntry.timestamp pour dédupliquer les journaux. Assurez-vous que l'horodatage réel de l'entrée de journal est analysé correctement. Si Fluentd n'est pas configuré pour analyser l'horodatage d'origine de l'entrée de journal, il utilise l'heure à laquelle il traite cette entrée de journal. Ainsi, si l'entrée est lue plusieurs fois, même si l'horodatage dans la ligne de journal est le même, Fluentd peut les traiter comme des entrées de journal différentes avec des horodatages différents.

Erreurs de journal d'audit répétées : Data points cannot be written more than 24h in the past

Un problème connu affecte les versions 1.8.5 à 1.9.3 (incluses) et entraîne l'apparition répétée de journaux tels que les suivants dans Journaux d'audit des accès aux données, lorsque l'agent est exécuté depuis plus de 24 heures :

Field timeSeries[0].points[0].interval.end_time had an invalid value of "2021-10-20T20:16:34.010866-07:00": Data points cannot be written more than 24h in the past.

La solution consiste à mettre à niveau l'agent vers la version 1.9.4 ou ultérieure.

Les caractères Unicode des journaux sont remplacés par des espaces ou "�"

Par défaut, l'entrée in_tail s'attend à ce que les fichiers d'entrée soient encodés au format ASCII. Elle remplace donc tout caractère non ASCII par un espace. Pour ingérer des fichiers encodés au format UTF-8, vous devez fournir deux options dans la configuration in_tail :

<source>
  @type tail
  …

  encoding UTF-8
  from_encoding UTF-8
</source>

Les deux options sont nécessaires. Si seule l'option encoding est fournie, les caractères non ASCII dans les journaux ingérés sont remplacés par "'�".

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 Logging n'apparaît pas dans la liste Désinstaller un programme de Windows

Pour désinstaller l'agent Logging 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é.