Questa pagina è stata tradotta dall'API Cloud Translation.

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 i log e le metriche, in Ops Agent in esecuzione. Se Ops Agent non è in esecuzione, consulta la sezione 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 console Google Cloud mostra che l'installazione di Ops Agent è bloccata su "In attesa"

Anche dopo aver installato correttamente l'Ops Agent, la console Google Cloud potrebbe continuare a mostrare lo stato "In attesa". Utilizza gcpdiag per confermare l'installazione di Ops Agent e per verificare che l'agente stia trasmettendo log e metriche dall'istanza VM.

Motivi comuni dell'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 account di servizio alla VM, quindi reinstalla Ops Agent.
Nella VM è già installato uno degli agenti legacy, che impedisce l'installazione di Ops Agent. Disinstalla gli agenti legacy e reinstalla l'agente operativo.

Cause 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:

Nell'account di servizio associato 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 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 Metrics Explorer 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.

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.
Nel pulsante di attivazione/disattivazione Codice Query Builder, seleziona Codice e imposta la lingua su MQL.

Inserisci la seguente query e poi fai clic su Esegui:

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

L'agente invia 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 della pipeline

Se viene visualizzato l'errore di runtime LogPipelineErr ("Pipeline di logging dell'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

Per riavviare l'agente, esegui il seguente comando sull'istanza:
```
sudo systemctl restart google-cloud-ops-agent
```
Per verificare che l'agente sia stato riavviato, esegui il seguente comando e verifica che i componenti "Metrics Agent" e "Logging Agent" siano stati avviati:
```
sudo systemctl status "google-cloud-ops-agent*"
```

Windows

Connettiti all'istanza utilizzando RDP o uno strumento simile e accedi a Windows.
Apri un terminale PowerShell con privilegi amministrativi facendo clic con il tasto destro del mouse sull'icona di PowerShell e selezionando Esegui come amministratore.
Per riavviare l'agente, esegui il seguente comando PowerShell:
```
Restart-Service google-cloud-ops-agent -Force
```
Per verificare che l'agente sia stato riavviato, esegui il seguente comando 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 ("Impossibile analizzare i log di Ops Agent"), il problema più probabile riguarda la configurazione di un'attività di elaborazione dei log. 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 l'accesso SSH alla VM.

Se modifichi la configurazione di registrazione, riavvia l'Ops Agent:

Linux

Per riavviare l'agente, esegui il seguente comando sull'istanza:
```
sudo systemctl restart google-cloud-ops-agent
```
Per verificare che l'agente sia stato riavviato, esegui il seguente comando e verifica che i componenti "Metrics Agent" e "Logging Agent" siano stati avviati:
```
sudo systemctl status "google-cloud-ops-agent*"
```

Windows

Connettiti all'istanza utilizzando RDP o uno strumento simile e accedi a Windows.
Apri un terminale PowerShell con privilegi amministrativi facendo clic con il tasto destro del mouse sull'icona di PowerShell e selezionando Esegui come amministratore.
Per riavviare l'agente, esegui il seguente comando PowerShell:
```
Restart-Service google-cloud-ops-agent -Force
```
Per verificare che l'agente sia stato riavviato, esegui il seguente comando e verifica che i componenti "Metrics Agent" e "Logging Agent" siano stati avviati:
```
Get-Service google-cloud-ops-agent*
```

Controllare le metriche locali

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 le attività 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 registrazione su /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, 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 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 di 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 questo errore, aumenta la quota o riduci la produttività 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 account di servizio o senza specificare le credenziali. Per informazioni su come risolvere il problema, consulta Autorizzare l'agente operativo.

L'agente invia le 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 Scrittore di metriche di monitoraggio.

Potresti visualizzare errori ResourceExhausted durante la scrittura nell'API Monitoring. Questo errore si verifica se il progetto raggiunge 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 il throughput 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 account di servizio o senza specificare le credenziali. Per informazioni su come risolvere il problema, consulta Autorizzare l'agente operativo.

Problemi di connettività di rete

Se l'agente è in esecuzione, ma non invia 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 della rete di Compute Engine, consulta Panoramica della rete per le VM.

Le cause comuni dei problemi di connettività sono:

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.

L'agente operativo esegue controlli di integrità che rilevano errori di connettività di rete. Consulta la documentazione relativa ai controlli di integrità per 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 memorizzare i frammenti del buffer. L'agente Ops crea chunk di buffer quando non è possibile inviare i dati di log all'API Cloud Logging. Senza un limite, questi chunk potrebbero consumare tutto lo spazio disponibile, interrompendo altri servizi sulla VM. Quando un'interruzione della rete provoca la scrittura di blocchi del buffer su disco, l'Ops Agent utilizza una quantità di spazio su disco specifica della piattaforma per archiviarli. Un messaggio come quello riportato nell'esempio seguente viene visualizzato anche in /var/log/google-cloud-ops-agent/subagents/logging-module.log su VM Linux o C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log su VM Windows quando la VM non riesce a inviare i chunk del 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 le metriche sia i log. Per disattivare la raccolta di metriche o log, utilizza il file Ops Agentconfig.yaml per sostituire il servizio logging o metrics predefinito in modo che la pipeline predefinita non abbia ricevitori. Per ulteriori informazioni, consulta quanto segue:

L'interruzione dell'importazione dati mediante la disattivazione dei servizi di agenti secondari di Ops Agent "Agente di logging" o "Agente di monitoraggio" comporta una configurazione non valida e non è supportata.

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

L'agente registra "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 tranquillamente ignorati:

  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 la serie temporale: i punti devono essere scritti in ordine".

Se hai eseguito l'upgrade a Ops Agent dall'agente di monitoraggio precedente e visualizzi il seguente messaggio di errore durante la scrittura delle metriche cumulative, la soluzione è riavviare la VM. Ops Agent e l'agente di monitoraggio calcolano i tempi di inizio per le metriche cumulative in modo diverso, il che può portare a visualizzare punti fuori sequenza. 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 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, indica 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 registra "Il destinatario delle metriche con tipo "nvml" non è supportato"

Se stai raccogliendo le metriche GPU della libreria di gestione NVIDIA (NVML) (agent.googleapis.com/gpu) utilizzando il ricevitore nvml, significa che stai utilizzando una versione di Ops Agent con il supporto di 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 destinatario nvml è stata unita al destinatario hostmetrics e il destinatario nvml è stato rimosso.

Viene visualizzato il messaggio di errore "Il ricevitore delle metriche di tipo "nvml" non è supportato" dopo aver installato Ops Agent versione 2.38.0 o successiva quando utilizzavi il ricevitore di anteprima nvml 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.

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

Le metriche GPU mancano

Se l'Ops Agent raccoglie alcune metriche, ma mancano alcune o tutte le metriche della GPU (agent.googleapis.com/gpu) della libreria di gestione NVIDIA (NVML), è possibile che si abbia un problema di configurazione o che non siano presenti processi che utilizzano la GPU.

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

Per verificare che il driver sia installato ed eseguito correttamente, segui la procedura per verificare l'installazione del driver GPU.

Se il driver non è installato:

Installa il driver GPU.
Riavvia Ops Agent.

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

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 sta comunicando con il driver, ma non visualizzi 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 mostra alcun dato.

Se stai raccogliendo 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 processes della GPU non vengono raccolte se non sono in esecuzione processi sulla GPU.

Alcune metriche sono mancanti o incoerenti

Esistono alcune metriche che la versione 2.0.0 e le versioni successive di Ops Agent gestiscono in modo diverso rispetto alle versioni "preview" di Ops Agent (versioni precedenti alla 2.0.0) o all'agente Monitoring.

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

Tipo di metrica, omettendo `agent.googleapis.com`	Ops Agent (GA)^†	Ops Agent (anteprima)^†	Agente Monitoring
`cpu_state`	I possibili valori per Windows sono `idle`, `interrupt,` `system` e `user`.	I possibili valori 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 importato per i dispositivi virtuali come `tmpfs` e `udev`.	Importato senza `/dev` nel percorso nell'etichetta `device`, ad esempio `sda15`. Importato per dispositivi virtuali come `tmpfs` e `udev`.	Importato senza `/dev` nel percorso nell'etichetta `device`, ad esempio `sda15`. Importato 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.

Contatori delle prestazioni danneggiati su Windows

Se il sottoagente delle metriche non si avvia, in Cloud Logging potresti visualizzare uno dei seguenti errori:

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 ricostruendo i contatori del rendimento. In PowerShell come amministratore, esegui:

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.

Dopo che il comando è andato a buon fine, riavvia Ops Agent:

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

Ripristina completamente lo stato dell'agente

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

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 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 in buffer: si tratta di voci di log in buffer che sono state monitorate ed elaborate da Ops Agent, ma non sono ancora state importate in Cloud Logging. Se sono presenti blocchi danneggiati, l'Ops Agent dovrebbe ignorarli nelle versioni >= 2.15.0. In alcuni casi, però, devono essere ripuliti manualmente. Questi file vengono archiviati nelle cartelle nidificate come: /var/lib/google-cloud-ops-agent/fluent-bit/buffers/tail.1/*
File di posizione del monitoraggio dei file di log: questi file registrano la posizione nei file di log in cui Ops Agent ha già eseguito il monitoraggio. Se questi file vengono rimossi, Ops Agent inizierà dalla parte superiore dei file per i quali è configurato il comando tail. L'eliminazione di questi file può comportare la duplicazione dei log se questi sono stati precedentemente importati 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 di 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

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

Ripristina, ma salva i file buffer

Se la VM non contiene chunk di buffer danneggiati (ovvero non sono presenti messaggi format check failed nel file di log autonomo di Ops Agent), puoi saltare i comandi precedenti che rimuovono i buffer locali quando reimposti lo 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 Ripristinare 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 in buffer non corrotti 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 Ripristinare completamente lo stato dell'agente.

Opzione 3: se non vuoi eliminare tutti i file di buffer, puoi estrarre i nomi dei file di buffer danneggiati dai log dell'agente e eliminare solo i file di 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 elabora nuovamente solo i file di log attuali; non elabora nuovamente i file che sono già stati ruotati o i log di altre fonti, come una porta TCP. I file posizione vengono 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 release recenti di Ops Agent

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

Arresto anomalo in loop della versione 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 includevano un componente FluentBit errato per la registrazione. Questo componente non funziona in righe di log specifiche e causa un loop di arresto anomalo dell'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 di Ops Agent

A partire dalla versione 2.46.0, l'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 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 aver eseguito l'upgrade di Ops Agent alla versione 2.46.0 o successiva. Ad esempio, se la query PromQL era simile a: http_requests_total{namespace="123456789"}, devi cambiarla in http_requests_total{namespace=~"123456789.*"}, poiché l'etichetta namespace è nel formato INSTANCE_ID/INSTANCE_NAME.

Le metriche non tipizzate di Prometheus cambiano il tipo di metrica a partire dalla versione 2.39.0 dell'Ops Agent

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

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

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

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

Utilizzo elevato della memoria nelle 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 comportato un aumento dell'utilizzo della memoria e un numero elevato di handle detenuti 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 scorretti se modifichi il fuso orario della VM da UTC. Il problema è stato risolto in Ops Agent 2.27.0, ma a causa del noto problema di utilizzo elevato di memoria di Windows, se riscontri questo problema ti consigliamo di eseguire l'upgrade almeno a Ops Agent 2.30.0. 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

Sostituire l'impostazione del fuso orario solo per il servizio di agente secondario 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 elaboratore di log che analizza un timestamp, il valore del fuso orario non verrà interpretato correttamente su Windows. Il problema è stato risolto in Ops Agent 2.27.0, ma a causa del noto problema di utilizzo elevato di memoria 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 release di Ops Agent precedenti.

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 tutta sicurezza. Per eliminare questi messaggi, esegui 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 dell'agente autonomo 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 i file /var/log/google-cloud-ops-agent/subagents/logging-module.log su VM Linux o i file C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log su VM Windows a causa di chunk 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 il problema, esegui l'upgrade di Ops Agent 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 degli agenti, valuta la possibilità di utilizzare la rotazione dei log. Per ulteriori informazioni, vedi Configurare la rotazione dei log.