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'agent ne parvient pas à autoriser l'accès, 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 le panneau de navigation de la console Google Cloud, sélectionnez Logging, puis Explorateur de journaux :

    Accéder à l'explorateur de journaux

  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 de connecteur AWS qui associe votre compte AWS aux services Google Cloud.

  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 :

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

Trouver votre message de test

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

  1. Dans le panneau de navigation de la console Google Cloud, sélectionnez Logging, puis Explorateur de journaux :

    Accéder à l'explorateur de journaux

  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 de connecteur AWS qui associe votre compte AWS aux services Google Cloud.

  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 le panneau de navigation de la console Google Cloud, sélectionnez Compute Engine, puis  Instances de VM :

    Accéder à la page Instances de VM

  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 :

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 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 le panneau de navigation de la console Google Cloud, sélectionnez Compute Engine, puis  Instances de VM :

    Accéder à la page Instances de VM

  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 le panneau de navigation de la console Google Cloud, sélectionnez IAM :

    Accéder à IAM

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

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

En cas d'écarts entre les configurations d'identifiants, l'agent peut utiliser des 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 êtes en train de vérifier une instance Amazon EC2, mais le projet Google Cloud 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.

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

L'exécution de 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

Consultez la page Règles de pare-feu pour en savoir plus sur la configuration des règles pour le trafic sortant.

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 Logging 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 bénéficier du rôle Éditeur. 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 Logging pour corriger ou remplacer les identifiants.
L'agent Logging arrête d'ingérer les journaux d'événements de certains canaux L'agent Logging peut silencieusement ne pas réussir à ingérer les journaux d'événements de certains canaux, même s'il est encore en cours d'exécution et ingère toujours les journaux d'agent et les journaux d'événements d'autres canaux. En effet, le plug-in windows_eventlog présente quelques problèmes, comme indiqué dans cette présentation. L'utilisation de windows_eventlog2 résout ce problème. Remarque : Le format de données du plug-in windows_eventlog2 n'est pas rétrocompatible avec le plug-in windows_eventlog. Si des pipelines BigQuery ou Google Cloud Storage sont configurés pour ces journaux, ils doivent être ajustés en conséquence. Consultez cette comparaison des entrées de journal fournie par windows_eventlog et windows_eventlog2. Pour utiliser windows_eventlog2, vous devez d'abord arrêter l'agent Logging, puis remplacer le fichier de configuration par un fichier semblable à cet exemple de fichier de configuration. Enfin, démarrez l'agent Logging.
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.
error_class=Errno::EADDRINUSE error="Address already in use - bind(2) for 0.0.0.0:24231" Plusieurs instances de l'agent Logging sont exécutées sur la VM. Utiliser ps -aux | grep "/usr/sbin/google-fluentd" pour afficher les processus d'agent en cours d'exécution (il ne doit y en avoir que deux : un superviseur et un nœud de calcul) et sudo netstat -nltp | grep :24231 pour afficher les processus en cours d'exécution qui occupent le port. Coupez les instances plus anciennes selon les besoins.
Échec du démarrage de l'agent Logging en raison d'erreurs de lib/fluent/config/types.rb La configuration de l'agent Logging utilise une section d'analyseur d'expression régulière dont l'expression régulière est incorrecte, ce qui entraîne un appel subexp non valide et des erreurs telles que Starting google-fluentd 1.8.6: /opt/google-fluentd/embedded/lib/ruby/gems/2.6.0/gems/fluentd-1.11.2/lib/fluent/config/types.rb:92: warning: invalid subexp call. Recherchez et corrigez l'expression régulière incorrecte dans le fichier de configuration de l'agent. Conseil : recherchez regex ou parse.

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