Risolvere i problemi di importazione dati di Ops Agent

Questo documento fornisce informazioni utili per diagnosticare e risolvere i problemi di importazione dei dati, per log e metriche, in Ops Agent in esecuzione. Se Ops Agent non è in esecuzione, consulta Risolvere i problemi di installazione e avvio.

Prima di iniziare

Prima di provare a risolvere un problema, controlla lo stato dei controlli di integrità dell'agente.

L'agente è in esecuzione, ma i dati non sono stati importati

Utilizza Metrics Explorer per eseguire una query sulla metrica dell'agente uptime e verificare che il componente dell'agente, google-cloud-ops-agent-metrics o google-cloud-ops-agent-logging, stia scrivendo nella metrica.

1. Nel pannello di navigazione della console Google Cloud, seleziona Monitoring e poi  Metrics Explorer:

   Vai a Metrics Explorer

2. Nel pulsante di attivazione/disattivazione con etichetta Builder Code, seleziona Code (Codice), quindi imposta la lingua su MQL.

3. Inserisci la seguente query e fai clic su Esegui:

   fetch gce_instance
   | metric 'agent.googleapis.com/agent/uptime'
   | align rate(1m)
   | every 1m
   

L'agente invia i log a Cloud Logging?

Se l'agente è in esecuzione, ma non invia log, controlla lo stato dei controlli di integrità di runtime dell'agente.

Errori di pipeline

Se viene visualizzato l'errore di runtime LogPipelineErr ("pipeline di logging di Ops Agent non riuscita"), significa che il subagente Logging ha riscontrato un problema durante la scrittura dei log. Verifica le seguenti condizioni:

• Verifica che i file di archiviazione del subagente Logging siano accessibili. Questi file si trovano nelle seguenti posizioni:
  • Linux: /var/lib/google-cloud-ops-agent/fluent-bit/buffers/
  • Windows: C:\Program Files\Google\Cloud Operations\Ops Agent\run\buffers\
• Verifica che il disco della VM non sia pieno.
• Verifica che la configurazione di logging sia corretta.

Questi passaggi richiedono la connessione SSH alla VM.

Se modifichi la configurazione del logging o se i file del buffer sono accessibili e il disco della VM non è pieno, riavvia Ops Agent:

Linux

1. Per riavviare l'agente, esegui questo comando sull'istanza:

   sudo systemctl restart google-cloud-ops-agent
   

2. Per confermare che l'agente è stato riavviato, esegui il comando seguente e verifica che i componenti "Metrics Agent" e "Logging Agent" siano stati avviati:

   sudo systemctl status "google-cloud-ops-agent*"
   

Windows

1. Connettiti all'istanza utilizzando RDP o uno strumento simile e accedi a Windows.
2. Apri un terminale PowerShell con privilegi di amministratore facendo clic con il tasto destro del mouse sull'icona di PowerShell e selezionando Esegui come amministratore
3. Per riavviare l'agente, esegui il comando PowerShell seguente:

   Restart-Service google-cloud-ops-agent -Force
   

4. Per confermare che l'agente è stato riavviato, esegui il comando seguente e verifica che i componenti "Metrics Agent" e "Logging Agent" siano stati avviati:

   Get-Service google-cloud-ops-agent*
   

Errori di analisi dei log

Se viene visualizzato l'errore di runtime LogParseErr ("Ops Agent non è riuscito ad analizzare i log"), il problema più probabile è legato alla configurazione di un processore di logging. Per risolvere il problema:

• Verifica che la configurazione di tutti i processori parse_json sia corretta.
• Verifica che la configurazione di tutti i processori parse_regex sia corretta.
• Se non hai processori parse_json o parse_regex, controlla la configurazione di altri processori di logging.

Questi passaggi richiedono la connessione SSH alla VM.

Se modifichi la configurazione del logging, riavvia Ops Agent:

Linux

1. Per riavviare l'agente, esegui questo comando sull'istanza:

   sudo systemctl restart google-cloud-ops-agent
   

2. Per confermare che l'agente è stato riavviato, esegui il comando seguente e verifica che i componenti "Metrics Agent" e "Logging Agent" siano stati avviati:

   sudo systemctl status "google-cloud-ops-agent*"
   

Windows

1. Connettiti all'istanza utilizzando RDP o uno strumento simile e accedi a Windows.
2. Apri un terminale PowerShell con privilegi di amministratore facendo clic con il tasto destro del mouse sull'icona di PowerShell e selezionando Esegui come amministratore
3. Per riavviare l'agente, esegui il comando PowerShell seguente:

   Restart-Service google-cloud-ops-agent -Force
   

4. Per confermare che l'agente è stato riavviato, esegui il comando seguente e verifica che i componenti "Metrics Agent" e "Logging Agent" siano stati avviati:

   Get-Service google-cloud-ops-agent*
   

Controllare le metriche locali

Nota: il servizio di metriche locali non è disponibile su Windows.

Questi passaggi richiedono la connessione SSH alla VM.

• Il modulo di logging è in esecuzione? Utilizza i seguenti comandi per controllare:

Linux

sudo systemctl status google-cloud-ops-agent"*"

Windows

Apri Windows PowerShell come amministratore ed esegui:

Get-Service google-cloud-ops-agent

Puoi anche controllare lo stato del servizio nell'app Servizi e ispezionare i processi in esecuzione nell'app Task Manager.

Controlla il log del modulo di logging

Questo passaggio richiede la connessione SSH alla VM.

I log del modulo di logging sono disponibili in /var/log/google-cloud-ops-agent/subagents/*.log per Linux e C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log per Windows. Se non esistono log, significa che il servizio agente non viene eseguito correttamente. Prima di tutto, vai alla sezione L'agente è installato ma non in esecuzione per correggere questa condizione.

• Potresti visualizzare errori di autorizzazione 403 quando scrivi nell'API Logging. Ad esempio:

  [2020/10/13 18:55:09] [ warn] [output:stackdriver:stackdriver.0] error
  {
  "error": {
    "code": 403,
    "message": "Cloud Logging API has not been used in project 147627806769 before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/logging.googleapis.com/overview?project=147627806769 then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry.",
    "status": "PERMISSION_DENIED",
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.Help",
        "links": [
          {
            "description": "Google developers console API activation",
            "url": "https://console.developers.google.com/apis/api/logging.googleapis.com/overview?project=147627806769"
          }
        ]
      }
    ]
  }
  }
  

  Per correggere questo errore, abilita l'API Logging e imposta il ruolo Writer log.

• Potresti notare un problema di quota per l'API Logging. Ad esempio:

  error="8:Insufficient tokens for quota 'logging.googleapis.com/write_requests' and limit 'WriteRequestsPerMinutePerProject' of service 'logging.googleapis.com' for consumer 'project_number:648320274015'." error_code="8"
  

  Per correggere questo errore, aumenta la quota o riduci la velocità effettiva dei log.

• Nel log del modulo potrebbero essere visualizzati i seguenti errori:

  {"error":"invalid_request","error_description":"Service account not enabled on this instance"}
  

  o

  can't fetch token from the metadata server
  

  Questi errori potrebbero indicare che hai eseguito il deployment dell'agente senza un account di servizio o credenziali specificate. Per informazioni sulla risoluzione del problema, consulta Autorizzare Ops Agent.

L'agente invia le metriche a Cloud Monitoring?

Controlla il log del modulo delle metriche

Questo passaggio richiede la connessione SSH alla VM.

Puoi trovare i log del modulo delle metriche in syslog. Se non esistono log, questo indica che il servizio agente non è in esecuzione correttamente. Prima di tutto, vai alla sezione L'agente è installato ma non in esecuzione per correggere questa condizione.

• Potresti visualizzare PermissionDenied errori durante la scrittura nell'API Monitoring. Questo errore si verifica se l'autorizzazione per Ops Agent non è configurata correttamente. Ad esempio:

  Nov  2 14:51:27 test-ops-agent-error otelopscol[412]: 2021-11-02T14:51:27.343Z#011info#011exporterhelper/queued_retry.go:231#011Exporting failed. Will retry the request after interval.#011{"kind": "exporter", "name": "googlecloud", "error": "[rpc error: code = PermissionDenied desc = Permission monitoring.timeSeries.create denied (or the resource may not exist).; rpc error: code = PermissionDenied desc = Permission monitoring.timeSeries.create denied (or the resource may not exist).]", "interval": "6.934781228s"}
  

  Per correggere questo errore, abilita l'API Monitoring e imposta il ruolo Writer metriche di Monitoring.

• Potresti visualizzare ResourceExhausted errori durante la scrittura nell'API Monitoring. Questo errore si verifica se il progetto sta raggiungendo il limite per le quote dell'API Monitoring. Ad esempio:

  Nov  2 18:48:32 test-ops-agent-error otelopscol[441]: 2021-11-02T18:48:32.175Z#011info#011exporterhelper/queued_retry.go:231#011Exporting failed. Will retry the request after interval.#011{"kind": "exporter", "name": "googlecloud", "error": "rpc error: code = ResourceExhausted desc = Quota exceeded for quota metric 'Total requests' and limit 'Total requests per minute per user' of service 'monitoring.googleapis.com' for consumer 'project_number:8563942476'.\nerror details: name = ErrorInfo reason = RATE_LIMIT_EXCEEDED domain = googleapis.com metadata = map[consumer:projects/8563942476 quota_limit:DefaultRequestsPerMinutePerUser quota_metric:monitoring.googleapis.com/default_requests service:monitoring.googleapis.com]", "interval": "2.641515416s"}
  

  Per correggere questo errore, aumenta la quota o riduci la velocità effettiva delle metriche.

• Nel log del modulo potrebbero essere visualizzati i seguenti errori:

  {"error":"invalid_request","error_description":"Service account not enabled on this instance"}
  

  o

  can't fetch token from the metadata server
  

  Questi errori potrebbero indicare che hai eseguito il deployment dell'agente senza un account di servizio o credenziali specificate. Per informazioni sulla risoluzione del problema, consulta Autorizzare Ops Agent.

Problemi di connettività di rete

Se l'agente è in esecuzione, ma non invia né log né metriche, potrebbe essersi verificato un problema di rete. I tipi di problemi di connettività di rete che potresti riscontrare variano a seconda della topologia dell'applicazione. Per una panoramica del networking di Compute Engine, consulta Panoramica del networking per le VM.

Le cause comuni dei problemi di connettività includono:

• Regole firewall che interferiscono con il traffico in entrata. Per informazioni sulle regole firewall, consulta Utilizzare le regole firewall VPC.
• Problemi nella configurazione di un proxy HTTP.
• Configurazione DNS.

Ops Agent esegue controlli di integrità che rilevano errori di connettività di rete. Consulta la documentazione sui controlli di integrità per scoprire le azioni suggerite da intraprendere in caso di errori di connettività.

A partire dalla versione 2.28.0 di Ops Agent, Ops Agent limita la quantità di spazio su disco che può utilizzare per archiviare blocchi di buffer. Ops Agent crea blocchi di buffer quando i dati di logging non possono essere inviati all'API Cloud Logging. Senza un limite, questi blocchi potrebbero consumare tutto lo spazio disponibile, interrompendo altri servizi sulla VM. Quando un'interruzione di rete causa la scrittura di blocchi di buffer su disco, Ops Agent utilizza una quantità di spazio su disco specifica per la piattaforma per archiviare i blocchi. Un messaggio come quello nell'esempio seguente viene visualizzato anche in /var/log/google-cloud-ops-agent/subagents/logging-module.log sulle VM Linux o in C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log sulle VM Windows quando la VM non può inviare i blocchi di buffer all'API Cloud Logging:

[2023/04/15 08:21:17] [warn] [engine] failed to flush chunk

Voglio raccogliere solo metriche o log, non entrambi

Per impostazione predefinita, Ops Agent raccoglie sia metriche che log. Per disabilitare la raccolta di metriche o log, utilizza il file Ops Agent config.yaml per eseguire l'override del servizio logging o metrics predefinito in modo che la pipeline predefinita non abbia ricevitori. Per ulteriori informazioni, consulta quanto segue:

• Esempi di configurazioni di service di logging.
• Esempi di configurazioni di metriche service.

Se interrompi l'importazione dati mediante la disattivazione dei servizi del sub-agente di Ops Agent, "Logging Agent " o"Monitoring Agent" genera una configurazione non valida e non è supportata.

È in corso la raccolta delle metriche, ma si è verificato un problema

L'agente sta registrando il messaggio "Esportazione non riuscita. Riprova"

Visualizzerai le voci di log "Esportazione non riuscita" quando il primo punto dati di una metrica cumulativa viene diminuito. I seguenti log non sono dannosi e possono essere ignorati in sicurezza:

  Jul 13 17:28:03 debian9-trouble otelopscol[2134]: 2021-07-13T17:28:03.092Z        info        exporterhelper/queued_retry.go:316        Exporting failed. Will retry the request a
  fter interval.        {"kind": "exporter", "name": "googlecloud/agent", "error": "rpc error: code = InvalidArgument desc = Field timeSeries[1].points[0].interval.start_time had a
  n invalid value of "2021-07-13T10:25:18.061-07:00": The start time must be before the end time (2021-07-13T10:25:18.061-07:00) for the non-gauge metric 'agent.googleapis.com/ag
  ent/uptime'.", "interval": "23.491024535s"}
  Jul 13 17:28:41 debian9-trouble otelopscol[2134]: 2021-07-13T17:28:41.269Z        info        exporterhelper/queued_retry.go:316        Exporting failed. Will retry the request a
  fter interval.        {"kind": "exporter", "name": "googlecloud/agent", "error": "rpc error: code = InvalidArgument desc = Field timeSeries[0].points[0].interval.start_time had a
  n invalid value of "2021-07-13T10:26:18.061-07:00": The start time must be before the end time (2021-07-13T10:26:18.061-07:00) for the non-gauge metric 'agent.googleapis.com/ag
  ent/monitoring/point_count'.", "interval": "21.556591578s"}
  

L'agente sta registrando i messaggi "Impossibile scrivere TimeSeries: i punti devono essere scritti in ordine".

Se hai eseguito l'upgrade all'Ops Agent dall'agente Monitoring legacy e visualizzi il seguente messaggio di errore durante la scrittura di metriche cumulative, la soluzione consiste nel riavviare la VM. Ops Agent e l'agente Monitoring calcolano l'ora di inizio per le metriche cumulative in modo diverso, il che può comportare la visualizzazione dei punti nell'ordine sbagliato. Il riavvio della VM reimposta l'ora di inizio e risolve il problema.

  Jun 2 14:00:06 * otelopscol[4035]: 2023-06-02T14:00:06.304Z#011error#011exporterhelper/queued_retry.go:367#011Exporting failed.
  Try enabling retry_on_failure config option to retry on retryable errors#011{"error": "failed to export time series to GCM: rpc error: code = InvalidArgument desc =
  One or more TimeSeries could not be written: Points must be written in order. One or more of the points specified had an older start time than the most recent point.:
  gce_instance{instance_id:,zone:} timeSeries[0-199]: agent.googleapis.com/memory/bytes_used{state:slab}
  

L'agente sta registrando i messaggi "Il token deve essere un token di breve durata (60 minuti) e in un periodo di tempo ragionevole"

Se viene visualizzato il seguente messaggio di errore quando l'agente scrive le metriche, significa che l'orologio di sistema non è sincronizzato correttamente:

  Invalid JWT: Token must be a short-lived token (60 minutes) and in a
  reasonable timeframe. Check your iat and exp values in the JWT claim.
  

Per informazioni sulla sincronizzazione degli orologi di sistema, consulta Configurare NTP su una VM.

L 'agente sta registrando "Il ricevitore delle metriche di tipo"nvml" non è supportato

Se raccogli metriche GPU NVIDIA Management Library (NVML) (agent.googleapis.com/gpu) utilizzando il ricevitore nvml, utilizzi una versione di Ops Agent con supporto in anteprima per le metriche NVML. Il supporto per queste metriche è diventato generalmente disponibile in Ops Agent versione 2.38.0. Nella versione GA, la raccolta delle metriche effettuata dal ricevitore nvml è stata unita nel ricevitore hostmetrics e il ricevitore nvml è stato rimosso.

Viene visualizzato il messaggio di errore "Il ricevitore delle metriche di tipo "nvml non è supportato" dopo l'installazione di Ops Agent versione 2.38.0 o successive quando hai utilizzato il ricevitore nvml di anteprima e hai eseguito l'override dell'intervallo di raccolta predefinito nel file di configurazione specificato dall'utente. L'errore si verifica perché il ricevitore nvml non esiste più, ma il file di configurazione specificato dall'utente vi fa ancora riferimento.

Per risolvere il problema, aggiorna il file di configurazione specificato dall'utente per eseguire l'override dell'intervallo di raccolta sul ricevitore hostmetrics.

Alcune metriche mancano o sono incoerenti

È presente un numero ridotto di metriche che Ops Agent versione 2.0.0 e successive gestisce in modo diverso rispetto alle versioni "di anteprima" di Ops Agent (versioni precedenti alla 2.0.0) o all'agente Monitoring.

La tabella seguente descrive le differenze nei dati importati da Ops Agent e dall'agente Monitoring.

Tipo di metrica, omesso agent.googleapis.com	Ops Agent (GA)^†	Ops Agent (anteprima)^†	Agente Monitoring
cpu_state	I valori possibili per Windows sono idle, interrupt, system e user.	I valori possibili per Windows sono idle, interrupt, system e user.	I valori possibili per Windows sono idle e used.
disk/bytes_used e disk/percent_used	Importato con il percorso completo nell'etichetta device; ad esempio, /dev/sda15. Non importata per dispositivi virtuali come tmpfs e udev.	Importazione senza /dev nel percorso nell'etichetta device; ad esempio, sda15. Importato per dispositivi virtuali come tmpfs e udev.	Importazione senza /dev nel percorso nell'etichetta device; ad esempio, sda15. Importato per dispositivi virtuali come tmpfs e udev.

^† La colonna GA fa riferimento alle versioni 2.0.0 e successive di Ops Agent. La colonna Anteprima si riferisce alle versioni di Ops Agent precedenti alla 2.0.0.

Problemi specifici di Windows

Le sezioni seguenti si applicano solo all'Ops Agent in esecuzione su Windows.

Contatori di prestazioni danneggiati su Windows

Se l'agente secondario delle metriche non riesce ad avviarsi, potrebbe essere visualizzato uno dei seguenti errori in Cloud Logging:

Failed to retrieve perf counter object "LogicalDisk"
Failed to retrieve perf counter object "Memory"
Failed to retrieve perf counter object "System"

Questi errori possono verificarsi se i contatori delle prestazioni del sistema sono danneggiati. Puoi risolvere gli errori ricreando i contatori del rendimento. In PowerShell come amministratore, esegui:

cd C:\Windows\system32
lodctr /R

Il comando precedente a volte può non riuscire; in questo caso, ricarica PowerShell e riprova finché l'operazione non va a buon fine.

Se il comando ha esito positivo, riavvia Ops Agent:

Restart-Service -Name google-cloud-ops-agent -Force

Reimposta completamente lo stato dell'agente

Se l'agente entra in uno stato non recuperabile, segui questi passaggi per ripristinare lo stato dell'agente nuovo.

Nota: questo processo rimuove tutti gli stati del buffer, il che può comportare la perdita dei log. Per un processo che non reimposta lo stato del buffer, consulta Reimpostare e salvare i file del buffer.

Linux

Interrompi il servizio dell'agente:

sudo service google-cloud-ops-agent stop

Rimuovi il pacchetto dell'agente:

curl -sSO https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.sh
sudo bash add-google-cloud-ops-agent-repo.sh --uninstall --remove-repo

Rimuovi i log automatici dell'agente su disco:

sudo rm -rf /var/log/google-cloud-ops-agent

Rimuovi i buffer locali dell'agente sul disco:

sudo rm -rf /var/lib/google-cloud-ops-agent/fluent-bit/buffers/*/

Nota: la directory /var/lib/google-cloud-ops-agent/fluent-bit/buffers/ contiene i seguenti tipi di file:

• File di buffer: questi file sono voci di log nel buffer che sono state in coda ed elaborate da Ops Agent, ma non ancora importati in Cloud Logging. Quando sono presenti blocchi danneggiati, Ops Agent dovrebbe ignorarli nelle versioni successive alla 2.15.0. In alcuni casi, però, devono essere puliti manualmente. Questi file sono archiviati nelle cartelle nidificate come: /var/lib/google-cloud-ops-agent/fluent-bit/buffers/tail.1/*
• File di posizione di tailing del file di log: questi file registrano la posizione nei file di log che Ops Agent ha già eseguito. Se questi file vengono rimossi, Ops Agent inizierà dall'alto dei file configurati come tail. L'eliminazione di questi file può causare la duplicazione dei log se questi sono stati importati in precedenza correttamente. Questi file vengono archiviati direttamente nella directory come file come: /var/lib/google-cloud-ops-agent/fluent-bit/buffers/default_pipeline_syslog*.

La sintassi .../buffers/*/ nel comando precedente garantisce che vengano eliminati solo i file del buffer. I file di posizione non vengono eliminati.

Reinstalla e riavvia l'agente:

curl -sSO https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.sh
sudo bash add-google-cloud-ops-agent-repo.sh --also-install
sudo service google-cloud-ops-agent restart

Windows

Nota: i comandi per Windows devono essere eseguiti in PowerShell come Amministratore.

Interrompi il servizio dell'agente:

Stop-Service google-cloud-ops-agent -Force;
Get-Service google-cloud-ops-agent* | %{sc.exe delete $_};
taskkill /f /fi "SERVICES eq google-cloud-ops-agent*";

Rimuovi il pacchetto dell'agente:

(New-Object Net.WebClient).DownloadFile("https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.ps1", "${env:UserProfile}\add-google-cloud-ops-agent-repo.ps1");
$env:REPO_SUFFIX="";
Invoke-Expression "${env:UserProfile}\add-google-cloud-ops-agent-repo.ps1 -Uninstall -RemoveRepo"

Rimuovi i log automatici dell'agente su disco:

rmdir -R -ErrorAction SilentlyContinue "C:\ProgramData\Google\Cloud Operations\Ops Agent\log";

Rimuovi i buffer locali dell'agente sul disco:

Get-ChildItem -Path "C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers\" -Directory -ErrorAction SilentlyContinue | %{rm -r -Path $_.FullName}

Nota: come per Linux, questo comando elimina solo le sottodirectory nella directory C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers, in modo che i file del buffer vengano rimossi, ma i file della posizione non vengano toccati.

Reinstalla e riavvia l'agente:

(New-Object Net.WebClient).DownloadFile("https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.ps1", "${env:UserProfile}\add-google-cloud-ops-agent-repo.ps1");
$env:REPO_SUFFIX="";
Invoke-Expression "${env:UserProfile}\add-google-cloud-ops-agent-repo.ps1 -AlsoInstall"

Reimposta ma salva i file buffer

Se la VM non ha blocchi di buffer danneggiati (ovvero, non ci sono messaggi format check failed nel file di log autonomo di Ops Agent), puoi saltare i comandi precedenti che rimuovono i buffer locali durante la reimpostazione dello stato dell'agente.

Se la VM contiene blocchi di buffer danneggiati, devi rimuoverli. Le seguenti opzioni descrivono diversi modi per gestire i buffer. Gli altri passaggi descritti in Reimpostare completamente lo stato dell'agente sono ancora applicabili.

• Opzione 1: elimina l'intera directory buffers. Questa è l'opzione più semplice, ma può comportare la perdita dei log non danneggiati nel buffer o la duplicazione dei log a causa della perdita dei file di posizione.

  Linux

  sudo rm -rf /var/lib/google-cloud-ops-agent/fluent-bit/buffers
  

  Windows

  rmdir -R -ErrorAction SilentlyContinue "C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers";
  

• Opzione 2: elimina le sottodirectory del buffer dalla directory buffers, ma lascia i file di posizione. Questo approccio è descritto in Reimpostare completamente lo stato dell'agente.

• Opzione 3: se non vuoi eliminare tutti i file di buffer, puoi estrarre i nomi di questi file dai log interni dell'agente ed eliminare solo quelli danneggiati.

  Linux

  grep "format check failed" /var/log/google-cloud-ops-agent/subagents/logging-module.log | sed 's|.*format check failed: |/var/lib/google-cloud-ops-agent/fluent-bit/buffers/|' | xargs sudo rm -f
  

  Windows

  $oalogspath="C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log";
  if (Test-Path $oalogspath) {
    Select-String "format check failed" $oalogspath |
    %{$_ -replace '.*format check failed: (.*)/(.*)', '$1\$2'} |
    %{rm -ErrorAction SilentlyContinue -Path ('C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers\' + $_)}
  };
  

• Opzione 4: se sono presenti molti buffer danneggiati e vuoi rielaborare tutti i file di log, puoi utilizzare i comandi dell'opzione 3 ed eliminare anche i file di posizione (in cui vengono archiviati l'avanzamento di Ops Agent per ogni file di log). L'eliminazione dei file di posizione può comportare la duplicazione dei log già importati. Questa opzione rielabora solo i file di log correnti; non rielabora i file che erano già stati ruotati o i log di altre origini, come una porta TCP. I file di posizione sono archiviati nella directory buffers, ma come file. I buffer locali vengono memorizzati come sottodirectory nella directory buffers,

  Linux

  grep "format check failed" /var/log/google-cloud-ops-agent/subagents/logging-module.log | sed 's|.*format check failed: |/var/lib/google-cloud-ops-agent/fluent-bit/buffers/|' | xargs sudo rm -f
  sudo find /var/lib/google-cloud-ops-agent/fluent-bit/buffers -maxdepth 1 -type f -delete
  

  Windows

  $oalogspath="C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log";
  if (Test-Path $oalogspath) {
    Select-String "format check failed" $oalogspath |
    %{$_ -replace '.*format check failed: (.*)/(.*)', '$1\$2'} |
    %{rm -ErrorAction SilentlyContinue -Path ('C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers\' + $_)}
  };
  Get-ChildItem -Path "C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers\" -File -ErrorAction SilentlyContinue | %{$_.Delete()}
  

Problemi noti nelle recenti release di Ops Agent

Le seguenti sezioni descrivono i problemi noti delle recenti release di Ops Agent.

Lo spazio dei nomi delle metriche Prometheus include il nome dell'istanza oltre all'ID istanza a partire dalla versione 2.46.0 di Ops Agent

A partire dalla versione 2.46.0, Ops Agent include il nome della VM nell'etichetta namespace quando importa le metriche nel formato di importazione di Prometheus. Nelle versioni precedenti, le metriche di Prometheus utilizzavano solo l'ID istanza della VM nell'ambito dell'etichetta namespace, ma a partire dalla versione 2.46.0, namespace è impostato su INSTANCE_ID/INSTANCE_NAME.

Se disponi di grafici, dashboard o criteri di avviso che utilizzano l'etichetta namespace, potresti dover aggiornare le query dopo aver eseguito l'upgrade di Ops Agent alla versione 2.46.0 o successive. Ad esempio, se la tua query PromQL ha il seguente formato: http_requests_total{namespace="123456789"}, devi cambiarla in http_requests_total{namespace=~"123456789.*"}, poiché l'etichetta namespace ha il formato INSTANCE_ID/INSTANCE_NAME.

Le metriche di Prometheus non tipiche cambiano il tipo di metrica a partire da Ops Agent versione 2.39.0

A partire dalla versione 2.39.0, Ops Agent supporta l'importazione di metriche Prometheus con tipi sconosciuti. Nelle versioni precedenti, queste metriche vengono trattate da Ops Agent come indicatori, ma a partire dalla versione 2.39.0, le metriche non tipiche vengono trattate come indicatori e contatori. Di conseguenza, gli utenti possono utilizzare operazioni cumulative su queste metriche.

Se disponi di grafici, dashboard o criteri di avviso che utilizzano MQL per eseguire query su metriche di Prometheus non tipiche, devi aggiornare le query MQL dopo aver eseguito l'upgrade di Ops Agent alla versione 2.39.0 o successive. Anziché eseguire query sulle metriche non tipiche come prometheus.googleapis.com/METRIC_NAME/gauge, modifica i tipi di metrica come segue:

• Utilizza prometheus.googleapis.com/METRIC_NAME/unknown per la versione indicatore della metrica.
• Utilizza prometheus.googleapis.com/METRIC_NAME/unknown:counter per la versione contatore della metrica.

Non è necessario apportare modifiche a grafici, dashboard o criteri di avviso che utilizzano PromQL per eseguire query su metriche di Prometheus non tipiche, ma puoi applicare operazioni cumulative a queste metriche dopo aver eseguito l'upgrade di Ops Agent alla versione 2.39.0 o successive.

Elevato utilizzo di memoria sulle VM Windows (versioni da 2.27.0 a 2.29.0)

Su Windows in Ops Agent, versioni da 2.27.0 a 2.29.0, un bug che causava la perdita di socket da parte dell'agente causava un aumento dell'utilizzo della memoria e un elevato numero di handle gestiti dal processo fluent-bit.exe.

Per risolvere il problema, esegui l'upgrade di Ops Agent alla versione 2.30.0 o successive e riavvia l'agente.

I fusi orari del registro eventi non sono corretti su Windows (versioni da 2.15.0 a 2.26.0)

I timestamp associati ai log eventi di Windows in Cloud Logging potrebbero non essere corretti se modifichi il fuso orario della VM rispetto al fuso orario UTC. Questo problema è stato risolto in Ops Agent 2.27.0, ma a causa del problema noto di memoria elevata di Windows, ti consigliamo di eseguire l'upgrade almeno ad Ops Agent 2.30.0 se stai riscontrando questo problema. Se non riesci a eseguire l'upgrade, puoi provare una delle seguenti soluzioni.

Utilizzare un fuso orario UTC

In PowerShell, esegui questi comandi come amministratore:

Set-TimeZone -Id "UTC"
Restart-Service -Name "google-cloud-ops-agent-fluent-bit" -Force

Esegui l'override dell'impostazione del fuso orario solo per il servizio sub-agente di logging

In PowerShell, esegui questi comandi come amministratore:

Attenzione: il valore del Registro di sistema Ambiente verrà sovrascritto per il servizio, se esistente.

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\google-cloud-ops-agent-fluent-bit" -Name "Environment" -Type "MultiString" -Value "TZ=UTC0"
Restart-Service -Name "google-cloud-ops-agent-fluent-bit" -Force

I timestamp analizzati su Windows hanno un fuso orario errato (qualsiasi versione precedente alla 2.27.0)

Se utilizzi un processore di log che analizza un timestamp, il valore del fuso orario non verrà analizzato correttamente su Windows. Questo problema è stato risolto in Ops Agent 2.27.0, ma a causa del noto problema di memoria elevata di Windows, ti consigliamo di eseguire l'upgrade almeno ad Ops Agent 2.30.0 se riscontri questo problema.

Problemi noti nelle release precedenti di Ops Agent

Le seguenti sezioni descrivono i problemi noti che si verificano con le release precedenti di Ops Agent.

Log non dannosi (versioni 2.9.1 e precedenti)

Potresti visualizzare errori durante lo scraping delle metriche da pseudo-processi o processi limitati. I seguenti log non sono dannosi e possono essere tranquillamente ignorati. Per eliminare questi messaggi, eseguire l'upgrade di Ops Agent alla versione 2.10.0 o successiva.

    Jul 13 17:28:55 debian9-trouble otelopscol[2134]: 2021-07-13T17:28:55.848Z        error        scraperhelper/scrapercontroller.go:205        Error scraping metrics        {"kind"
  : "receiver", "name": "hostmetrics/hostmetrics", "error": "[error reading process name for pid 2: readlink /proc/2/exe: no such file or directory; error reading process name for
  pid 3: readlink /proc/3/exe: no such file or directory; error reading process name for pid 4: readlink /proc/4/exe: no such file or directory; error reading process name for pid
  5: readlink /proc/5/exe: no such file or directory; error reading process name for pid 6: readlink /proc/6/exe: no such file or directory; error reading process name for pid 7: r
  eadlink /proc/7/exe: no such file or directory; error reading process name for pid 8: readlink /proc/8/exe: no such file or directory; error reading process name for pid 9: readl
  ink /proc/9/exe: no such file or directory; error reading process name for pid 10: readlink /proc/10/exe: no such file or directory; error reading process name for pid 11: readli
  nk /proc/11/exe: no such file or directory; error reading process name for pid 12: readlink /proc/12/exe: no such file or directory; error reading process name for pid 13: readli
  nk /proc/13/exe: no such file or directory; error reading process name for pid 14: readlink /proc/14/exe: no such file or directory; error reading process name for pid 15: readli
  nk /proc/15/exe: no such file or directory; error reading process name for pid 16: readlink /proc/16/exe: no such file or directory; error reading process name for pid 17: readli
  nk /proc/17/exe: no such file or directory; error reading process name for pid 18: readlink /proc/18/exe: no such file or directory; error reading process name for pid 19: readli
  nk /proc/19/exe: no such file or directory; error reading process name for pid 20: readlink /proc/20/exe: no such file or directory; error reading process name for pid 21: readli
  nk /proc/21/exe: no such file or directory; error reading process name for pid 22: readlink /proc/22/exe: no such file or directory; error reading process name for pid
  Jul 13 17:28:55 debian9-trouble otelopscol[2134]: 23: readlink /proc/23/exe: no such file or directory; error reading process name for pid 24: readlink /proc/24/exe: no such file
   or directory; error reading process name for pid 25: readlink /proc/25/exe: no such file or directory; error reading process name for pid 26: readlink /proc/26/exe: no such file
   or directory; error reading process name for pid 27: readlink /proc/27/exe: no such file or directory; error reading process name for pid 28: readlink /proc/28/exe: no such file
   or directory; error reading process name for pid 30: readlink /proc/30/exe: no such file or directory; error reading process name for pid 31: readlink /proc/31/exe: no such file
   or directory; error reading process name for pid 43: readlink /proc/43/exe: no such file or directory; error reading process name for pid 44: readlink /proc/44/exe: no such file
   or directory; error reading process name for pid 45: readlink /proc/45/exe: no such file or directory; error reading process name for pid 90: readlink /proc/90/exe: no such file
   or directory; error reading process name for pid 92: readlink /proc/92/exe: no such file or directory; error reading process name for pid 106: readlink /proc/106/exe: no such fi
  le or directory; error reading process name for pid 360: readlink /proc/360/exe: no such file or directory; error reading process name for pid 375: readlink /proc/375/exe: no suc
  h file or directory; error reading process name for pid 384: readlink /proc/384/exe: no such file or directory; error reading process name for pid 386: readlink /proc/386/exe: no
   such file or directory; error reading process name for pid 387: readlink /proc/387/exe: no such file or directory; error reading process name for pid 422: readlink /proc/422/exe
  : no such file or directory; error reading process name for pid 491: readlink /proc/491/exe: no such file or directory; error reading process name for pid 500: readlink /proc/500
  /exe: no such file or directory; error reading process name for pid 2121: readlink /proc/2121/exe: no such file or directory; error reading
  Jul 13 17:28:55 debian9-trouble otelopscol[2134]: process name for pid 2127: readlink /proc/2127/exe: no such file or directory]"}
  Jul 13 17:28:55 debian9-trouble otelopscol[2134]: go.opentelemetry.io/collector/receiver/scraperhelper.(controller).scrapeMetricsAndReport
  Jul 13 17:28:55 debian9-trouble otelopscol[2134]:         /root/go/pkg/mod/go.opentelemetry.io/collector@v0.29.0/receiver/scraperhelper/scrapercontroller.go:205
  Jul 13 17:28:55 debian9-trouble otelopscol[2134]: go.opentelemetry.io/collector/receiver/scraperhelper.(controller).startScraping.func1
  Jul 13 17:28:55 debian9-trouble otelopscol[2134]:         /root/go/pkg/mod/go.opentelemetry.io/collector@v0.29.0/receiver/scraperhelper/scrapercontroller.go:186
  

I log personali dell'agente consumano troppo CPU, memoria e spazio su disco (versioni 2.16.0 e precedenti)

Le versioni di Ops Agent precedenti alla 2.17.0 potrebbero consumare molta CPU, memoria e spazio su disco con file /var/log/google-cloud-ops-agent/subagents/logging-module.log su VM Linux o file C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log sulle VM Windows a causa di blocchi di buffer danneggiati. In questo caso, nel file logging-module.log viene visualizzato un numero elevato di messaggi come il seguente.

  [2022/04/30 05:23:38] [error] [input chunk] error writing data from tail.2 instance
  [2022/04/30 05:23:38] [error] [storage] format check failed: tail.2/2004860-1650614856.691268293.flb
  [2022/04/30 05:23:38] [error] [storage] format check failed: tail.2/2004860-1650614856.691268293.flb
  [2022/04/30 05:23:38] [error] [storage] [cio file] file is not mmap()ed: tail.2:2004860-1650614856.691268293.flb
  

Per risolvere questo problema, esegui l'upgrade di Ops Agent alla versione 2.17.0 o successiva e reimposta completamente lo stato dell'agente.

Se il sistema genera ancora un volume elevato di log automatici degli agenti, valuta la possibilità di utilizzare la rotazione dei log. Per maggiori informazioni, consulta Configurare la rotazione dei log.