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 (voir Définir les 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 l'explorateur de journaux.

Accéder à l'explorateur 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 Cloud qui contient l'instance de VM.
    • Pour les instances de VM Amazon EC2, choisissez le [projet de connecteur AWS][aws-connector] qui associe votre compte AWS aux services Google Cloud.
  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 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."
    

Afficher le message de test

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

Accéder à l'explorateur 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 Cloud qui contient l'instance de VM.
    • Pour les instances de VM Amazon EC2, choisissez le [projet de connecteur AWS][aws-connector] qui associe votre compte AWS aux services Google Cloud.
  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.

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. 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. Un journal complet peut se présenter comme suit :

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.

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 Stackdriver Logging, vous voyez s'afficher un nom antérieur à l'API Cloud Logging, une mention Écriture seule ou Complet, les niveaux d'accès de votre instance sont appropriés pour l'agent Cloud Logging.
    3. Si, à côté d'API Stackdriver Monitoring, vous voyez s'afficher un nom antérieur à l'API Cloud Monitoring, une mention Écriture seule ou Complet, 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 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: Entités principales. Une liste de personnes, de groupes et de comptes de service doit s'afficher. La colonne Rôle contient les rôles de 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. 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 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 de sortie. 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 le trafic de sortie, 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 :

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. 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 disposer 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 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 de journal maximal que l'agent Logging peut traiter est limité au processeur. L'utilisation du processeur a tendance à augmenter lorsque le débit du journal augmente. Toutefois, l'agent, avec la configuration par défaut, ne peut utiliser qu'un seul cœur de processeur. Ainsi, lorsque le débit du journal 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 les rattrape par la suite pour les traiter à terme. Si le débit des journaux reste systématiquement élevé, les journaux risquent de surcharger le tampon et d'être perdus.

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

Si vous avez besoin d'un débit de journal plus élevé, vous pouvez envisager d'utiliser l'agent Ops. Sous Linux, pour les entrées de journal qui sont des textes bruts de 1 000 octets et n'impliquent 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.

L'agent supprimé, selon Google Cloud Console, a été installé

Une fois l'agent désinstallé, Google Cloud Console peut mettre jusqu'à une heure pour signaler cette modification.