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 controllare:

  • Se i comandi di installazione di Linux generano errori, assicurati di precedere i comandi di installazione con 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 comando seguente:

      sudo service google-fluentd status

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

      sudo service google-fluentd restart

      Se il riavvio non riesce e l'output del log mostra "Disabilitato tramite metadati", è probabile che tu stia eseguendo un'immagine da 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 abilitazione dell'agente Logging, dove il valore 0 disabilita l'agente. Per riattivare l'agente, rimuovi la chiave google-logging-enable o imposta il relativo valore su 1. Per maggiori informazioni, consulta Creare un'istanza con l'agente Logging disabilitato.

      Se l'agente non viene disabilitato tramite i metadati, reinstalla l'agente. 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 propri 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 visualizzi errori HTTP 429, potresti aver superato le quote dell'API Logging. Puoi visualizzare la tua quota disponibile selezionando API e servizi > Dashboard nella console Google Cloud. Scegli l'API Logging.

      • Se riscontri problemi di accesso o autorizzazione alle API, vai a Verificare le credenziali di Compute Engine.

  • Se l'agente sembra funzionare normalmente, ma non stai ricevendo dati, devi verificare che l'agente stia inviando i dati al progetto corretto. Vedi la sezione seguente, Verificare le credenziali di Compute Engine.

  • Se l'agente non riesce a ottenere l'autorizzazione, controlla se le credenziali della chiave privata mancano o non sono valide.

Verifica l'installazione dell'agente

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

  1. Nel pannello di navigazione della console Google Cloud, seleziona Logging e poi Esplora log:

    Vai a Esplora log

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

    • Per Istanze VM di Compute Engine, scegli il progetto Google Cloud che contiene l'istanza VM.
    • Per Istanze VM Amazon EC2, scegli il progetto connettore AWS che collega il tuo account AWS ai servizi Google Cloud.

  3. Nelle schede Windows, scegli la risorsa per la tua istanza VM:

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

Se viene visualizzata la voce di log "Failed gRPC to Logging API" (Invio di gRPC all'API Logging riuscito), l'installazione dell'agente è stata completata. Questo messaggio viene generato una volta al momento dell'installazione dell'agente e ogni volta che l'agente viene riavviato.

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

Testa l'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 seguente procedura funziona su istanze VM di Compute Engine e Amazon EC2 che eseguono Linux:

  1. Verifica che l'agente Logging sia in esecuzione eseguendo questi 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 comando seguente sull'istanza della 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

Dovresti eseguire un servizio agente. Esegui i comandi seguenti 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 di quel 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 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 eseguendo una versione recente dell'agente. Per determinare la versione specifica, consulta la sezione Recupero della 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 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 test, cercalo in Esplora log:

  1. Nel pannello di navigazione della console Google Cloud, seleziona Logging e poi Esplora log:

    Vai a Esplora log

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

    • Per Istanze VM di Compute Engine, scegli il progetto Google Cloud che contiene l'istanza VM.
    • Per Istanze VM Amazon EC2, scegli il progetto connettore AWS che collega il tuo account AWS ai servizi Google Cloud.

  3. Nelle schede Windows, scegli la risorsa per la tua istanza VM:

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

  4. Dovresti vedere una voce di log con il tuo messaggio di test. Se sì, l'agente Logging funziona correttamente.

Verifica le credenziali di Compute Engine

Affinché un'istanza VM di Compute Engine possa eseguire l'agente senza credenziali della chiave privata, deve avere ambiti di accesso adeguati e l'identità dell'account di servizio utilizzata dall'istanza deve avere autorizzazioni IAM appropriate.

Quando crei un'istanza VM, l'ambito predefinito e le impostazioni dell'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 avere credenziali adatte.

Impossibile caricare le credenziali predefinite

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

Il log degli errori ha 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.

Una delle possibili cause è che la VM dispone di una configurazione proxy personalizzata. Per risolvere il problema, consulta l'istruzione di configurazione proxy per escludere il server metadati di Compute Engine (metadata.google.internal o 169.254.169.254) dal proxy. Se l'errore persiste, rimuovi l'account di servizio Compute Engine predefinito dalla VM e aggiungilo di nuovo.

Verifica gli ambiti di accesso

Per verificare gli ambiti di accesso:

  1. Nel pannello di navigazione della console Google Cloud, seleziona Compute Engine e poi Istanze VM:

    Vai a Istanze VM

  2. Fai clic sul nome dell'istanza VM. Viene visualizzata la pagina dei dettagli dell'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 viene visualizzato il messaggio "Questa istanza ha accesso API completo a tutti i servizi Google Cloud", gli ambiti di accesso sono adeguati.
    2. Se accanto all'API Stackdriver Logging è visualizzato un nome precedente per l'API Cloud Logging e disponi dell'autorizzazione Solo scrittura o Completa, gli ambiti di accesso dell'istanza sono adeguati per l'agente Cloud Logging.
    3. Se accanto ad API Stackdriver Monitoring è visualizzato un nome precedente per l'API Cloud Monitoring, disponi dell'autorizzazione Solo scrittura o Completa, gli ambiti di accesso dell'istanza sono adeguati per l'agente Cloud Monitoring.

Correggi il problema

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

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

Ambito dell'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 dell'account di servizio predefinito

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 per l'account di servizio, individua innanzitutto l'account di servizio predefinito:

  1. Nel pannello di navigazione della console Google Cloud, seleziona Compute Engine e poi Istanze VM:

    Vai a Istanze VM

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

  3. Cerca l'intestazione Account di servizio nella pagina. Viene elencato l'account di servizio predefinito per l'istanza. Potrebbe essere simile al seguente:

    [ID]-compute@developer.gserviceaccount.com

  4. Nel pannello di navigazione della console Google Cloud, seleziona IAM:

    Vai a IAM

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

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

    • Se vedi Editor, quel ruolo è appropriato per tutti gli agenti. Editor è il ruolo predefinito assegnato agli account di servizio per Compute Engine.
    • Se vedi Logs Writer, quel 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, quel ruolo è sufficiente per l'agente Monitoring. Per gli altri ruoli di Monitoring che includono l'autorizzazione di scrittura, consulta Controllo dell'accesso per Cloud Monitoring.

Correggi il problema

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

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. Nelle istanze VM AWS EC2, devi configurare l'agente per l'utilizzo di un account di servizio di questo tipo.

Per configurare l'agente in questo modo, devi creare credenziali con chiave privata per l'account di servizio designato e fornire queste credenziali all'agente.

  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 una posizione predefinita:

    Linux

    /etc/google/auth/application_default_credentials.json

    Windows

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

  3. Se la località predefinita non contiene le credenziali, l'agente utilizza le credenziali predefinite dell'applicazione del server di metadati.

Le informazioni che seguono sono utili per diagnosticare problemi relativi alle credenziali con chiave privata:

  1. La chiave privata è presente?
  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 sull'istanza VM siano installate credenziali della chiave privata valide, verifica innanzitutto che il file delle credenziali esista nel percorso previsto, quindi verifica che le informazioni contenute nel file delle credenziali siano valide.

Le credenziali sono presenti?

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

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

Se uno dei comandi visualizza un file come quello mostrato di seguito, l'istanza potrebbe avere credenziali di chiave privata valide. Se entrambi i comandi visualizzano 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 causare l'utilizzo da parte dell'agente di credenziali diverse da quelle richieste dal servizio. Ad esempio, se imposti una posizione delle credenziali personalizzate in GOOGLE_APPLICATION_CREDENTIALS nella shell di accesso, ma non imposti tale variabile nella configurazione del servizio dell'agente, il servizio cercherà nella posizione predefinita anziché nella località personalizzata.

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

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

Le credenziali sono valide?

Nel file delle credenziali, project_id è il tuo progetto Google Cloud, 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 quanto visualizzato nella sezione IAM e amministrazione > Account di servizio della console Google 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.
  • Stai controllando un'istanza Amazon EC2, ma il progetto Google Cloud nel file delle credenziali non è il progetto connettore (denominato AWS Link...) per il tuo account AWS.
  • L'account di servizio elencato non esiste. Potrebbe essere stato eliminato.
  • Nell'account di servizio elencato non sono abilitati i ruoli corretti: Writer log per l'agente Cloud Logging e Monitoring Metric Writer 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 > Account di servizio della console Google Cloud. Se non sono presenti credenziali valide, consulta la pagina relativa all'aggiunta di credenziali per sostituire le credenziali esistenti o per aggiungerne di nuove.

Se l'account di servizio è quello corretto, ma la chiave privata è stata revocata, puoi creare una nuova chiave privata e copiarla nella tua istanza. Consulta la pagina relativa alla 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 query di esclusione correnti per assicurarti che i log che stai cercando non vengano esclusi accidentalmente.

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 può richiedere del 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

Consulta le 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 tabella seguente elenca alcuni problemi comuni che potresti riscontrare con l'agente Cloud Logging e spiega come risolverli.

In 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 all'API.

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

Errore Causa Soluzione
Non è possibile eseguire il programma di installazione dell'agente su Windows 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 abilitato l'API Non hai abilitato l'API Cloud Logging nel tuo progetto. Vai alla console API e modifica lo stato dell'API Cloud Logging su ON.
La richiesta conteneva credenziali non valide
o
Impossibile recuperare il token di accesso (nessun ambito configurato?)		 L'istanza VM non dispone di credenziali adatte. Se utilizzi Amazon EC2, devi installare le credenziali sulle istanze VM prima di installare l'agente. Consulta l'articolo su come autorizzare l'agente Logging a installare le credenziali.
Autorizzazione negata Le credenziali di autorizzazione della chiave privata per l'agente Logging non sono configurate correttamente. Consulta la sezione Verifica delle credenziali della chiave privata.
Il chiamante non dispone dell'autorizzazione L'account di servizio utilizzato per l'autorizzazione nel progetto non ha autorizzazioni sufficienti. Potrebbe essere l'account di servizio predefinito utilizzato in Compute Engine o App Engine oppure potrebbe essere un account di servizio definito dall'utente utilizzato per l'autorizzazione di una 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 le procedure 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 dal 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, nell'istanza VM. Nella sezione <match **>, aggiungi la riga seguente:
project_id [YOUR_PROJECT_ID]
Altrimenti, consulta Autorizzare l'agente Logging a correggere o sostituire le credenziali.
L'agente Window Logging interrompe l'importazione dei log eventi da alcuni canali L'agente Logging potrebbe non riuscire automaticamente a importare i log eventi da determinati canali, anche se è ancora in esecuzione e sta importando i log degli agenti e i log eventi da altri canali. Il motivo è che il plug-in windows_eventlog presenta alcuni problemi, come menzionato 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 presenti pipeline di esportazione di BigQuery o Google Cloud Storage configurate per questi log, devono essere modificate di conseguenza. Consulta questo confronto delle voci di log fornito da windows_eventlog e windows_eventlog2. Per utilizzare windows_eventlog2, devi prima arrestare l'agente Logging, quindi 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 traccia della sua posizione nei file di input quando viene configurato logrotate con l'impostazione copytruncate. Ti consigliamo di utilizzare l'impostazione nocopytruncate per garantire 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="Indirizzo già in uso - bind(2) for 0.0.0.0:24231" Sulla VM sono in esecuzione più istanze dell'agente Logging. Utilizzo di ps -aux | grep "/usr/sbin/google-fluentd" per mostrare i processi dell'agente in esecuzione (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. Termina le istanze meno recenti in base alle tue esigenze.
L'agente Logging non si avvia a causa di errori di lib/fluent/config/types.rb La configurazione dell'agente Logging utilizza una sezione dell'analizzatore sintattico regex con un'espressione regolare non corretta, il che genera una chiamata con espressione secondaria 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 corretta nel file di configurazione dell'agente. Suggerimento: cerca regex o parse.

Limitazione della velocità effettiva dei log

La velocità effettiva massima dei log che l'agente Logging può elaborare è limitata dalla CPU. L'utilizzo della CPU tende a crescere con l'aumentare della velocità effettiva dei log. Tuttavia, con la configurazione predefinita, l'agente può utilizzare fino a un solo core CPU. Quindi, quando la velocità effettiva di log aumenta, l'agente potrebbe raggiungere un limite di utilizzo della CPU. Se questi picchi sono solo temporanei, l'agente Logging esegue il buffering dei log e in seguito si aggiorna per elaborarli. Se la velocità effettiva dei log rimane costantemente elevata, i log potrebbero superare il buffer e alla fine andare persi.

In genere, quando ogni voce di log è di 1000 byte di testo non elaborato e non contiene elaborazione di formati aggiuntivi, l'agente Logging raggiunge il limite di un core CPU pari 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 di log più elevata, puoi utilizzare Ops Agent. Su Linux, per le voci di log con testo non elaborato di 1000 byte e che non prevedono elaborazioni aggiuntive, Ops Agent 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 di dimensione massima, 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 alla pipeline di elaborazione all'interno dell'agente. Se insertID è diverso tra i log duplicati, significa che i log vengono eseguiti più volte in coda dai file di log. Questo può accadere in presenza di rotazione dei log o quando il file POS non è presente o è danneggiato. Per ridurre le probabilità che questo problema si verifichi, assicurati che i file di posizione per qualsiasi input in_tail non siano configurati per trovarsi nella cartella /var/log o in qualsiasi altra cartella in 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 è impostato per analizzare il timestamp originale della voce di log, allora Fluentd utilizza l'ora in cui elabora la voce di log. Di conseguenza, se l'input viene letto più volte, anche se il timestamp nella riga del log è lo stesso, Fluentd potrebbe considerarli come voci di log diverse con timestamp diversi.

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

Si è verificato un problema noto che interessa le versioni dalla 1.8.5 alla 1.9.3 (incluse) a causa del quale log come il seguente vengono ripetutamente visualizzati negli audit log di 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 consiste nell'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 siano codificati in formato ASCII, pertanto sostituisce qualsiasi carattere non ASCII con uno spazio. Per importare effettivamente i file con codifica 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 dalla console Google Cloud come installato

Dopo la disinstallazione dell'agente, la console Google Cloud potrebbe impiegare fino a un'ora per segnalare la modifica.

L'agente Logging non compare 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.