Risolvi i problemi dell'agente Logging

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

In questa pagina vengono fornite istruzioni per la risoluzione dei problemi comuni riscontrati durante l'installazione o l'interazione con l'agente Logging.

Elenco di controllo

In caso di problemi durante l'installazione o l'utilizzo dell'agente Logging, controlla quanto segue:

  • Se i comandi di installazione di Linux generano errori, assicurati di anteporre i comandi di installazione a 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, potresti doverlo riavviare.

    • Per una VM Linux, utilizza il comando seguente:

      sudo service google-fluentd status
      

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

      sudo service google-fluentd restart
      

      Se il riavvio non va a buon fine e l'output del log mostra il messaggio "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 attivazione dell'agente Logging, dove un valore 0 disabilita l'agente. Per riattivare l'agente, rimuovi la chiave google-logging-enable o imposta il relativo valore su 1. Per ulteriori informazioni, consulta Creare un'istanza con l'agente Logging disabilitato.

      Se l'agente non viene disattivato tramite i metadati, reinstalla l'operazione. Vedi la sezione seguente, Reinstallare l'agente Logging.

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

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

      Non è possibile recuperare 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 l'agente sembra funzionare normalmente, ma non stai ricevendo dati, devi controllare che l'agente stia inviando i dati al progetto corretto. Consulta la sezione seguente, Verifica delle credenziali di Compute Engine.

  • Se l'agente non autorizza, controlla se le credenziali per la chiave privata non sono presenti o non sono valide.

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 che contiene la tua 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 che collega il tuo account AWS ai servizi Google Cloud.
  2. Nelle schede Windows, scegli la risorsa per l'istanza VM:

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

Se compare la voce di log "Inviata gRPC all'API Logging", significa che l'installazione dell'agente è stata completata. Questo messaggio viene generato una volta installato l'agente e anche 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 test a Logging:

Istanza Linux

La seguente procedura funziona sia sulle istanze VM di Compute Engine sia su Amazon EC2 che utilizzano 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 prova eseguendo il comando seguente sulla tua istanza VM:

    logger "Some test message"
    

Istanza Windows

L'agente Logging ha due nomi di servizio Windows:

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

Devi eseguire un servizio agente. Esegui questi 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 di quel servizio:

    Get-Service StackdriverLogging,fluentdwinsvc
    
  2. Se un servizio non è in esecuzione, viene visualizzato un messaggio di errore. Se è in esecuzione, vedrai l'output come segue:

    Status    Name                DisplayName
    ------    ----                -----------
    Running  StackdriverLogging   Cloud Logging
    
  3. Se esegui query su entrambi i servizi, dovresti vedere un messaggio di errore e uno Running sullo stato:

    • Se non viene visualizzato lo stato Running, significa che l'agente Logging non è in esecuzione.
    • Se vedi che StackdriverLogging è in esecuzione, stai eseguendo una versione recente dell'agente. Per determinare la versione specifica, consulta la sezione Come ottenere la versione specifica.
    • Se noti che fluentdwinsvc è in esecuzione, devi eseguire l'upgrade dell'agente alla versione più recente.
  4. Richiede i 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."
    

Trovare 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 che contiene la tua 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 che collega il tuo account AWS ai servizi Google Cloud.
  2. Nelle schede Windows, scegli la risorsa per l'istanza VM:

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

Verifica le credenziali di Compute Engine

Affinché un'istanza VM di Compute Engine possa eseguire l'agente senza le credenziali della chiave privata, l'istanza deve avere ambiti di accesso adeguati e l'identità dell'account di servizio utilizzata dall'istanza deve avere le 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 avere credenziali adatte.

Impossibile caricare le credenziali predefinite

Se si verificano errori Could not load the default credentials nel file di log Logging, significa che 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.

Ciò potrebbe essere dovuto al fatto che la VM ha una configurazione proxy personalizzata. Per risolvere il problema, consulta l'istruzione di configurazione proxy per escludere il server di metadati 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. 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 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 completo all'API per tutti i servizi Google Cloud", gli ambiti di accesso sono adeguati.
    2. Se accanto a API Stackdriver Logging, un nome precedente dell'API Cloud Logging, che disponi dell'autorizzazione di scrittura solo o completa, gli ambiti di accesso dell'istanza sono adeguati per l'agente Cloud Logging.
    3. Se accanto all'API Stackdriver Monitoring, per l'API Cloud Monitoring, hai un nome con autorizzazione di sola scrittura o completa, gli ambiti di accesso dell'istanza sono adeguati per l'agente Cloud Monitoring.

Correggi il problema

Se non disponi degli ambiti di accesso adatti 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 dell'accesso Autorizzazioni agente
https://www.googleapis.com/auth/logging.write Adatto per l'agente Logging
https://www.googleapis.com/auth/monitoring.write Adatto per l'agente Monitoring

Verifica l'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 dell'account di servizio predefinito, inizia individuando l'account di servizio predefinito:

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

    Apri la pagina Istanze Compute Engine

  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. Ecco un esempio:

    [ID]-compute@developer.gserviceaccount.com
    
  4. Apri la pagina IAM e amministrazione & gt; IAM del tuo progetto. L'intestazione della pagina è Autorizzazioni per il progetto [PROJECT_NAME]:

    Apri la pagina IAM

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

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

    • Se vedi Editor, il 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 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 l'account di servizio predefinito non ha ruoli adeguati, prova a modificare i ruoli per l'account di servizio nella pagina IAM e amministrazione > IAM. Aggiungi i ruoli di logging o monitoraggio corretti 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. Nelle 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 fornire tali credenziali all'agente.

  1. L'agente cerca una variabile di ambiente, GOOGLE_APPLICATION_CREDENTIALS, che contenga 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
  1. Se la località predefinita non contiene le credenziali, l'agente utilizzerà le credenziali predefinite dell'applicazione dal server di metadati.

Le seguenti informazioni consentono di diagnosticare i problemi relativi alle credenziali della chiave privata:

  1. È presente la chiave privata?
  2. La chiave privata è ancora valida per l'account di servizio?
  3. L'account di servizio ha i 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.

Le credenziali sono presenti?

Per verificare se nell'istanza sono presenti credenziali dell'account di servizio con chiave privata, esegui questi comandi Linux sull'istanza:

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

Se uno dei comandi mostra un file come quello riportato di seguito, l'istanza potrebbe avere credenziali valide della chiave privata. 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 possono causare l'utilizzo da parte dell'agente delle credenziali diverse da quelle richieste dal servizio. Ad esempio, se imposti una località delle credenziali personalizzata in GOOGLE_APPLICATION_CREDENTIALS nella shell di accesso, ma non imposti la variabile nella configurazione del servizio dell'agente, il servizio cercherà nella località predefinita anziché nella località 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 Aggiungere 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 ciò che è visualizzato nella sezione IAM e amministrazione & gt; Account di servizio della console Google Cloud.

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

  • Stai controllando un'istanza di Compute Engine, ma il progetto Google Cloud nel file delle credenziali non è quello che contiene la tua istanza.
  • Stai controllando un'istanza di 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 indicato non esiste. Potrebbe essere stata eliminata.
  • L'account di servizio elencato non ha i ruoli corretti attivati: Logs Writer 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 & gt; Account di servizio della console Google Cloud. Se non sono presenti credenziali valide, consulta Aggiungere 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 nell'istanza. Consulta Creazione di chiavi dell'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 cerchi non vengano esclusi accidentalmente.

Verifica firewall

Per verificare se l'istanza ha accesso a logging.googleapis.com, esegui questo 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 di firewall:

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

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

Reinstalla l'agente

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

Altri problemi comuni

Nella tabella seguente sono elencati alcuni problemi comuni che potresti riscontrare con l'agente Cloud Logging e ti spiegano 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 ricevere 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
Impossibile 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 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?)
L'istanza VM non ha le credenziali adatte. Se utilizzi Amazon EC2, devi installare le credenziali nelle istanze delle VM prima di installare l'agente. Per installare le credenziali, consulta Autorizzare l'agente Logging.
Autorizzazione negata Le tue 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 necessaria 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 un account di servizio definito dall'utente utilizzato per l'autorizzazione delle chiavi private. L'account deve avere il ruolo di Editor. Modifica l'autorizzazione dell'account di servizio nella pagina IAM del tuo progetto. Se necessario, puoi modificare l'ambito di accesso di una VM esistente utilizzando la procedura 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 recuperare 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, nella tua istanza VM. Nella sezione <match **>, aggiungi la seguente riga:
project_id [YOUR_PROJECT_ID]
In caso contrario, consulta Autorizza l'agente Logging per correggere o sostituire le credenziali.
L'agente di logging delle finestre interrompe l'importazione dei log eventi da alcuni canali L'agente Logging potrebbe non riuscire ad importare i log eventi da alcuni canali, anche se è ancora in esecuzione e l'importazione dei log agente e dei log eventi da altri canali. Il motivo è che il plug-in windows_eventlog presenta alcuni problemi come menzionato in questa presentazione. Utilizza windows_eventlog2 per risolvere 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 BigQuery o Google Cloud Storage configurate 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 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 di vista la sua posizione nei file di input quando Cloud Logging è configurato con l'impostazione copytruncate. Consigliamo di utilizzare l'impostazione nocopytruncate per assicurarti che la funzione logrotate 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="Indirizzo già in uso - bind(2) per 0.0.0.0:24231" Sulla VM sono in esecuzione più istanze di agente Logging. L'uso 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. Elimina le istanze meno recenti in base alle necessità.
L'avvio del logging dell'agente non riesce 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, generando una chiamata subexp non valida e 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 la regex non corretta nel file di configurazione dell'agente. Suggerimento: cerca regex o parse.

Limitazione della velocità effettiva di log

La velocità effettiva massima del log 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 un solo core CPU. Quindi, quando i picchi di velocità effettiva del log, l'agente potrebbe raggiungere un limite di utilizzo della CPU. Se questi picchi sono solo temporanei, l'agente Logging esegue il buffer dei log e in seguito acquisisce i dati per elaborarli. Se la velocità effettiva del log rimane costantemente alta, i log potrebbero fuoriuscire dal buffer e andare persi.

In genere, quando ogni voce di log è di testo non elaborato da 1000 byte e non contiene un'elaborazione di formato aggiuntiva, l'agente Logging raggiunge il limite massimo di CPU per 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 Ops. Su Linux, per le voci di log costituite da 1000 byte di testo non elaborato e che non richiedono alcuna elaborazione aggiuntiva, l'agente operativo può elaborare circa 160.000 voci di log al secondo.

Dimensione massima del log superata

Se una o più voci del log superano il limite massimo, le voci visualizzate nei log fluentd potrebbero essere 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 massima. Ad esempio, il seguente codice di esempio 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 vengono 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 accodati più volte ai file di log. Questo potrebbe verificarsi in presenza di rotazione dei log o quando il file di posizione manca o è danneggiato. Per ridurre il rischio di questo problema, assicurati che i file di posizione per qualsiasi input in_tail non siano configurati nella cartella /var/log o in qualsiasi altra cartella che potrebbe aver attivato la rotazione dei log.

La pipeline di logging utilizza anche il campo LogEntry.timestamp per la deduplicazione dei 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, utilizza il tempo in cui elabora la voce di log. Pertanto, se l'input viene letto più volte, anche se il timestamp nella riga del log è uguale, Fluentd potrebbe considerarli come voci di log diverse con timestamp diversi.

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

Si è verificato un problema noto che interessa le versioni da 1.8.5 a 1.9.3 (incluse), che causa la visualizzazione ripetuta dei log come quello seguente nei log di controllo 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 successive.

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 ASCII, pertanto sostituisce qualsiasi carattere non ASCII di uno spazio. Per importare 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 installata

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