Questa pagina è stata tradotta dall'API Cloud Translation.

Risolvi i problemi dell'agente Logging

Questa pagina fornisce istruzioni per la risoluzione dei problemi comuni con l'installazione dell'agente Logging 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 restituiscono errori, assicurati di aggiungi sudo come prefisso ai comandi di installazione.
Verifica che il servizio dell'agente sia in esecuzione sulla tua 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 seguente comando:
```
sudo service google-fluentd restart
```
  Se il riavvio non riesce e l'output di log mostra "Disabilitato tramite metadati", probabilmente stai eseguendo un'immagine da Google Cloud Marketplace, in cui l'agente Logging è disabilitato per impostazione predefinita. La La chiave di metadati dell'istanza google-logging-enable controlla l'agente Logging stato di abilitazione, dove un valore di 0 disabilita l'agente. Per riattivarla l'agente, rimuovi la chiave google-logging-enable o imposta su 1. Per ulteriori informazioni, vedi Crea un'istanza con l'agente Logging disabilitato).
  
  Se l'agente non viene disabilitato 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 la propria accede a 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 Quote dell'API Logging. Puoi vedere le quota disponibile selezionando API e servizi > Dashboard in la console Google Cloud. Scegli l'API Logging.
  - Se riscontri problemi di accesso all'API o di autorizzazione, vai alla sezione Verifica le credenziali di Compute Engine.
Se l'agente sembra funzionare normalmente, ma non ricevi dati, devi verificare che l'agente stia inviando i dati al progetto corretto. Consulta la sezione Verificare le credenziali di Compute Engine riportata di seguito.
Se l'agente non riesce a concedere l'autorizzazione, controlla se le credenziali per chiave privata mancante o non valida.

Verifica l'installazione dell'agente

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

Nella console Google Cloud, 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.
Nella parte superiore della pagina, scegli il progetto contenente la tua istanza VM:
- Per le istanze VM Compute Engine, scegli il progetto Google Cloud che contiene l'istanza VM.
- Per Istanze VM Amazon EC2, scegli il progetto Google Cloud a cui invii i log.
Nelle schede Windows, scegli la risorsa per la tua istanza VM:
- Per Compute Engine, scegli Istanza VM GCE.
- Per Amazon EC2, scegli Istanza AWS EC2.
- Seleziona syslog (Linux), fluent.info (Windows) o Tutti i log.

Se vedi una voce di log, "gRPC inviato correttamente all'API Logging", l'installazione dell'agente sarà completata. Questo messaggio è stato generato una volta quando dell'agente e ogni agente viene riavviato.

Per ulteriori informazioni su Esplora log, consulta Utilizzare 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 sia su Compute Engine che sulla VM Amazon EC2 di istanze che eseguono Linux:

Verifica che l'agente Logging sia in esecuzione eseguendo questo comando 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 [...]

Invia un messaggio di log di prova eseguendo questo comando sulla tua VM istanza:
```
logger "Some test message"
```

Istanza Windows

L'agente Logging ha due nomi di servizi Windows:

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

Dovresti eseguire un servizio agente. Esegui i seguenti comandi utilizzando PowerShell:

Chiedi lo stato di entrambi i servizi. Se sai quale deve essere in esecuzione, puoi usare solo il nome del servizio in questione:
```
Get-Service StackdriverLogging,fluentdwinsvc
```
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
```
Se esegui una query su entrambi i servizi, dovresti vedere un solo messaggio di errore e Stato Running:
- Se non vedi nessuno stato Running, l'agente Logging non è in esecuzione.
- Se vedi che StackdriverLogging è in esecuzione, significa che stai che esegue una versione recente dell'agente. Per determinare la versione specifica, consulta la sezione Recupero della versione.
- Se vedi che fluentdwinsvc è in esecuzione, dovresti eseguire l'upgrade dell'agente a all'ultima versione.

Richiede privilegi di amministratore: se una versione dell'agente è in esecuzione, quindi 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."

Trova il tuo messaggio di prova

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

Nella console Google Cloud, 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.
Nella parte superiore della pagina, scegli il progetto contenente la tua istanza VM:
- Per le istanze VM Compute Engine, scegli il progetto Google Cloud che contiene l'istanza VM.
- Per Istanze VM Amazon EC2, scegli il progetto Google Cloud a cui invii i log.
Nelle schede Windows, scegli la risorsa per la tua istanza VM:
- Per Compute Engine, scegli Istanza VM GCE.
- Per Amazon EC2, scegli Istanza AWS EC2.
- Seleziona syslog (Linux), fluent.info (Windows) o Tutti i log.
Dovresti vedere una voce di log con il messaggio di test. Se sì, la classe che l'agente stia funzionando correttamente.

Verifica le credenziali di Compute Engine

Per eseguire l'agente senza una chiave privata su un'istanza VM di Compute Engine le credenziali, l'istanza deve avere accesso adeguato ambiti e identità dell'account di servizio usato dall'istanza deve avere le autorizzazioni IAM appropriate.

Quando crei un'istanza VM, vengono applicate le impostazioni predefinite dell'ambito e dell'account di servizio sono sufficienti per eseguire gli agenti. Istanze molto vecchie per cui hai modificato le impostazioni predefinite, potrebbero non essere e credenziali.

Impossibile caricare le credenziali predefinite

In caso di errori Could not load the default credentials in Logging del file di log, significa che l'agente potrebbe non riuscire a e la connessione al server metadati di 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 potenziale causa è che la VM ha una configurazione proxy personalizzata. Per risolvere il problema, Consulta le Istruzioni per la configurazione del proxy per escludere il server metadati di Compute Engine (metadata.google.internal, oppure 169.254.169.254) di passare attraverso il proxy. Se l'errore persiste, rimuovere l'account di servizio Compute Engine predefinito dalla VM e aggiungerlo di nuovo.

Verifica gli ambiti di accesso

Per verificare gli ambiti di accesso:

Nella console Google Cloud, 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.
Fai clic sul nome dell'istanza VM. La pagina dei dettagli dell'istanza .
Nella sezione Ambiti di accesso API Cloud, fai clic su Dettagli per visualizzare delle API nell'elenco delle API. Cerca le seguenti voci:
1. Se vedi "Questa istanza ha accesso API completo a tutti i servizi Google Cloud", significa che i tuoi ambiti di accesso sono adeguati.
2. Se accanto all'API Stackdriver Logging vedi un nome meno recente per l'API Cloud Logging, L'autorizzazione di sola scrittura o Completa, quindi l'input dell'istanza gli ambiti di accesso sono adeguati per l'agente Cloud Logging.
3. Se accanto all'API Stackdriver Monitoring è presente un nome meno recente per l'API Cloud Monitoring, L'autorizzazione di sola scrittura o Completa, quindi l'input dell'istanza sono appropriati per l'agente Cloud Monitoring.

Risolvere il problema

Se non disponi di ambiti di accesso adeguati nella tua istanza Compute Engine, aggiungi gli ambiti di accesso necessari in esecuzione.

La tabella seguente mostra gli ambiti pertinenti a Logging e Agenti di monitoraggio:

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 predefinita

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

Per verificare l'autorizzazione dell'account di servizio predefinito, individua innanzitutto account di servizio predefinito:

Nella console Google Cloud, 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.
Fai clic sul nome dell'istanza VM. Viene visualizzata la pagina dei dettagli dell'istanza.
Cerca l'intestazione Account di servizio nella pagina. La con l'account di servizio predefinito per l'istanza. Potrebbe avrà il seguente aspetto:
```
[ID]-compute@developer.gserviceaccount.com
```
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 Console di amministrazione.
Seleziona Visualizza per: Entità. Dovresti vedere un elenco di persone, gruppi e account di servizio. Nella colonna Ruolo sono visualizzati i ruoli di ciascuna entità. ha nel tuo progetto.
Nella riga dell'account di servizio predefinito dell'istanza, dovresti vedere uno o più ruoli:
- Se vedi Editor, quel ruolo è appropriato per tutti gli agenti. Il ruolo Editor potrebbe essere concesso automaticamente all'amministratore predefinito a seconda della configurazione dei criteri dell'organizzazione.
- Se vedi Writer log, quel ruolo è sufficiente per il ruolo un agente. 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 Agente Monitoring. Per gli altri ruoli di Monitoring che includono il ruolo vedi Controllo dell'accesso per Cloud Monitoring.

Correggere il problema

Se il tuo account di servizio predefinito non dispone di ruoli adeguati, prova a modificare il i ruoli per il tuo account di servizio nella piattaforma IAM e amministratore > IAM. Aggiungi il token Logging o Monitoring ruoli 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'istanza non predefinita che disponga dell'autorizzazione appropriata. Nelle istanze VM AWS EC2, devi configurare l'agente in modo che utilizzi un account di servizio di questo tipo.

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

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

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

Linux

/etc/google/auth/application_default_credentials.json

Windows

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

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

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

La chiave privata è presente?
La chiave privata è ancora valida per l'account di servizio?
L'account di servizio dispone dei ruoli necessari per l'agente?

Per verificare che sulla tua istanza VM siano installate credenziali per chiave privata valide, verifica innanzitutto che il file delle credenziali esista nella posizione prevista e quindi verifica che le informazioni nel file delle credenziali siano valide.

Le credenziali sono presenti?

Per vedere se nell'istanza sono presenti credenziali dell'account di servizio chiavi privata, esegui il comando i seguenti comandi Linux sulla tua istanza:

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

Se uno dei comandi mostra un file come quello mostrato di seguito, la tua istanza potrebbe avere credenziali della chiave privata valide. Se entrambi i comandi mostrano un file, viene utilizzato il file indicato con 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 e credenziali diverse da quelle richieste dal tuo servizio. Ad esempio, se imposti una posizione delle credenziali personalizzate in GOOGLE_APPLICATION_CREDENTIALS all'accesso ma non impostare quella variabile nella configurazione del servizio dell'agente, verrà visualizzato nella località predefinita anziché nella località personalizzata.

Per esaminare 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, vedi 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, mentre private_key_id identifica la chiave privata nell'account di servizio. Associa queste informazioni ai mostrato in IAM e Amministratore > nella sezione Account di servizio nella console Google Cloud.

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

Stai controllando un'istanza Compute Engine, ma il progetto Google Cloud nel file delle credenziali non è il progetto che contiene la tua istanza.
Stai controllando un'istanza Amazon EC2, ma il progetto Google Cloud nel file delle credenziali non è il progetto Google Cloud in cui inviano i log.
L'account di servizio elencato non esiste. Potrebbe essere stato eliminato.
Nell'account di servizio elencato non sono abilitati i ruoli corretti: Scrittore di log per l'agente Cloud Logging e Scrittore di metriche di monitoraggio per l'agente Cloud Monitoring.
La chiave privata non esiste. Potrebbe essere stato revocato.

Puoi revocare le credenziali utilizzando la funzionalità IAM e Amministratore > Sezione Account di servizio della console Google Cloud. Se non sono presenti credenziali valide, consulta Aggiunta delle credenziali per sostituire quello esistente credenziali o aggiungerne di nuove.

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

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

Verificare le query di esclusione dei log

Visualizza query di esclusione correnti per assicurarti che i log che stai cercando non vengano 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 può richiedere del tempo quando il firewall blocca l'uscita in uscita per via del traffico. Esempio di output che indica un problema del firewall:

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

Visita la pagina relativa alle regole firewall per informazioni su come impostare le regole per il traffico in uscita.

Reinstalla l'agente

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

Se hai la certezza che il problema non sia correlato alle credenziali, puoi saltare avanti consulta l'articolo Installazione su Linux e Windows.
Per un'installazione completa dell'agente e delle eventuali credenziali necessarie, consulta Installare l'agente Logging.

Altri problemi comuni

Nella tabella seguente sono elencati alcuni problemi comuni che potresti riscontrare con l'app dell'agente Cloud Logging e ti spiega come correggerli.

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 c'è un problema con autorizzazioni o 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 un'istanza VM.

Errore	Causa	Soluzione
Impossibile eseguire il programma di installazione dell'agente su Windows	Forse hai scaricato il programma di installazione nella 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?)	La tua istanza VM non dispone di credenziali adatte. Se usi Amazon EC2, devi installare le credenziali sulle istanze VM un agente.	Per installare le credenziali, consulta Autorizzazione dell'agente Logging.
Autorizzazione negata	Le credenziali di autorizzazione con chiave privata per l'agente di logging non sono configurate correttamente.	Vedi Verifica delle credenziali della chiave privata.
Il chiamante non dispone dell'autorizzazione	L'account di servizio utilizzato per l'autorizzazione nel progetto è autorizzazioni insufficienti. Potrebbe essere l'account di servizio predefinito utilizzato in Compute Engine o App Engine oppure potrebbe essere un ambiente account di servizio utilizzato per l'autorizzazione della chiave privata. Account Deve avere il ruolo 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 Modifica dell'account di servizio e degli ambiti di accesso per un'istanza le procedure del caso.
Impossibile ottenere l'ID progetto	L'agente Cloud Logging non è riuscito a ottenere l'ID progetto da un il file delle credenziali della chiave privata dell'account di servizio.	Per aggiungere o eseguire l'override di un ID progetto per l'agente, modificare il file di configurazione dell'agente /etc/google-fluentd/google-fluentd.conf, sulla tua VM in esecuzione in un'istanza Compute Engine. Nella sezione <match >, aggiungi la seguente riga: `project_id [YOUR_PROJECT_ID]`** Altrimenti, consulta Autorizza l'agente Logging a correggere o sostituire le credenziali.
L'agente Windows Logging smette di importare i log eventi da alcuni canali	L'agente di logging potrebbe non riuscire in silenzio 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, menzionate in questa presentazione. Stai usando `windows_eventlog2` risolve il problema.	Nota: il formato dei dati del plug-in `windows_eventlog2` non è compatibile con le versioni precedenti con il plug-in `windows_eventlog`. Se ci sono tutte le pipeline di esportazione di BigQuery o Google Cloud Storage configurate per questi log, devono essere regolati di conseguenza. Consulta confronto tra le voci di log fornita da `windows_eventlog` e `windows_eventlog2`. Per utilizzare `windows_eventlog2`, devi prima interrompere la dell'agente Logging, quindi sostituisci il file di configurazione con uno simile a questo file di configurazione di esempio. Infine, avvia l'agente Logging.
L'agente Logging smette di importare i log in presenza di logrotate	L'agente Logging potrebbe perdere di vista la sua posizione all'interno file di input quando logrotate è configurato con `copytruncate` dell'ambientazione.	È meglio utilizzare l'impostazione `nocopytruncate` per assicurarti che, mediante logrotazione, sposta i file invece di troncarli. Se vuoi mantenere l'impostazione `copytruncate`, la soluzione è riavvia l'agente periodicamente. In alternativa, puoi utilizzare l'impostazione `postrotate` per e riavviare l'agente.
error_class=Errno::EADDRINUSE error="Address already in use - bind(2) for 0.0.0.0:24231"	Sono in esecuzione più istanze dell'agente Logging la VM.	Utilizzo di `ps -aux \| grep "/usr/sbin/google-fluentd"` per la visualizzazione di un agente in esecuzione (deve ve ne siano solo due: un supervisore e worker) e `sudo netstat -nltp \| grep :24231` per mostrare in esecuzione che occupa la porta. Termina le istanze meno recenti adatta.
L'agente Logging non si avvia a causa di errori da `lib/fluent/config/types.rb`	La configurazione dell'agente Logging utilizza un sezione parser regex con un'espressione regolare non corretta, che genera 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 corretta nell'agente di configurazione . Suggerimento: cerca `regex` o `parse`.

Limitazione della velocità effettiva di log

La velocità effettiva massima di log che l'agente Logging può elaborare è CPU limitata. L'utilizzo della CPU tende ad aumentare quando aumenta la velocità effettiva del log. Ma con la configurazione predefinita, può utilizzare fino a un solo core CPU. Quindi, quando ai picchi di velocità effettiva dei log, l'agente potrebbe raggiungere il limite di utilizzo della CPU. Se questi picchi sono solo temporanei, l'agente Logging esegue il buffer dei log in seguito la recupera per elaborarle. Se la velocità effettiva del log è coerente rimane alto, i log potrebbero sovraccaricare il buffer e alla fine vengono persi.

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

Se hai bisogno di una velocità effettiva di log più elevata, puoi prendere in considerazione l'utilizzo del modulo Ops Agente. Su Linux, per le voci di log che sono costituite da testo non elaborato di 1000 byte e non richiedono ulteriore elaborazione, Ops Agent può elaborare circa 160.000 voci di log al secondo.

Dimensione massima dei log superata

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

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

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 dimensioni massime consentite. Ad esempio, il seguente codice campione taglia i log con 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>

Log duplicati

LogEntry.insertID vengono aggiunti alla pipeline di elaborazione all'interno dell'agente. Se insertID è diverso tra i log duplicati, questo indica che i log vengono inseriti nella coda dai file di log. più volte. Questo può accadere in presenza di rotazione dei log o quando pos mancante o danneggiato. Per ridurre le probabilità che questo problema si verifichi, assicurati che i file di posizione per qualsiasi input in_tail non sono configurati per essere nel /var/log cartella o qualsiasi altra cartella per la quale la rotazione dei log potrebbe essere abilitata.

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 il timestamp originale della voce di log, quindi Fluentd usa l'ora durante l'elaborazione della voce di log. Quindi se l'input viene letto più volte, il timestamp nella riga del log è lo stesso, Fluentd può considerarli diversi voci di log con timestamp diversi.

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

Esiste un problema noto che interessa le versioni dalla 1.8.5 alla 1.9.3 (incluse) che fa sì che log simili ai seguenti vengano visualizzati ripetutamente Audit log degli accessi ai dati, quando l'agente ha sono in esecuzione da oltre 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 successive.

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

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 la codifica 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, il formato 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 richiedere fino a ora per segnalare la modifica.

L'agente Logging non viene visualizzato in Disinstalla un elenco dei programmi di Windows

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