Risoluzione dei problemi dell'agente

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

Elenco di controllo

Se hai difficoltà a installare o utilizzare l'agente Logging, ecco alcuni aspetti da controllare:

  • Se i comandi di installazione di Linux generano errori, assicurati di far precedere i comandi di installazione da sudo.

  • Verifica che il servizio agente sia in esecuzione sulla tua istanza VM:

    • Per una VM Windows, utilizza il seguente comando di 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, potresti doverlo riavviare utilizzando il seguente comando:

      sudo service google-fluentd restart
      

      Se il riavvio non riesce e l'output del log viene visualizzato come "Disabled via metadata", verrà probabilmente eseguito un'immagine da Google Cloud Marketplace, dove l'agente Logging è disabilitato per impostazione predefinita. Viene controllata dalla chiave dei metadati dell'istanza google-logging-enable (con il valore 0). Per riattivare l'agente, rimuovila o imposta il valore su 1 (vedi Impostazione dei metadati dell'istanza).

      Se l'agente non è disabilitato tramite i metadati, reinstallalo. Vedi la sezione seguente, Reinstallare l'agente.

  • 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 recuperare i log delle 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 l'agente sembra essere in esecuzione normalmente, ma non stai ricevendo dati, devi controllare che l'agente stia inviando i dati al progetto corretto. Consulta la sezione Verificare le credenziali di Compute Engine di seguito.

Verifica l'installazione dell'agente

Per verificare che l'installazione sia andata a buon fine, cerca la voce del log di test dell'agente in Esplora log.

Vai a Esplora log

  1. Nella parte superiore della pagina, scegli il progetto contenente l'istanza VM:

    • Per Istanze VM di Compute Engine, scegli il progetto Cloud che contiene l'istanza VM.
    • Per le istanze VM Amazon EC2, scegli il [progetto connettore AWS][aws-connector] che collega il tuo account AWS ai servizi Google Cloud.
  2. Nelle schede di Windows, scegli la risorsa per l'istanza VM:

    • Per Compute Engine, scegli Istanza VM GCE.
    • Per Amazon EC2, scegli AWS EC2 Instance.
    • Seleziona syslog (Linux), fluent.info (Windows) o All logs (Tutti i log).

Se vedi una voce di log "&Inviata correttamente gRPC all'API Logging", significa che l'installazione dell'agente è stata completata. Questo messaggio viene generato una volta installato l'agente e anche ogni agente viene riavviato.

Per ulteriori informazioni su Esplora log, consulta la sezione Utilizzo di Esplora log.

Test dell'agente

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

Istanza Linux

La procedura seguente funziona su entrambe le istanze VM di Compute Engine e Amazon EC2 che eseguono Linux:

  1. Verifica che l'agente Logging sia in esecuzione eseguendo questi comandi sulla tua 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 prova eseguendo questo comando sulla tua istanza VM:

    logger "Some test message"
    

Istanza di Windows

L'agente Logging ha due nomi di servizi Windows:

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

Dovresti eseguire un servizio dell'agente. Esegui i seguenti comandi sulla tua 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 in questione:

    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 query su entrambi i servizi, dovresti vedere un messaggio di errore e uno Running di stato:

    • Se non vedi alcun stato Running, l'agente Logging non è in esecuzione.
    • Se vedi che StackdriverLogging è in esecuzione, significa che stai eseguendo una versione recente dell'agente. Per stabilire la versione specifica, vedi Scaricare la versione.
    • Se vedi che fluentdwinsvc è in esecuzione, devi eseguire l'upgrade dell'agente alla versione più recente.
  4. Richiede privilegi di amministratore: se è in esecuzione una versione dell'agente, invia un messaggio di log di prova eseguendo i comandi PowerShell seguenti:

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

Individuare il messaggio di prova

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

Vai a Esplora log

  1. Nella parte superiore della pagina, scegli il progetto contenente l'istanza VM:

    • Per Istanze VM di Compute Engine, scegli il progetto Cloud che contiene l'istanza VM.
    • Per le istanze VM Amazon EC2, scegli il [progetto connettore AWS][aws-connector] che collega il tuo account AWS ai servizi Google Cloud.
  2. Nelle schede di Windows, scegli la risorsa per l'istanza VM:

    • Per Compute Engine, scegli Istanza VM GCE.
    • Per Amazon EC2, scegli AWS EC2 Instance.
    • Seleziona syslog (Linux), fluent.info (Windows) o All logs (Tutti i log).
  3. Dovresti vedere una voce di log con il messaggio di prova. In questo caso, l'agente Logging funziona correttamente.

Verifica delle credenziali Compute Engine

Per fare in modo che un'istanza VM di Compute Engine esegua l'agente senza credenziali con chiave privata, l'istanza deve avere ambiti di accesso idonei e l'identità dell'account di servizio utilizzata dall'istanza deve disporre delle autorizzazioni IAM appropriate.

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

Impossibile caricare le credenziali predefinite

Se si verificano errori Could not load the default credentials nel file di log Logging, è possibile che l'agente non riesca a connettersi al server di metadati Compute Engine. Una potenziale causa è se la VM ha una configurazione proxy personalizzata. Per risolvere il problema, consulta l'istruzione di configurazione del proxy per escludere il server di metadati di Compute Engine (metadata.google.internal o 169.254.169.254) dal proxy. Un log completo potrebbe avere il seguente aspetto:

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.

Verifica degli ambiti di accesso

Per verificare gli ambiti di accesso:

  1. Apri la pagina Compute Engine > Istanze VM:

    Apri la pagina delle istanze

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

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

    1. Se vedi "Questa istanza ha accesso API completo a tutti i servizi Google Cloud", i tuoi ambiti di accesso sono adeguati.
    2. Se vedi accanto all'API Stackdriver Logging, un nome precedente per l'API Cloud Logging, che disponi dell'autorizzazione di scrittura solo o completa, gli ambiti di accesso dell'istanza sono sufficienti per l'agente Cloud Logging.
    3. Se vedi accanto all'API Stackdriver Monitoring, un nome precedente per l'API Cloud Monitoring, che disponi dell'autorizzazione di scrittura solo o completa, gli ambiti di accesso dell'istanza sono sufficienti per l'agente Cloud Monitoring.

Risolvere il problema

Se non disponi degli ambiti di accesso appropriati nella tua istanza di Compute Engine, aggiungi gli ambiti di accesso necessari all'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 Durata adeguata per l'agente Monitoring

Verifica dell'autorizzazione predefinita dell'account di servizio

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

Per verificare l'autorizzazione predefinita dell'account di servizio, inizia individuando l'account di servizio predefinito:

  1. Apri la dashboard di Compute Engine per il tuo progetto:

    Apri la pagina Istanze Compute Engine

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

  3. Cerca l'intestazione Account di servizio nella pagina. Viene elencato l'account di servizio predefinito per l'istanza. Ecco un esempio di come dovrebbe essere:

    [ID]-compute@developer.gserviceaccount.com
    
  4. Apri la pagina IAM e AMP dell'amministratore per il tuo progetto. L'intestazione della pagina è Autorizzazioni per il progetto [PROJECT_NAME]:

    Apri la pagina IAM

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

  6. Nella riga relativa all'account di servizio predefinito dell'istanza, dovresti vedere uno o più ruoli:

    • Se vedi il ruolo Editor, il ruolo è appropriato per tutti gli agenti. Editor è il ruolo predefinito assegnato agli account di servizio per Compute Engine.
    • Se vedi Logs Writer, il ruolo è sufficiente per l'agente Logging. Per gli altri ruoli di Logging che includono l'autorizzazione di scrittura, consulta Controllo dell'accesso per Cloud Logging.
    • Se vedi Monitoring Metric Writer, il ruolo è sufficiente per l'agente di monitoraggio. Per gli altri ruoli di Monitoring che includono l'autorizzazione di scrittura, consulta la sezione Controllo dell'accesso per Cloud Monitoring.

Risolvere il problema

Se il tuo account di servizio predefinito non dispone di ruoli sufficienti, prova a modificare i ruoli per l'account di servizio nella pagina IAM e amministrazione di IAM. Aggiungi i ruoli Logging o Monitoring per autorizzare gli agenti: Logging > Writer log o Monitoring > Monitoring Metric Writer.

Verifica delle 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. Sulle istanze VM di AWS EC2, devi configurare l'agente per utilizzare questo account di servizio.

Per configurare l'agente in questo modo, devi creare le credenziali della chiave privata per l'account di servizio designato e concedere tali credenziali all'agente. L'agente cerca le credenziali in due modi:

  1. L'agente cerca una variabile di ambiente, GOOGLE_APPLICATION_CREDENTIALS, che contiene il nome di un file contenente le credenziali della chiave privata.
  2. Se la variabile di ambiente non è presente, l'agente cercherà le credenziali in un file standard:

Linux

 /etc/google/auth/application_default_credentials.json

Windows

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

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

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

Per verificare che nell'istanza VM siano installate credenziali di chiave privata valide, verifica innanzitutto che il file delle credenziali esista nella posizione prevista, quindi verifica che le informazioni contenute nel file delle credenziali siano valide. Le credenziali valide in precedenza possono essere revocate utilizzando la sezione IAM e amministrazione; account di servizio di Cloud Console. Se non sono presenti credenziali valide, consulta la sezione Aggiungere credenziali per sostituire le credenziali esistenti o per aggiungerne altre.

Le credenziali sono presenti?

Per verificare se le credenziali dell'account di servizio private-key sono presenti nell'istanza, esegui i comandi Linux seguenti nell'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 mostrato di seguito, l'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}"
}

Se non sono presenti file di credenziali, consulta la sezione Aggiungere credenziali.

Le credenziali sono valide?

Nel file delle credenziali, project_id è il tuo progetto GCP, client_email identifica l'account di servizio nel progetto e private_key_id identifica la chiave privata nell'account di servizio. Abbina queste informazioni a ciò che è mostrato nella sezione IAM e AMP; account di servizio di Cloud Console.

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

  • Stai controllando un'istanza di Compute Engine, ma il progetto GCP nel file delle credenziali non è quello che contiene la tua istanza.
  • Stai controllando un'istanza Amazon EC2, ma il progetto GCP nel file delle credenziali non è il progetto connettore (denominato AWS Link...) per il tuo account AWS.
  • L'account di servizio indicato non esiste. Potrebbe essere stato eliminato.
  • L'account di servizio elencato non ha i ruoli corretti abilitati: Writer log per l'agente Cloud Logging e Writer metrica di Monitoring per l'agente Cloud Monitoring.
  • La chiave privata non esiste. Potrebbe essere stato revocato.

Se l'account di servizio è corretto, ma la chiave privata è stata revocata, puoi creare una nuova chiave privata e copiarla nell'istanza. Consulta la sezione Creazione delle chiavi degli account di servizio.

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

Verifica le query di esclusione dei log

Visualizza le tue query di esclusione attuali per assicurarti che i log che stai cercando non siano esclusi accidentalmente.

Verifica firewall

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

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

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

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

Visita Regole firewall per informazioni su come configurare il traffico in uscita.

Reinstallazione dell'agente

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

Altri problemi comuni

La tabella seguente illustra alcuni problemi comuni che potresti riscontrare con l'agente Cloud Logging e ti mostra 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 un problema con le autorizzazioni o l'accesso API.

Potresti iniziare a visualizzare errori dopo l'esecuzione dell'agente. 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 va a buon fine 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]\.
Il progetto non ha attivato l'API Non hai attivato 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 (non sono stati configurati ambiti?)
La tua istanza VM non dispone delle credenziali appropriate. Se utilizzi Amazon EC2, devi installare le credenziali sulle istanze VM prima di installare l'agente. Vedi Autorizzazione dell'agente per installare le credenziali.
Autorizzazione negata Le credenziali di autorizzazione della chiave privata per l'agente Logging non sono configurate correttamente. Consulta la pagina Verifica delle credenziali della chiave privata.
Il chiamante non dispone dell'autorizzazione L'account di servizio utilizzato per l'autorizzazione nel progetto non dispone delle autorizzazioni sufficienti. Potrebbe essere l'account di servizio predefinito utilizzato in Compute Engine o App Engine oppure può essere un account di servizio definito dall'utente per l'autorizzazione della chiave privata. L'account deve avere il ruolo di Editor. Modifica l'autorizzazione dell'account di servizio nella pagina IAM del progetto. Se necessario, puoi modificare l'ambito di accesso per una VM esistente utilizzando la procedura di modifica dell'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, nella tua istanza della VM. Nella sezione <match **>, aggiungi la seguente riga:
project_id [YOUR_PROJECT_ID]
In caso contrario, consulta Autorizzazione dell'agente per correggere o sostituire le credenziali.
L'agente Logging della finestra interrompe l'importazione dei log eventi da alcuni canali L'agente Logging potrebbe non essere in grado di importare i log eventi da alcuni canali, anche se è ancora in esecuzione e importa i log agenti e i log eventi da altri canali. Il motivo è che il plug-in windows_eventlog ha alcuni problemi menzionati in questa presentazione. L'utilizzo di Windows_eventlog2 risolve il problema. Nota: il formato dei dati del plug-in windows_eventlog2 non è compatibile con il plug-in windows_eventlog. Se ci sono pipeline di BigQuery o Google Cloud Storage esportate configurate per questi log, devono essere adattate 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 in cui si trova nei file di input quando logrotate è configurato con l'impostazione copytruncate. È preferibile utilizzare l'impostazione nocopytruncate per assicurarti che la rotazione dei file sposti i file invece di 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={quot;Indirizzo già in uso - bind(2) per 0.0.0.0:24231" Più istanze di agente Logging sono in esecuzione sulla VM. L'utilizzo di ps -aux | grep "/usr/sbin/google-fluentd" per mostrare i processi in esecuzione dell'agente (dovrebbero 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 previsto.
L'agente Logging non si avvia a causa di errori da lib/fluent/config/types.rb La configurazione dell'agente Logging utilizza una sezione dell'analizzatore sintattico regex che ha un'espressione regolare non valida, con il risultato di una chiamata subexp e di errori non validi 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 della velocità effettiva del log

La velocità effettiva di log massima che l'agente Logging può elaborare è limitata dalla CPU. L'utilizzo della CPU tende a crescere con l'aumento della velocità effettiva del log. Tuttavia, l'agente, con la configurazione predefinita, può utilizzare fino a un core CPU. Pertanto, quando il valore della velocità effettiva di log aumenta, l'agente potrebbe raggiungere un limite di utilizzo della CPU. Se questi picchi sono solo temporanei, l'agente di logging esegue il buffer e inserisce i log in un secondo momento per elaborarli. Se la velocità effettiva di log rimane costantemente elevata, i log potrebbero superare il buffer e andare persi.

In genere, se ogni voce di log ha un testo non elaborato di 1000 byte e non contiene ulteriore elaborazione del formato, l'agente Logging raggiunge il limite principale della CPU con 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 del log più elevata, potresti utilizzare l'agente operativo. Su Linux, per le voci di log che sono testo non elaborato di 1000 byte e che non richiedono ulteriori elaborazioni, l'agente operativo può elaborare circa 160.000 voci di log al secondo.

Dimensione massima del log superata

Se una o più voci di log superano il limite massimo di dimensioni, nei log fluentd potrebbero essere presenti voci simili alla seguente:

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


oppure

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 del log in modo che non superino il limite massimo di dimensione. Ad esempio, il seguente codice di esempio consente di ritagliare i log con il tag mytag, con i dati contenuti 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 ricavati più volte dai file di log. Questo potrebbe verificarsi in presenza di rotazione del log o quando il file di posizione manca o è danneggiato. Per ridurre la possibilità di questo problema, assicurati che i file di posizione per qualsiasi input in_tail non siano configurati nella cartella /var/log o in eventuali altre cartelle per cui è abilitata la rotazione dei log.

La pipeline di logging si basa anche sul campo LogEntry.timestamp per deduplicare i log. Assicurati che il timestamp effettivo della voce di log sia analizzato correttamente. Se Fluentd non è configurato per analizzare il timestamp originale dalla voce di log, Fluentd utilizza il momento in cui elabora la voce di log. Pertanto, se l'input viene letto più volte, anche se il timestamp nella riga di log è uguale, Fluentd potrebbe considerarli come voci di log diverse con timestamp differenti.

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

Esiste un problema noto che riguarda le versioni da 1.8.5 a 1.9.3 (incluse), a causa dei quali i log come quelli riportati di seguito vengono visualizzati ripetutamente negli audit log degli accessi 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 è eseguire l'upgrade dell'agente alla versione 1.9.4 o successiva.

I caratteri Unicode nei log vengono sostituiti da spazi o ' '

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

<source>
  @type tail
  …

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

Sono necessarie entrambe le opzioni. Se viene fornita solo l'opzione encoding, i caratteri non ASCII nei log importati verranno sostituiti da ' '.

Agente rimosso segnalato da Google Cloud Console come installato

Dopo aver disinstallato l'agente, potrebbe essere necessaria fino a un'ora per segnalare la modifica in Google Cloud Console.