Risolvere i problemi di importazione dati di Ops Agent

Questo documento fornisce informazioni per aiutarti a 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 Risolvi 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 Ops Agent, la console Google Cloud 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 l'errore di installazione

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

• La VM non ha un account di servizio associato. Collega un service account alla VM, quindi reinstalla Ops Agent.

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

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 manca il ruolo roles/logging.logWriter o roles/monitoring.metricWriter.
• L'ambito di accesso per il logging o il monitoraggio non è abilitato. Per informazioni su come controllare e aggiornare gli ambiti di accesso, consulta Verifica 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 dell'agente uptime e verifica 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  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 Builder Codice, seleziona Codice, quindi imposta la lingua su PromQL.

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

   rate({"__name__"="agent.googleapis.com/agent/uptime", monitored_resource="gce_instance"}[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à del runtime dell'agente.

Pipeline di logging sottoposte ad upgrade

A partire da Ops Agent 2.66.0, la pipeline di logging predefinita è gestita dal servizio agente Metrics anziché dal servizio agente Logging. A partire da Ops Agent 2.72.0, tutte le pipeline di logging supportate sono gestite dal servizio Agente di Metrics. Se le pipeline di logging non funzionano come previsto, puoi provare a ripristinare il vecchio servizio dell'agente Logging aggiornando la configurazione:

logging:
  service:
    experimental_otel_logging: false

Questa impostazione verrà rimossa, quindi se devi ripristinare la versione precedente, contatta l'assistenza clienti Google Cloud per segnalare il problema.

Nota: ogni servizio conserva il proprio record dei log elaborati, quindi il passaggio da un servizio all'altro comporterà l'elaborazione di log duplicati.

Errori della pipeline

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

• Verifica che i file di archiviazione del subagente 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 l'accesso SSH alla VM.

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

Linux

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

   sudo systemctl restart google-cloud-ops-agent
   

2. Per verificare che l'agente sia stato riavviato, esegui il seguente comando e verifica che i componenti "Agente Metriche" e "Agente Logging" 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 questo comando PowerShell:

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

4. Per verificare che l'agente sia stato riavviato, esegui il seguente comando e verifica che i componenti "Agente Metriche" e "Agente Logging" siano stati avviati:

   Get-Service google-cloud-ops-agent*
   

Errori di analisi dei log

Se visualizzi l'errore di runtime LogParseErr ("Ops Agent non è riuscito ad analizzare i log"), il problema più probabile è nella configurazione di un processore di logging. Per risolvere il problema, segui questi passaggi:

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

Se modifichi la configurazione del logging, riavvia Ops Agent:

Linux

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

   sudo systemctl restart google-cloud-ops-agent
   

2. Per verificare che l'agente sia stato riavviato, esegui il seguente comando e verifica che i componenti "Agente Metriche" e "Agente Logging" 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 questo comando PowerShell:

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

4. Per verificare che l'agente sia stato riavviato, esegui il seguente comando e verifica che i componenti "Agente Metriche" e "Agente Logging" siano stati avviati:

   Get-Service google-cloud-ops-agent*
   

Controlla le metriche locali

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

Questi passaggi richiedono l'accesso SSH alla VM.

• 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 Gestione attività.

Controlla il log del modulo di logging

Questo passaggio richiede l'accesso SSH alla VM.

Puoi trovare i log del modulo di logging in /var/log/google-cloud-ops-agent/subagents/*.log per Linux e in C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log per Windows. Se non sono presenti log, il servizio dell'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 Autore 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 potresti visualizzare 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 di questo problema, consulta Autorizza Ops Agent.

L'agente invia metriche a Cloud Monitoring?

Controlla 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 dell'agente non è in esecuzione correttamente. Vai prima alla sezione L'agente è installato, ma non è in esecuzione per correggere questa condizione.

• Potresti visualizzare errori PermissionDenied 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 Monitoring Metric Writer.

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

• Nel log del modulo potresti visualizzare 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 di questo problema, consulta Autorizza Ops Agent.

Problemi di connettività di rete

Se l'agente è in esecuzione, ma non invia log né metriche, potresti avere 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, consulta Panoramica del networking per le VM.

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

• Regole firewall che interferiscono con il traffico in entrata. Per informazioni sulle regole firewall, consulta Utilizza le regole firewall VPC.
• Problemi nella configurazione del proxy HTTP.
• Ispezione TLS su un proxy in uscita.
• Configurazione DNS.

Ops Agent esegue controlli di integrità che rilevano errori di connessione 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 "Impossibile eseguire il flush del chunk"

A partire dalla versione 2.28.0, Ops Agent limita la quantità di spazio su disco che può utilizzare per archiviare i blocchi del 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 della rete causa la scrittura di blocchi di buffer sul disco, Ops Agent utilizza una quantità di spazio su disco specifica della piattaforma per archiviare i blocchi. Un messaggio simile all'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, consulta Configura un proxy HTTP.

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

Ispezione TLS su un proxy in uscita

Se un proxy o un firewall in uscita esegue l'ispezione TLS sul traffico verso *.googleapis.com utilizzando un certificato CA personalizzato non attendibile per la VM, gli handshake TLS non vanno a buon fine. I log del subagente registrano errori dei certificati come x509: certificate signed by unknown authority e la telemetria smette di raggiungere Cloud Logging e Cloud Monitoring.

Durante errori di esportazione prolungati, i batch di nuovi tentativi in coda possono accumularsi nella memoria nel processo otelopscol e aumentare la memoria utilizzata sulla VM. A partire dalla versione 2.66.0 di Ops Agent, il processo otelopscol gestisce la pipeline di logging predefinita e, a partire dalla versione 2.72.0, gestisce tutte le pipeline di logging supportate.

Per verificare se un proxy in uscita sta intercettando le connessioni TLS da una VM Linux, esegui il comando openssl s_client per ispezionare la catena di certificati per logging.googleapis.com:

echo | openssl s_client -connect logging.googleapis.com:443 \
  -servername logging.googleapis.com

Se la VM instrada il traffico tramite un proxy HTTP esplicito, includi il flag -proxy:

echo | openssl s_client -proxy PROXY_HOST:PROXY_PORT \
  -connect logging.googleapis.com:443 -servername logging.googleapis.com

Sostituisci quanto segue:

• PROXY_HOST: il nome host o l'indirizzo IP del proxy HTTP.
• PROXY_PORT: il numero di porta del proxy HTTP.

Se il valore del campo del certificato issuer è la CA del proxy o del firewall anziché Google Trust Services, con un valore Verify return code diverso da zero, l'ispezione TLS è attiva.

Per risolvere il problema, esegui una delle seguenti operazioni, quindi riavvia Ops Agent:

• Configura il proxy o il firewall in uscita in modo da bypassare l'ispezione TLS per *.googleapis.com, inclusi logging.googleapis.com, monitoring.googleapis.com, telemetry.googleapis.com e oauth2.googleapis.com.
• Installa il certificato CA radice del proxy nell'archivio di attendibilità di sistema della VM.

Voglio raccogliere solo metriche o log, non entrambi

Per impostazione predefinita, Ops Agent raccoglie sia metriche sia log. Per disattivare la raccolta di metriche o log, utilizza il file config.yaml di Ops Agent per eseguire l'override del servizio logging o metrics predefinito in modo che la pipeline predefinita non abbia receiver. Per saperne di più, consulta le seguenti risorse:

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

L'interruzione dell'importazione dati tramite la disattivazione dei servizi dei subagenti di Ops Agent "Logging Agent" o "Metrics Agent" genera una configurazione non valida e non è supportata.

Le metriche vengono raccolte, ma sembra che ci sia un problema

Questa sezione descrive alcune condizioni di errore comuni.

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

Le voci di log "Esportazione non riuscita" vengono visualizzate quando il primo punto dati di una metrica cumulativa viene ignorato. 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 "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 di metriche cumulative, la soluzione è riavviare la VM. Ops Agent e l'agente Monitoring calcolano le ore di inizio per le metriche cumulative in modo diverso, il che può comportare la visualizzazione di punti non in ordine. 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 "Uno o più punti sono stati scritti più frequentemente del periodo di campionamento massimo"

Se lo stesso ricevitore viene utilizzato in più pipeline nella configurazione di Ops Agent, le metriche raccolte da quel ricevitore vengono inviate da ogni pipeline che lo utilizza. Questa configurazione può causare la duplicazione delle metriche e generare errori "I punti sono stati scritti più frequentemente del periodo di campionamento massimo" nei log:

Jan 26 11:11:06 * otelopscol[1234]: 2026-01-26T11:11:06.665Z#011error#011exporterhelper/queued_retry.go:367#011Exporting failed. Dropping data.
{"error": "failed to export metrics to projects/*: rpc error: code = InvalidArgument desc = One or more TimeSeries could not be written:
timeSeries[...] (... metric.type=\"agent.googleapis.com/cpu/utilization\", ... resource.type=\"gce_instance\", ...):
write for resource failed: One or more points were written more frequently than the maximum sampling period configured for the metric."}

La duplicazione delle metriche si verifica spesso quando aggiungi un ricevitore a una nuova pipeline che è già utilizzata nella configurazione predefinita integrata di Ops Agent. Poiché la configurazione predefinita non viene mostrata esplicitamente nel file config.yaml, potresti non sapere che un ricevitore è già in uso. Quando crei nuove pipeline, consulta la documentazione sulla configurazione predefinita di Ops Agent per vedere quali receiver vengono utilizzati nelle pipeline predefinite. Ad esempio, il ricevitore hostmetrics è abilitato per impostazione predefinita in default_pipeline. Se crei e attivi una nuova pipeline che utilizza anche il receiver hostmetrics nel tuo config.yaml, le metriche di hostmetrics vengono inviate due volte perché il receiver è ora utilizzato in due pipeline.

Per risolvere il problema, evita la duplicazione delle metriche assicurandoti che lo stesso ricevitore non venga utilizzato in più pipeline che scrivono in Cloud Monitoring. Puoi farlo rimuovendo il receiver dalla pipeline definita dall'utente o eseguendo l'override di default_pipeline per rimuovere il receiver.

L'agente registra i 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, consulta Configura NTP su una VM.

L'agente registra "metrics receiver with type "nvml" is not supported" (il ricevitore di metriche con tipo "nvml" non è supportato)

Se raccogli le metriche della GPU NVIDIA Management Library (NVML) (agent.googleapis.com/gpu) utilizzando il ricevitore nvml, significa che utilizzi una versione di Ops Agent con supporto in 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.

Viene visualizzato il messaggio di errore "Il ricevitore di metriche con tipo "nvml" non è supportato" dopo l'installazione di Ops Agent versione 2.38.0 o successive quando utilizzavi il ricevitore nvml in 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 in modo da eseguire l'override dell'intervallo di raccolta sul ricevitore hostmetrics.

Metriche della GPU mancanti

Se Ops Agent raccoglie alcune metriche, ma mancano alcune o tutte le metriche della GPU (agent.googleapis.com/gpu) della NVIDIA Management Library (NVML), 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, segui questi passaggi:

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

2. Se il driver non è installato, segui questi passaggi:

   1. Installa il driver della GPU.

   2. Riavvia Ops Agent.

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

   3. Controlla i log di 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 della GPU è installato e i log di Ops Agent indicano che Ops Agent comunica con il driver, ma non vedi alcuna metrica della GPU, il problema potrebbe riguardare il grafico che stai utilizzando. Per informazioni sulla risoluzione dei problemi relativi ai grafici, consulta Il grafico non visualizza dati.

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

Alcune metriche sono mancanti o incoerenti

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

La tabella seguente descrive le differenze nell'acquisizione dei dati da parte di Ops Agent e dell'agente Monitoring legacy.

Tipo di metrica, omettendo agent.googleapis.com	Ops Agent (GA)^†	Ops Agent (anteprima)^†	Agente Monitoring legacy
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 viene importato per i dispositivi virtuali come tmpfs e udev.	Importato senza /dev nel percorso nell'etichetta device, ad esempio sda15. Importati per dispositivi virtuali come tmpfs e udev.	Importato senza /dev nel percorso nell'etichetta device, ad esempio sda15. Importati per dispositivi virtuali come tmpfs e udev.

^† La colonna GA si riferisce alle versioni di Ops Agent 2.0.0 e successive. 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 a Ops Agent in esecuzione su Windows.

Ritardo nell'arrivo dei log

Se noti un ritardo nell'arrivo dei log, ma vedi l'arrivo di voci di log SuccessAudit di Windows, ad esempio "An attempt was made to access an object.", il numero di voci di log SuccessAudit potrebbe impedire l'importazione dei log in tempo. Per risolvere il problema, disattiva le voci di log SuccessAudit se non sono necessarie.

Contatori delle prestazioni danneggiati su Windows

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

cd C:\Windows\system32
lodctr /R

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

Una volta eseguito il comando, 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 ripristinarlo in uno stato nuovo.

Nota: questo processo rimuove tutto lo stato del buffer, il che può comportare la perdita di log. Per una procedura che non reimposta lo stato del buffer, consulta Reimposta, ma salva i file del buffer.

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 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/*/

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

• File buffer: questi file sono voci di log memorizzate nel buffer che sono state monitorate ed elaborate da Ops Agent, ma non ancora importate in Cloud Logging. Quando sono presenti chunk danneggiati, Ops Agent deve ignorarli nelle versioni >= 2.15.0. In alcuni casi, tuttavia, devono essere rimosse manualmente. Questi file vengono archiviati in cartelle nidificate come: /var/lib/google-cloud-ops-agent/fluent-bit/buffers/tail.1/*
• File di posizione di tailing dei file di log: questi file registrano la posizione nei file di log in cui Ops Agent ha già eseguito il tailing. Se questi file vengono rimossi, Ops Agent inizierà dall'inizio dei file per cui è configurato il tailing. L'eliminazione di questi file può comportare la duplicazione dei log se questi erano stati precedentemente importati correttamente. Questi file vengono archiviati direttamente nella directory come file, ad esempio: /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 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.

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 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}

Nota: analogamente a Linux, questo comando elimina solo le sottodirectory nella directory C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers, in modo che i file buffer vengano rimossi, ma i file di posizione rimangano invariati.

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 del buffer

Se la VM non contiene blocchi di buffer danneggiati (ovvero non sono presenti messaggi format check failed nel file di log automatico 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 Ripristina 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 con 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 Ripristina 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à importati 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 vengono archiviati 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 release recenti di Ops Agent

Le sezioni seguenti descrivono i problemi noti delle release recenti di 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 il target di scraping emette metriche con metriche *_created aggiuntive per i contatori (per supportare la nuova funzionalità sperimentale dei timestamp di creazione), l'agente potrebbe non riuscire a scrivere le metriche e segnalare errori che indicano che le ore di inizio devono essere positive. 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 sarà possibile correggerlo in una nuova release di Ops Agent, utilizza la versione 2.55.0, che non è interessata. Se utilizzi le policy dell'agente, puoi anche bloccare la versione su 2.55.0 per impedire gli upgrade. Per saperne di più, consulta Installazione di una versione specifica dell'agente.

Loop di arresto anomalo di Ops Agent versione 2.47.0, 2.48.0 o 2.49.0

Le versioni 2.47.0, 2.48.0 e 2.49.0 incorporavano un componente FluentBit difettoso per il logging. Questo componente non riesce a elaborare righe di log specifiche e causa un loop di arresto anomalo di Ops Agent.

Questo problema è stato risolto nella versione 2.50.0 di Ops Agent.

Lo spazio dei nomi delle metriche di 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 durante l'importazione delle metriche nel formato di importazione di Prometheus. Nelle versioni precedenti, le metriche di 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 policy 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 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 non tipizzate cambiano tipo di metrica a partire dalla versione 2.39.0 di 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 da Ops Agent come indicatori, ma a partire dalla versione 2.39.0, le metriche non tipizzate vengono trattate sia come indicatori che come contatori. Di conseguenza, ora gli utenti possono utilizzare 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 utilizzata sulle VM Windows (versioni da 2.27.0 a 2.29.0)

In Windows, nelle versioni di Ops Agent dalla 2.27.0 alla 2.29.0, un bug che causava occasionalmente la perdita di socket da parte dell'agente ha portato a un aumento della memoria utilizzata e a un numero elevato di handle detenuti dal processo fluent-bit.exe.

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

I fusi orari del log eventi non sono corretti su Windows (versioni dalla 2.15.0 alla 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 almeno a Ops Agent 2.30.0 se riscontri questo problema. Se non riesci a eseguire l'upgrade, puoi provare una delle seguenti soluzioni alternative.

Utilizza 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

Esegui l'override dell'impostazione del fuso orario solo per il servizio dell'agente secondario di Logging

In PowerShell, esegui i seguenti comandi come amministratore:

Attenzione: questa operazione sovrascriverà il valore del registro Environment per il servizio, se esiste già.

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. Il 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 a 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 limitati. I seguenti log non sono dannosi e possono essere ignorati in sicurezza. Per eliminare questi messaggi, esegui l'upgrade di 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 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 su VM Windows a causa di blocchi di buffer danneggiati. In questo caso, nel file logging-module.log viene visualizzato un numero elevato di messaggi simili ai seguenti.

  [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 di Ops Agent alla versione 2.17.0 o successive e reimposta completamente lo stato dell'agente.

Se il sistema genera ancora un volume elevato di log automatici dell'agente, valuta la possibilità di utilizzare la rotazione dei log. Per saperne di più, consulta Configura la rotazione dei log.