Risolvere i problemi dell'agente Logging

Questa pagina fornisce istruzioni per la risoluzione dei problemi comuni riscontrati durante l'installazione o l'interazione con l'agente Logging.

Elenco di controllo

Se hai difficoltà a installare o utilizzare l'agente Logging, ecco alcune cose da verificare:

  • Se i comandi di installazione di Linux restituiscono errori, assicurati di anteporre ai comandi di installazione sudo.

  • Verifica che il servizio agente sia in esecuzione sull'istanza VM:

    • Per una VM Windows, utilizza il seguente comando PowerShell:

      Get-Service -Name StackdriverLogging

      Cerca un servizio chiamato Stackdriver Logging. Se l'agente non è in esecuzione, potrebbe essere necessario riavviarlo.

    • Per una VM Linux, utilizza il seguente comando:

      sudo service google-fluentd status

      Se l'agente non è in esecuzione, potrebbe essere necessario riavviarlo utilizzando il seguente comando:

      sudo service google-fluentd restart

      Se il riavvio non va a buon fine e l'output del log mostra "Disabilitato tramite metadati", è probabile che tu stia eseguendo un'immagine di Google Cloud Marketplace, in cui l'agente Logging è disabilitato per impostazione predefinita. La chiave dei metadati dell'istanza google-logging-enable controlla lo stato di attivazione dell'agente Logging, dove un valore di 0 disattiva l'agente. Per riattivare l'agente, rimuovi la chiave google-logging-enable o imposta il relativo valore su 1. Per saperne di più, vedi Crea un'istanza con l'agente di logging disattivato.

      Se l'agente non è disattivato tramite i metadati, reinstallalo. Consulta la sezione seguente, Reinstallazione dell'agente Logging.

  • Controlla se l'agente ha scritto messaggi di errore nei log.

    • Su Windows, a partire dalla versione v1-9, l'agente Logging salva i log in C:\Program Files (x86)\Stackdriver\LoggingAgent\fluentd.log.

      Non è possibile ottenere i log per le versioni precedenti dell'agente.

    • Su Linux, l'agente Logging è un pacchetto fluentd e registra i messaggi in /var/log/google-fluentd/google-fluentd.log:

      • Se visualizzi errori HTTP 429, potresti aver superato le tue quote dell'API Logging. Puoi visualizzare la quota disponibile selezionando API e servizi > Dashboard nella console Google Cloud . Scegli l'API Logging.

      • Se riscontri problemi di accesso o autorizzazione API, consulta Verifica delle credenziali Compute Engine.

  • Se l'agente sembra funzionare normalmente, ma non ricevi dati, devi verificare che l'agente invii i dati al progetto corretto. Consulta la sezione seguente, Verifica delle credenziali di Compute Engine.

  • Se l'agente non riesce ad autorizzare, controlla se le credenziali per la tua chiave privata sono mancanti o non valide.

Verifica l'installazione dell'agente

Per verificare che l'installazione sia riuscita, cerca la voce di log di test dell'agente in Esplora log.

  1. Nella Google Cloud console, vai alla pagina Esplora log:

    Vai a Esplora log

    Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato con il sottotitolo Logging.

  2. Nella parte superiore della pagina, scegli il progetto che contiene l'istanza VM:

    • Per le istanze VM di Compute Engine, scegli il progetto Google Cloud che contiene l'istanza VM.

  3. Nelle schede di Windows, scegli la risorsa per l'istanza VM:

    • Per Compute Engine, scegli Istanza VM GCE.
    • Seleziona syslog (Linux), fluent.info (Windows) o Tutti i log.

Se vedi la voce di log "Successfully sent gRPC to Logging API" (gRPC inviato correttamente all'API Logging), l'installazione dell'agente è completata. Questo messaggio viene generato una volta quando l'agente viene installato e ogni volta che viene riavviato.

Per saperne di più su Esplora log, vedi Utilizzo di Esplora log.

Testare l'agente

Se sospetti che l'agente non funzioni, verifica che sia in esecuzione e prova a inviare un messaggio di test a Logging:

Istanza Linux

  1. Verifica che l'agente Logging sia in esecuzione eseguendo i seguenti comandi sull'istanza VM:

    ps ax | grep fluentd

    Dovresti vedere un output simile al seguente:

     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. Invia un messaggio di log di test eseguendo il seguente comando sull'istanza VM:

    logger "Some test message"

Istanza Windows

L'agente Logging ha due nomi di servizio Windows:

  • StackdriverLogging per le versioni v1-5 e successive
  • fluentdwinsvc per le versioni precedenti

Devi eseguire un servizio agente. Esegui i seguenti comandi sull'istanza VM utilizzando PowerShell:

  1. Chiedi lo stato di entrambi i servizi. Se sai quale servizio deve essere in esecuzione, puoi utilizzare solo il nome del servizio:

    Get-Service StackdriverLogging,fluentdwinsvc

  2. Se un servizio non è in esecuzione, viene visualizzato un messaggio di errore. Se è in esecuzione, vedrai un output simile al seguente:

    Status    Name                DisplayName
------    ----                -----------
Running  StackdriverLogging   Cloud Logging

  3. Se esegui una query su entrambi i servizi, dovresti visualizzare un messaggio di errore e uno stato Running:

    • Se non vedi alcuno stato Running, significa che l'agente Logging non è in esecuzione.
    • Se vedi che StackdriverLogging è in esecuzione, significa che stai utilizzando una versione recente dell'agente. Per determinare la versione specifica, consulta la sezione Ottenere la versione.
    • Se vedi che fluentdwinsvc è in esecuzione, devi eseguire l'upgrade dell'agente all'ultima versione.

  4. Richiede privilegi di amministratore: se è in esecuzione una versione dell'agente, invia un messaggio di log di test eseguendo i seguenti comandi PowerShell:

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

Trovare il messaggio di prova

Dopo aver inviato un messaggio di prova, cercalo in Esplora log:

  1. Nella Google Cloud console, vai alla pagina Esplora log:

    Vai a Esplora log

    Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato con il sottotitolo Logging.

  2. Nella parte superiore della pagina, scegli il progetto che contiene l'istanza VM:

    • Per le istanze VM di Compute Engine, scegli il progetto Google Cloud che contiene l'istanza VM.

  3. Nelle schede di Windows, scegli la risorsa per l'istanza VM:

    • Per Compute Engine, scegli Istanza VM GCE.
    • Seleziona syslog (Linux), fluent.info (Windows) o Tutti i log.

  4. Dovresti vedere una voce di log con il messaggio di prova. In questo caso, l'agente Logging funziona correttamente.

Verifica le credenziali di Compute Engine

Affinché un'istanza VM di Compute Engine esegua l'agente senza credenziali con chiave privata, l'istanza deve disporre di ambiti di accesso adatti e l'identità del service account utilizzata dall'istanza deve disporre di autorizzazioni IAM adeguate.

Quando crei un'istanza VM, le impostazioni predefinite dell'ambito e del account di servizio sono sufficienti per eseguire gli agenti. Le istanze molto vecchie o quelle per le quali hai modificato le impostazioni predefinite potrebbero non disporre di credenziali adatte.

Impossibile caricare le credenziali predefinite

Se nel file di log di Logging sono presenti Could not load the default credentials errori, significa che l'agente potrebbe non riuscire a connettersi al server dei metadati di Compute Engine.

Il log degli errori è simile al seguente:

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.

Una potenziale causa è la configurazione di un proxy personalizzato nella VM. Per risolvere il problema, fai riferimento alle istruzioni di configurazione del proxy per escludere il server metadati di Compute Engine (metadata.google.internal o 169.254.169.254) dal proxy. Se l'errore persiste, rimuovi il account di servizio Compute Engine predefinito dalla VM e aggiungilo di nuovo.

Verifica gli ambiti di accesso

Per verificare gli ambiti di accesso:

  1. Nella Google Cloud console, vai alla pagina Istanze VM.

    Vai a Istanze VM

    Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato con il sottotitolo Compute Engine.

  2. Fai clic sul nome dell'istanza. Viene visualizzata la pagina dei dettagli dell'istanza.

  3. Nella sezione Ambiti di accesso alle API Cloud, fai clic su Dettagli per visualizzare l'elenco delle API. Cerca le seguenti voci:

    1. Se vedi il messaggio "Questa istanza ha accesso completo alle API di tutti i servizi Google Cloud", i tuoi ambiti di accesso sono adeguati.
    2. Se accanto all'API Stackdriver Logging, un nome precedente per l'API Cloud Logging, vedi che hai l'autorizzazione Solo scrittura o Completa, gli ambiti di accesso della tua istanza sono adeguati per l'agente Cloud Logging.
    3. Se vedi accanto all'API Stackdriver Monitoring, un nome precedente per l'API Cloud Monitoring, che hai l'autorizzazione Solo scrittura o Completa, gli ambiti di accesso della tua istanza sono adeguati per l'agente Cloud Monitoring.

Correggere il problema

Se non disponi degli ambiti di accesso adatti nella tua istanza Compute Engine, aggiungi gli ambiti di accesso necessari alla tua istanza.

La tabella seguente mostra gli ambiti pertinenti per gli agenti Logging e Monitoring:

Ambito di accesso Autorizzazioni agente
https://www.googleapis.com/auth/logging.write Adeguato per l'agente Logging
https://www.googleapis.com/auth/monitoring.write Adeguato per l'agente Monitoring

Verifica l'autorizzazione del account di servizio predefinito

Anche se gli ambiti di accesso dell'istanza VM di Compute Engine sono adeguati, il account di servizio predefinito dell'istanza potrebbe non fornire le autorizzazioni IAM corrette per l'agente.

Per verificare l'autorizzazione del account di servizio predefinito, inizia individuando ilaccount di serviziot predefinito:

  1. Nella Google Cloud console, vai alla pagina Istanze VM.

    Vai a Istanze VM

    Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato con il sottotitolo Compute Engine.

  2. Fai clic sul nome dell'istanza. Viene visualizzata la pagina dei dettagli dell'istanza.

  3. Cerca l'intestazione Service account nella pagina. Viene visualizzato ilaccount di serviziot predefinito per l'istanza. Potrebbe avere un aspetto simile al seguente:

    [ID]-compute@developer.gserviceaccount.com

  4. Nella console Google Cloud , vai alla pagina IAM:

    Vai a IAM

    Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato con il sottotitolo IAM e amministrazione.

  5. Seleziona Visualizza per: autori. Dovresti visualizzare un elenco di persone, gruppi e account di servizio. Nella colonna Ruolo sono riportati i ruoli di ogni entità nel tuo progetto.

  6. Nella riga del account di servizio predefinito della tua istanza, dovresti visualizzare uno o più ruoli:

Correggere il problema

Se il tuo account di servizio predefinito non dispone di ruoli adeguati, prova a modificare i ruoli per ilaccount di serviziot nella pagina IAM e amministrazione > IAM. Aggiungi i ruoli Logging o Monitoring appropriati per autorizzare gli agenti: Logging > Logs Writer o Monitoring > Monitoring Metric Writer.

Verifica le credenziali della chiave privata

Nelle istanze VM di Compute Engine, puoi configurare l'agente in modo che utilizzi un account di servizio non predefinito con l'autorizzazione appropriata.

Per configurare l'agente in questo modo, devi creare le credenziali della chiave privata per il account di servizio designato e fornirle all'agente.

  1. L'agente cerca una variabile di ambiente, GOOGLE_APPLICATION_CREDENTIALS, che contiene il nome di un file che contiene le credenziali della chiave privata.

  2. Se la variabile di ambiente non è presente, l'agente cercherà le credenziali in una posizione predefinita:

    Linux

    /etc/google/auth/application_default_credentials.json

    Windows

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

  3. Se la posizione predefinita non contiene le credenziali, l'agente utilizza le credenziali predefinite dell'applicazione dal server dei metadati.

Le seguenti informazioni ti aiutano a diagnosticare i problemi relativi alle credenziali con chiave privata:

  1. La chiave privata è presente?
  2. La chiave privata è ancora valida per il account di servizio?
  3. Il account di servizio dispone dei ruoli necessari per l'agente?

Per verificare che le credenziali della chiave privata valide siano installate sull'istanza VM, verifica innanzitutto che il file delle credenziali esista nella posizione prevista, quindi verifica che le informazioni nel file delle credenziali siano valide.

Sono presenti le credenziali?

Per verificare se le credenziali del account di servizio con chiave privata sono presenti nell'istanza, esegui i seguenti comandi Linux sull'istanza:

sudo cat $GOOGLE_APPLICATION_CREDENTIALS
sudo cat /etc/google/auth/application_default_credentials.json

Se uno dei due comandi mostra un file come quello riportato di seguito, la tua istanza potrebbe avere credenziali di chiave privata valide. Se entrambi i comandi mostrano un file, viene utilizzato il file indicato da GOOGLE_APPLICATION_CREDENTIALS.

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

Le discrepanze tra le configurazioni delle credenziali potrebbero indurre l'agente a utilizzare credenziali diverse da quelle richieste dal servizio. Ad esempio, se imposti una posizione delle credenziali personalizzata in GOOGLE_APPLICATION_CREDENTIALS nella shell di accesso, ma non imposti questa variabile nella configurazione del servizio dell'agente, il servizio cercherà nella posizione predefinita anziché in quella personalizzata.

Per rivedere o modificare la variabile di ambiente delle credenziali, accedi o imposta GOOGLE_APPLICATION_CREDENTIALS in /etc/default/google-fluentd.

Se non sono presenti file di credenziali, consulta Aggiunta di credenziali.

Le credenziali sono valide?

Nel file delle credenziali, project_id è il tuo progetto Google Cloud , client_email identifica il account di servizio nel progetto e private_key_id identifica la chiave privata nel account di servizio. Abbina queste informazioni a quelle visualizzate nella sezione IAM e amministrazione > Service account della consoleGoogle Cloud .

Il file delle credenziali non è valido se si verifica una delle seguenti condizioni:

  • Stai controllando un'istanza Compute Engine, ma il progetto Google Cloud nel file delle credenziali non è il progetto che contiene l'istanza.
  • Il account di servizio elencato non esiste. Potrebbe essere stato eliminato.
  • L'account di servizio elencato non ha i ruoli corretti abilitati: Scrittore log per l'agente Cloud Logging e Scrittore metriche Monitoring per l'agente Cloud Monitoring.
  • La chiave privata non esiste. Potrebbe essere stato revocato.

Le credenziali possono essere revocate utilizzando la sezione IAM e amministrazione > Service account della Google Cloud console. Se non sono presenti credenziali valide, consulta la sezione Aggiunta di credenziali per sostituire quelle esistenti o per aggiungerne di nuove.

Se il account di servizio è quello corretto, ma la chiave privata è stata revocata, puoi creare una nuova chiave privata e copiarla nell'istanza. Vedi Creazione account di servizio account.

In caso contrario, devi creare un nuovo account di servizio come descritto nella sezione Aggiunta delle credenziali.

Verifica le query di esclusione dei log

Visualizza le query di esclusione correnti per assicurarti che i log che stai cercando non siano stati esclusi per errore.

Verifica firewall

Per verificare se la tua istanza ha accesso a logging.googleapis.com, esegui il seguente comando Linux sull'istanza:

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

Il completamento del comando potrebbe richiedere un po' di tempo quando il firewall blocca il traffico in uscita. Output di esempio che indica un problema del firewall:

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

Visita la pagina Regole firewall per informazioni su come configurare le regole per il traffico in uscita.

Reinstalla l'agente

L'installazione della versione più recente dell'agente può risolvere molti problemi:

Altri problemi comuni

La seguente tabella elenca alcuni problemi comuni che potresti riscontrare con l'agente Cloud Logging e indica come risolverli.

Su Linux, l'agente Logging registra gli errori in /var/log/google-fluentd/google-fluentd.log. Su Windows, l'agente Logging registra gli errori in C:\Program Files (x86)\Stackdriver\LoggingAgent\fluentd.log (a partire dalla versione v1-9). La classe di errore Google::APIClient::ClientError indica che si è verificato un problema con le autorizzazioni o l'accesso API.

Potresti iniziare a visualizzare errori dopo che l'agente è stato eseguito correttamente. Ad esempio, qualcuno potrebbe aver revocato le autorizzazioni richieste dal tuo progetto o dalla tua istanza VM.

Errore Causa Soluzione
L'esecuzione del programma di installazione dell'agente su Windows non riesce Potresti aver scaricato il programma di installazione in una directory di sistema. Sposta il programma di installazione in una directory non di sistema, ad esempio C:\Users\[USERID]\.
L'API non è stata abilitata per il progetto Non hai abilitato l'API Cloud Logging nel tuo progetto. Vai alla console API e imposta lo stato dell'API Cloud Logging su ON.
La richiesta aveva credenziali non valide
o
Impossibile recuperare il token di accesso (nessun ambito configurato?)		 La tua istanza VM non dispone di credenziali adatte. Consulta Autorizzazione dell'agente Logging per installare le credenziali.
Autorizzazione negata Le credenziali di autorizzazione con chiave privata per l'agente Logging non sono configurate correttamente. Consulta Verifica delle credenziali della chiave privata.
Il chiamante non dispone dell'autorizzazione Il account di servizio utilizzato per l'autorizzazione nel tuo progetto dispone di autorizzazioni insufficienti. Potrebbe trattarsi del account di servizio predefinito utilizzato in Compute Engine o App Engine oppure di un account di servizio definito dall'utente utilizzato per l'autorizzazione della chiave privata. L'account deve avere il ruolo di Editor. Modifica l'autorizzazione del account di servizio nella pagina IAM del progetto. Se necessario, puoi modificare l'ambito di accesso per una VM esistente utilizzando le procedure Modifica del account di servizio e degli ambiti di accesso per un'istanza.
Impossibile ottenere l'ID progetto L'agente Cloud Logging non è riuscito a ottenere l'ID progetto da un file delle credenziali della chiave privata di un account di servizio. Per aggiungere o sostituire un ID progetto per l'agente, modifica il file di configurazione dell'agente, /etc/google-fluentd/google-fluentd.conf, sull'istanza VM. Nella sezione <match **>, aggiungi la seguente riga:
project_id [YOUR_PROJECT_ID]
In caso contrario, consulta la sezione Autorizzare l'agente Logging per correggere o sostituire le credenziali.
L'agente Logging di Windows smette di importare i log eventi da alcuni canali L'agente Logging potrebbe non riuscire a importare i log eventi da determinati canali, anche se è ancora in esecuzione e importa i log dell'agente e i log eventi da altri canali. Il motivo è che il plug-in windows_eventlog presenta alcuni problemi, come indicato in questa presentazione. L'utilizzo di windows_eventlog2 risolve il problema. Nota: il formato dei dati del plug-in windows_eventlog2 non è compatibile con le versioni precedenti del plug-in windows_eventlog. Se sono configurate pipeline di esportazione BigQuery o Google Cloud Storage per questi log, devono essere modificate di conseguenza. Consulta questo confronto tra le voci di log fornito da windows_eventlog e windows_eventlog2. Per utilizzare windows_eventlog2, devi prima arrestare l'agente Logging e poi sostituire il file di configurazione con uno simile a questo file di configurazione di esempio. Infine, avvia l'agente Logging.
L'agente Logging interrompe l'importazione dei log in presenza di logrotate L'agente Logging potrebbe perdere la traccia della sua posizione nei file di input quando logrotate è configurato con l'impostazione copytruncate. È consigliabile utilizzare l'impostazione nocopytruncate per assicurarsi che logrotate sposti i file anziché troncarli. Se vuoi mantenere l'impostazione copytruncate, la soluzione alternativa è riavviare l'agente periodicamente. In alternativa, puoi utilizzare l'impostazione postrotate per riavviare l'agente.
error_class=Errno::EADDRINUSE error="Address already in use - bind(2) for 0.0.0.0:24231" Sulla VM sono in esecuzione più istanze dell'agente Logging. Utilizza ps -aux | grep "/usr/sbin/google-fluentd" per mostrare i processi dell'agente in esecuzione (devono essere solo due: un supervisore e un worker) e sudo netstat -nltp | grep :24231 per mostrare i processi in esecuzione che occupano la porta. Elimina le istanze meno recenti come ritieni opportuno.
L'agente Logging non viene avviato a causa di errori provenienti da lib/fluent/config/types.rb La configurazione dell'agente Logging utilizza una sezione di analisi delle espressioni regolari che contiene espressioni regolari non valide, il che comporta una chiamata subexp non valida ed errori come 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. Individua e correggi l'espressione regolare non valida nel file di configurazione dell'agente. Suggerimento: cerca regex o parse.

Limitazione del throughput dei log

La velocità effettiva massima dei log che l'agente Logging può elaborare è limitata dalla CPU. L'utilizzo della CPU tende ad aumentare quando aumenta la velocità effettiva dei log. Tuttavia, l'agente, con la configurazione predefinita, può utilizzare al massimo un solo core della CPU. Pertanto, quando il throughput dei log aumenta, l'agente potrebbe raggiungere un limite di utilizzo della CPU. Se questi picchi sono solo temporanei, l'agente Logging memorizza nel buffer i log e li recupera in un secondo momento per elaborarli. Se la velocità effettiva dei log rimane costantemente elevata, i log potrebbero superare la capacità del buffer e alla fine andare persi.

In genere, quando ogni voce di log è un testo non elaborato di 1000 byte e non contiene un'elaborazione del formato aggiuntiva, l'agente Logging raggiunge il limite di una CPU core a circa 5500 voci di log al secondo. Se le voci di log richiedono un'elaborazione avanzata, ad esempio l'analisi JSON o Regex, il numero massimo di voci di log al secondo potrebbe essere inferiore.

Se hai bisogno di una velocità effettiva dei log più elevata, puoi valutare l'utilizzo dell'agente Ops. Su Linux, per le voci di log che sono testo non elaborato di 1000 byte e non comportano un'elaborazione aggiuntiva, Ops Agent può elaborare circa 160.000 voci di log al secondo.

Dimensione massima del log superata

Se una o più voci di log hanno superato il limite di dimensioni massimo, potresti trovare voci nei log fluentd simili alle seguenti:

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


o

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

Per risolvere questo errore, taglia le voci di log in modo che non superino il limite di dimensione massimo. Ad esempio, il seguente codice campione taglia i log con il tag mytag, con i dati nel campo 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>

I log sono duplicati

LogEntry.insertID viene aggiunto nella pipeline di elaborazione all'interno dell'agente. Se insertID è diverso tra i log duplicati, significa che i log vengono estratti dai file di log più volte. Ciò può accadere in presenza di rotazione dei log o quando il file pos è mancante o danneggiato. Per ridurre la probabilità che si verifichi questo problema, assicurati che i file di posizione per qualsiasi input in_tail non siano configurati per trovarsi nella cartella /var/log o in altre cartelle in cui potrebbe essere abilitata la rotazione dei log.

La pipeline di logging si basa anche sul campo LogEntry.timestamp per eliminare i duplicati dei log. Assicurati che il timestamp effettivo della voce di log sia analizzato correttamente. Se Fluentd non è configurato per analizzare il timestamp originale della voce di log, utilizza l'ora in cui elabora la voce di log. Pertanto, se l'input viene letto più volte, anche se il timestamp nella riga di log è lo stesso, Fluentd potrebbe trattarli come voci di log diverse con timestamp diversi.

Errori ripetuti nel log di controllo: Data points cannot be written more than 24h in the past

Esiste un problema noto che interessa le versioni da 1.8.5 a 1.9.3 (inclusa) che causa la visualizzazione ripetuta di log come i seguenti negli audit log dell'accesso ai dati, quando l'agente è in esecuzione da più di 24 ore:

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 soluzione è aggiornare l'agente alla versione 1.9.4 o successive.

I caratteri Unicode nei log vengono sostituiti da spazi o dal carattere "�"

Per impostazione predefinita, l'input in_tail prevede che i file di input siano codificati in ASCII, quindi sostituisce qualsiasi carattere non ASCII con uno spazio. Per importare effettivamente file codificati in UTF-8, devi fornire due opzioni nella configurazione in_tail:

<source>
  @type tail
  …

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

Entrambe le opzioni sono necessarie. Se viene fornita solo l'opzione encoding, i caratteri non ASCII nei log importati verranno sostituiti da "�".

Agente rimosso segnalato dalla console Google Cloud come installato

Dopo aver disinstallato l'agente, la console Google Cloud potrebbe impiegare fino a un'ora per segnalare questa modifica.

L'agente Logging non viene visualizzato nell'elenco Disinstalla un programma di Windows

Per disinstallare l'agente Logging quando non è elencato nell'elenco Disinstalla un programma del Pannello di controllo di Windows, esegui uninstall.exe dalla directory in cui l'hai installato.