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, nell'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.

La consoleGoogle Cloud mostra l'installazione di Ops Agent bloccata su "In attesa"

Anche dopo aver installato correttamente l'Ops Agent, la Google Cloud console potrebbe comunque visualizzare lo stato "In attesa". Utilizza gcpdiag per confermare l'installazione di Ops Agent e verificare che l'agente trasmetta log e metriche dalla tua istanza VM.

Motivi comuni per il mancato completamento dell'installazione

L'installazione di Ops Agent potrebbe non riuscire per i seguenti motivi:

• La VM non ha un account di servizio collegato. Collega un service account alla VM e poi reinstalla Ops Agent.

• Nella VM è già installato uno degli agenti legacy, il che impedisce l'installazione di Ops Agent. Disinstalla gli agenti legacy e poi reinstalla l'agente operativo.

Motivi comuni degli errori di trasmissione della telemetria

Un Ops Agent installato e in esecuzione potrebbe non riuscire a inviare log, metriche o entrambi da una VM per i seguenti motivi:

• Nel account di servizio collegato alla VM mancano i ruoli roles/logging.logWriter o roles/monitoring.metricWriter.
• L'ambito di accesso alla registrazione o al monitoraggio non è abilitato. Per informazioni su come controllare e aggiornare gli ambiti di accesso, consulta Verificare gli ambiti di accesso.
• L'API Logging o l'API Monitoring non è abilitata.

Utilizza i controlli di integrità dell'agente per identificare la causa principale e la soluzione corrispondente.

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

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

1. Nella console Google Cloud , vai alla pagina leaderboard Esplora metriche:

   Vai a Esplora metriche

   Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato con il sottotitolo Monitoring.

2. Nel pulsante di attivazione/disattivazione etichettato Codice generatore, seleziona Codice, quindi imposta la lingua su PromQL.

3. Inserisci la seguente query, quindi fai clic su Esegui:

   rate({"agent.googleapis.com/agent/uptime", monitored_resource="gce_instance"}[1m])
   

L'agente invia log a Cloud Logging?

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

Errori della pipeline

Se visualizzi l'errore di runtime LogPipelineErr ("Ops Agent logging pipeline failed"), il subagent Logging ha riscontrato un problema con la scrittura dei log. Controlla le seguenti condizioni:

• Verifica che i file di archiviazione del subagent di 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 del logging sia corretta.

Questi passaggi richiedono di accedere alla VM tramite SSH.

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

Errori di analisi dei log

Se visualizzi l'errore di runtime LogParseErr ("Ops Agent failed to parse logs"), il problema più probabile è nella configurazione di un processore di logging. Per risolvere il problema:

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

Questi passaggi richiedono di accedere alla VM tramite SSH.

Se modifichi la configurazione della registrazione, riavvia l&#39Ops Agento:

Controllare le metriche locali

Questi passaggi richiedono di accedere alla VM tramite SSH.

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

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 l'accesso SSH alla VM.

Puoi trovare i log del modulo di logging all'indirizzo /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 sono presenti log, il servizio agente non è in esecuzione correttamente. Vai prima alla sezione L'agente è installato, ma non in esecuzione per risolvere il problema.

• Potresti visualizzare errori di autorizzazione 403 durante la scrittura 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 Scrittore log.

• Potresti riscontrare 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 l'errore, aumenta la quota o riduci la velocità effettiva dei log.

• Nel log del modulo potrebbero essere presenti 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 service account o credenziali specificate. Per informazioni sulla risoluzione del problema, consulta Autorizzare l'agente operativo.

L'agente invia metriche a Cloud Monitoring?

Controllare il log del modulo delle metriche

Questo passaggio richiede l'accesso SSH alla VM.

Puoi trovare i log del modulo delle metriche in syslog. Se non sono presenti log, significa che il servizio agent non è in esecuzione correttamente. Vai prima alla sezione L'agente è installato, ma non è in esecuzione per risolvere questa condizione.

• Potresti visualizzare errori PermissionDenied durante la scrittura nell'API Monitoring. Questo errore si verifica se l'autorizzazione per l&#39Ops Agents 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 risolvere questo errore, abilita l'API Monitoring e imposta il ruolo Scrittore metriche Monitoring.

• Potresti visualizzare errori ResourceExhausted durante la scrittura nell'API Monitoring. Questo errore si verifica se il progetto raggiunge il limite per le quote 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 l'errore, aumenta la quota o riduci la velocità effettiva delle metriche.

• Nel log del modulo potrebbero essere presenti 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 service account o credenziali specificate. Per informazioni sulla risoluzione del problema, consulta Autorizzare l'agente operativo.

Problemi di connettività di rete

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

Le cause più comuni dei problemi di connettività includono:

• Regole firewall che interferiscono con il traffico in entrata. Per informazioni sulle regole firewall, vedi Utilizzo delle regole firewall VPC.
• Problemi nella configurazione del proxy HTTP.
• Configurazione DNS.

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

Informazioni sui messaggi di errore "failed to flush chunk"

A partire dalla versione 2.28.0 di Ops Agent, Ops Agent limita la quantità di spazio su disco che può utilizzare per archiviare i blocchi del buffer. Ops Agent crea blocchi 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 dei blocchi del buffer su disco, l&#39Ops Agents utilizza una quantità di spazio su disco specifica della piattaforma per archiviare i blocchi. Un messaggio come quello dell'esempio seguente viene visualizzato anche in /var/log/google-cloud-ops-agent/subagents/logging-module.log sulle VM Linux o C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log sulle VM Windows quando la VM non può inviare i blocchi del buffer all'API Cloud Logging:

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

Problemi nel proxy HTTP

Un problema con la configurazione del proxy HTTP potrebbe generare errori. Ad esempio, gli errori di flb_upstream con il termine context indicano un problema con la configurazione del proxy:

[2024/03/25 12:21:51] [error] [C:\work\submodules\fluent-bit\src\flb_upstream.c:281 errno=2] No such file or directory
[2024/03/25 12:21:51] [error] [upstream] error creating context from URL: https://oauth2.googleapis.com/token
[2024/03/25 12:21:51] [error] [oauth2] error creating upstream context

Per risolvere il problema, verifica che il proxy HTTP sia stato configurato correttamente. Per istruzioni su come configurare il proxy HTTP, vedi Configura un proxy HTTP.

Per le specifiche del formato del proxy HTTP, consulta il manuale ufficiale di Fluent Bit.

Voglio raccogliere solo metriche o log, non entrambi

Per impostazione predefinita, Ops Agent raccoglie sia metriche che log. Per disattivare la raccolta di metriche o log, utilizza il file config.yaml di Ops Agent per ignorare il servizio logging o metrics predefinito in modo che la pipeline predefinita non abbia ricevitori. Per ulteriori informazioni, consulta le seguenti risorse:

• Esempi di configurazioni di logging service.
• Esempi di configurazioni delle metricheservice.

L'interruzione dell'importazione dati disattivando i servizi secondari dell'Ops Agent "Logging Agent" o "Monitoring Agent" comporta una configurazione non valida e non è supportata.

Le metriche vengono raccolte, ma sembra che ci sia qualcosa che non va

L'agente registra il messaggio "Esportazione non riuscita. Verrà eseguito un nuovo tentativo"

Vengono visualizzate voci di log "Esportazione non riuscita" quando viene eliminato il primo punto dati di una metrica cumulativa. 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 registra i messaggi "TimeSeries could not be written: Points must be written in order." (Impossibile scrivere TimeSeries: i punti devono essere scritti in ordine).

Se hai eseguito l'upgrade a Ops Agent dall'agente Monitoring legacy e visualizzi il seguente messaggio di errore durante la scrittura delle metriche cumulative, la soluzione è riavviare la VM. Ops Agent e l'agente Monitoring calcolano gli orari di inizio per le metriche cumulative in modo diverso, il che può comportare la visualizzazione dei punti in ordine diverso. 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 registra messaggi "Il token deve essere un token di breve durata (60 minuti) e in un periodo di tempo ragionevole"

Se visualizzi 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, vedi Configurare NTP su una VM.

L'agente registra "metrics receiver with type "nvml" is not supported"

Se raccogli le metriche GPU della libreria di gestione NVIDIA (NVML) (agent.googleapis.com/gpu) utilizzando il ricevitore nvml, significa che hai utilizzato una versione di Ops Agent con il supporto dell'anteprima per le metriche NVML. Il supporto di queste metriche è diventato disponibile a livello generale nella versione 2.38.0 di Ops Agent. Nella versione GA, la raccolta delle metriche eseguita dal ricevitore nvml è stata unita al ricevitore hostmetrics e il ricevitore nvml è stato rimosso.

Visualizzi il messaggio di errore "metrics receiver with type "nvml" is not supported" dopo aver installato Ops Agent versione 2.38.0 o successive quando utilizzavi il ricevitore nvml di anteprima e hai sostituito l'intervallo di raccolta predefinito nel file di configurazione specificato dall'utente. L'errore si verifica perché il destinatario nvml non esiste più, ma il file di configurazione specificato dall'utente fa ancora riferimento a questo destinatario.

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

Mancano le metriche GPU

Se Ops Agent raccoglie alcune metriche, ma alcune o tutte le metriche GPU della NVIDIA Management Library (NVML) (agent.googleapis.com/gpu) non sono presenti, potresti avere un problema di configurazione o non avere processi che utilizzano la GPU.

Se non raccogli metriche della GPU, controlla il driver della GPU. Per raccogliere le metriche della GPU, Ops Agent richiede che il driver della GPU sia installato e configurato sulla VM. Per controllare il driver:

1. Per verificare che il driver sia installato e in esecuzione correttamente, segui i passaggi per verificare l'installazione del driver della GPU.

2. Se il driver non è installato:

   1. Installa il driver GPU.

   2. Riavvia Ops Agent.

      Devi riavviare Ops Agent dopo aver installato o eseguito l'upgrade del driver GPU.

   3. Controlla i log dell'Ops Agent per verificare che la comunicazione sia stata avviata correttamente. I messaggi di log sono simili ai seguenti:

      Jul 11 18:28:12 multi-gpu-debian11-2 otelopscol[906670]: 2024-07-11T18:28:12.771Z        info        nvmlreceiver/client.go:128        Successfully initialized Nvidia Management Library
      Jul 11 18:28:12 multi-gpu-debian11-2 otelopscol[906670]: 2024-07-11T18:28:12.772Z        info        nvmlreceiver/client.go:151        Nvidia Management library version is 12.555.42.06
      Jul 11 18:28:12 multi-gpu-debian11-2 otelopscol[906670]: 2024-07-11T18:28:12.772Z        info        nvmlreceiver/client.go:157        NVIDIA driver version is 555.42.06
      Jul 11 18:28:12 multi-gpu-debian11-2 otelopscol[906670]: 2024-07-11T18:28:12.781Z        info        nvmlreceiver/client.go:192        Discovered Nvidia device 0 of model NVIDIA L4 with UUID GPU-fc5a05a7-8859-ec33-c940-3cf0930c0e61.
      

Se il driver GPU è installato e i log di Ops Agent indicano che Ops Agent comunica con il driver, ma non visualizzi alcuna metrica GPU, il problema potrebbe riguardare il grafico che stai utilizzando. Per informazioni sulla risoluzione dei problemi relativi ai grafici, consulta Il grafico non mostra dati.

Se raccogli alcune metriche della GPU, ma mancano le metriche processes, processes/max_bytes_used e processes/utilization, significa che non sono in esecuzione processi sulle GPU. Le metriche della GPU processes non vengono raccolte se non sono in esecuzione processi sulla GPU.

Alcune metriche sono mancanti o incoerenti

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

Problemi specifici di Windows

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

Contatori delle prestazioni danneggiati su Windows

Se il sub-agente delle metriche non viene avviato, potresti visualizzare 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 vengono danneggiati. Puoi risolvere gli errori ricreando i contatori delle prestazioni. In PowerShell come amministratore, esegui:

cd C:\Windows\system32
lodctr /R

Il comando precedente può occasionalmente non riuscire. In questo caso, ricarica PowerShell e riprova finché non va a buon fine.

Una volta eseguito correttamente il comando, riavvia Ops Agent:

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

Reimpostare completamente lo stato dell'agente

Se l'agente entra in uno stato non recuperabile, segui questi passaggi per ripristinarlo a uno stato iniziale.

Linux

Arresta 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 autonomi dell'agente sul 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/*/

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

Arresta 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 autonomi dell'agente sul 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}

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 sono presenti messaggi format check failed nel file di log automatico dell'Ops Agent), puoi saltare i comandi precedenti che rimuovono i buffer locali durante il ripristino 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 memorizzati nel buffer non danneggiati 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 buffer, puoi estrarre i nomi dei file buffer danneggiati dai log automatici dell'agente ed eliminare solo i file buffer 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 (che memorizzano l'avanzamento di Ops Agent per file di log). L'eliminazione dei file di posizione può comportare la duplicazione dei log già inseriti correttamente. Questa opzione rielabora solo i file di log correnti; non rielabora i file che sono 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 archiviati 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 versioni recenti di Ops Agent

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

La versione 2.56.0 di Ops Agent non riesce a inviare le metriche di Prometheus

Se utilizzi Ops Agent versione 2.56.0 insieme al ricevitore Prometheus e se la destinazione di scraping emette metriche con metriche *_created aggiuntive per i contatori (per supportare la nuova funzionalità sperimentale Timestamp di creazione), l'agente potrebbe non riuscire a scrivere le metriche e segnalare errori che indicano che gli orari di inizio devono essere positivi. I messaggi di log sono simili ai seguenti:

Field points[0].interval.start_time had an invalid value of \"1781-05-03T21:46:07.592596-07:52\": The start time must be positive.;

Si tratta di un problema con OpenTelemetry upstream. Per risolvere l'errore finché non viene corretto in una nuova release dell'Ops Agent, utilizza la versione 2.55.0, che non è interessata. Se utilizzi i criteri dell'agente, puoi anche bloccare la versione 2.55.0 per impedire gli upgrade. Per maggiori informazioni, vedi Installare una versione specifica dell'agente.

Loop di arresto anomalo delle versioni 2.47.0, 2.48.0 o 2.49.0 di Ops Agent

Le versioni 2.47.0, 2.48.0 e 2.49.0 incorporavano un componente FluentBit difettoso per la registrazione. Questo componente non funziona su righe di log specifiche e causa un ciclo di arresti anomali di Ops Agent.

Questo problema è stato risolto nella versione 2.50.0 dellOps Agent.

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

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

Se hai grafici, dashboard o criteri di avviso che utilizzano l'etichetta namespace, potresti dover aggiornare le query dopo l'upgrade dell'Ops Agent alla versione 2.46.0 o successive. Ad esempio, se la query PromQL era simile a: http_requests_total{namespace="123456789"}, devi modificarla in http_requests_total{namespace=~"123456789.*"}, poiché l'etichetta namespace è nel formato INSTANCE_ID/INSTANCE_NAME.

Le metriche Prometheus senza tipo cambiano tipo a partire dalla versione 2.39.0 dell'Ops Agent

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 dall&#39Ops Agento come indicatori, ma a partire dalla versione 2.39.0, le metriche senza tipo vengono trattate sia come indicatori che come contatori. Di conseguenza, ora gli utenti possono utilizzare le operazioni cumulative su queste metriche.

Se utilizzi PromQL, puoi applicare operazioni cumulative alle metriche Prometheus non tipizzate dopo aver eseguito l'upgrade di Ops Agent alla versione 2.39.0 o successive.

Utilizzo elevato della memoria sulle VM Windows (versioni da 2.27.0 a 2.29.0)

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

Per risolvere il problema, esegui l'upgrade dell'agente operativo alla versione 2.30.0 o successive e riavvia l'agente.

I fusi orari del log eventi sono errati su Windows (versioni da 2.15.0 a 2.26.0)

I timestamp associati ai log eventi di Windows in Cloud Logging potrebbero essere errati se modifichi il fuso orario della VM da 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 ad almeno Ops Agent 2.30.0 se riscontri questo problema. Se non riesci a eseguire l'upgrade, puoi provare una delle seguenti soluzioni alternative.

Utilizzare un fuso orario UTC

In PowerShell, esegui i seguenti comandi come amministratore:

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

Ignora l'impostazione del fuso orario solo per il servizio di sub-agente di logging

In PowerShell, esegui i seguenti comandi come amministratore:

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 problema noto di Windows con un utilizzo elevato della memoria, ti consigliamo di eseguire l'upgrade ad almeno Ops Agent 2.30.0 se riscontri questo problema.

Problemi noti nelle versioni precedenti di Ops Agent

Le sezioni seguenti descrivono i problemi noti che si verificano con le versioni 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 con limitazioni. I seguenti log non sono dannosi e possono essere ignorati in sicurezza. Per eliminare questi messaggi, esegui l'upgrade dell'Ops Agent alla versione 2.10.0 o successive.

    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 automatici dell'agente consumano troppa CPU, memoria e spazio su disco (versioni 2.16.0 e precedenti)

Le versioni dell'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 su VM Windows a causa di blocchi di buffer danneggiati. In questo caso, nel file logging-module.log vedrai 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 il problema, esegui l'upgrade dell'agente Ops alla versione 2.17.0 o successiva e reimposta completamente lo stato dell'agente.

Se il tuo sistema genera ancora un volume elevato di log automatici dell'agente, valuta la possibilità di utilizzare la rotazione dei log. Per ulteriori informazioni, vedi Configurare la rotazione dei log.