Questa pagina è stata tradotta dall'API Cloud Translation.

Risolvi i problemi di importazione dati di Ops Agent

Questo documento fornisce informazioni per aiutarti a diagnosticare e risolvere i problemi. problemi di importazione dati, per log e metriche, in Ops Agent in esecuzione. Se Ops Agent non è in esecuzione, consulta l'articolo Risolvere i problemi di installazione e all'avvio.

Prima di iniziare

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

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

Anche dopo l'installazione di Ops Agent, nella console Google Cloud potrebbe ancora essere visualizzato lo stato "In attesa" . Utilizza gcpdiag per confermare l'installazione di Ops Agent e per verificare che, se l'agente e la trasmissione di log e metriche da un'istanza VM.

Motivi comuni per gli errori di installazione

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

Alla VM non è collegato un account di servizio. Collega un account di servizio alla VM e 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 Ops Agent.

Cause comuni degli errori di trasmissione di telemetria

Un Ops Agent installato e in esecuzione può non inviare log, metriche o entrambe da una VM per i seguenti motivi:

Nell'account di servizio collegato alla VM manca l'elemento roles/logging.logWriter oppure Ruolo roles/monitoring.metricWriter.
L'ambito di accesso al logging 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 sia abilitata.

Utilizza i controlli di integrità degli agenti 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 sta 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 Monitoraggio.
Nel pulsante di attivazione/disattivazione con etichetta Builder Code, seleziona Code (Codice) e poi 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 i log a Cloud Logging?

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

Errori della pipeline

Se viene visualizzato l'errore di runtime LogPipelineErr ("pipeline di logging di Ops Agent") non riuscita"), il subagente Logging ha riscontrato un problema di scrittura logaritmi. Controlla le seguenti condizioni:

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

Questi passaggi richiedono l'accesso tramite SSH alla VM.

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

Linux

Per riavviare l'agente, esegui questo comando sull'istanza:
```
sudo systemctl restart google-cloud-ops-agent
```
Per confermare che l'agente è stato riavviato, esegui questo comando verifica che i componenti di "Metrics Agent" e "Agente Logging" data di inizio:
```
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 entro il facendo clic con il tasto destro del mouse sull'icona di PowerShell e selezionando Run as Administrator (Esegui come amministratore)
Per riavviare l'agente, esegui il comando PowerShell seguente:
```
Restart-Service google-cloud-ops-agent -Force
```
Per confermare che l'agente è stato riavviato, esegui questo comando verifica che i componenti di "Metrics Agent" e "Agente Logging" data di inizio:
```
Get-Service google-cloud-ops-agent*
```

Errori di analisi dei log

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

Verifica che la configurazione di qualsiasi parse_json processori è corretto.
Verifica che la configurazione di qualsiasi parse_regex processori è corretto.
Se non hai processori parse_json o parse_regex, controlla la configurazione di qualsiasi altro tipo di accesso processori.

Questi passaggi richiedono l'accesso tramite SSH alla VM.

Se modifichi la configurazione del logging, riavvia Ops Agent:

Linux

Per riavviare l'agente, esegui questo comando sull'istanza:
```
sudo systemctl restart google-cloud-ops-agent
```
Per confermare che l'agente è stato riavviato, esegui questo comando verifica che i componenti di "Metrics Agent" e "Agente Logging" data di inizio:
```
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 entro il facendo clic con il tasto destro del mouse sull'icona di PowerShell e selezionando Run as Administrator (Esegui come amministratore)
Per riavviare l'agente, esegui il comando PowerShell seguente:
```
Restart-Service google-cloud-ops-agent -Force
```
Per confermare che l'agente è stato riavviato, esegui questo comando verifica che i componenti di "Metrics Agent" e "Agente Logging" data di inizio:
```
Get-Service google-cloud-ops-agent*
```

Controllare le metriche locali

Questi passaggi richiedono l'accesso tramite SSH alla VM.

Il modulo di logging è in esecuzione? Usa 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 in esecuzione processi nell'app Task Manager.

Controlla il log del modulo di logging

Questo passaggio richiede l'accesso tramite SSH alla VM.

I log del modulo di logging sono disponibili 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, significa che il servizio dell'agente non è in esecuzione. correttamente. Vai a L'agente è installato ma non in esecuzione per correggere la condizione.

È possibile che si verifichino errori di autorizzazione 403 durante la scrittura nell'account Logging API. 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 Ruolo Writer log.

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

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

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

Nel log del modulo potrebbero essere visualizzati i seguenti errori:
```
{"error":"invalid_request","error_description":"Service account not enabled on this instance"}
```
o
```
can't fetch token from the metadata server
```
Questi errori potrebbero indicare che hai eseguito il deployment dell'agente senza alcun servizio l'account di servizio o le credenziali specificate. Per informazioni su come risolvere questo problema, consulta Autorizzare Ops Agent.

L'agente invia le metriche a Cloud Monitoring?

Controllare il log del modulo delle metriche

Questo passaggio richiede l'accesso tramite SSH alla VM.

Puoi trovare i log del modulo delle metriche in syslog. Se non sono presenti log, indica che il servizio dell'agente non funziona correttamente. Vai alla sezione Prima sezione L'agente è installato, ma non in esecuzione tale condizione.

Potresti visualizzare PermissionDenied errore durante la scrittura nell'attributo l'API Monitoring. Questo errore si verifica se l'autorizzazione per Ops Agent non è configurato 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: abilitare l'API Monitoring e imposta Ruolo Writer metriche Monitoring.

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

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

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

Nel log del modulo potrebbero essere visualizzati i seguenti errori:
```
{"error":"invalid_request","error_description":"Service account not enabled on this instance"}
```
o
```
can't fetch token from the metadata server
```
Questi errori potrebbero indicare che hai eseguito il deployment dell'agente senza alcun servizio l'account di servizio o le credenziali specificate. Per informazioni su come risolvere questo problema, consulta Autorizzare Ops Agent.

Problemi di connettività di rete

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

Le cause comuni dei problemi di connettività sono le seguenti:

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

Ops Agent esegue controlli di integrità che rilevano errori di connettività di rete. Invita alla documentazione sui controlli di integrità per scoprire le azioni suggerite per per gli errori di connettività.

A partire da Ops Agent versione 2.28.0, Ops Agent limita la quantità di spazio su disco che può utilizzare per archiviare il buffer o blocchi di testo. Ops Agent crea blocchi del buffer quando non è possibile inviare i dati di logging all'API Cloud Logging. Senza un limite, questi blocchi potrebbero consumare di spazio disponibile, interrompendo gli altri servizi sulla VM. In caso di interruzione della rete causa la scrittura di blocchi del buffer su disco, Ops Agent utilizza un specifica della piattaforma per archiviare i chunk. Un messaggio come l'esempio che segue viene visualizzato /var/log/google-cloud-ops-agent/subagents/logging-module.log attivo 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

Voglio raccogliere solo metriche o log, non entrambi

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

Arresto dell'importazione dati disabilitando i servizi sub-agente Ops Agent "Agente Logging" o "Agente Monitoring" determina una configurazione non valida non è supportato.

È in corso la raccolta delle metriche, ma qualcosa sembra errato

L'agente sta registrando il messaggio "Esportazione non riuscita. Nuovo tentativo" messaggi

Viene visualizzato il messaggio "Esportazione non riuscita" di log quando il primo punto dati di un la metrica cumulativa viene eliminata. I seguenti log non sono dannosi e possono può essere ignorato.

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

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

Se hai eseguito l'upgrade a Ops Agent dall'agente Monitoring legacy e vedi il seguente messaggio di errore durante la scrittura di metriche cumulative, è riavviare la VM. Ops Agent e l'agente Monitoring calcolano l'inizio volte per le metriche cumulative in modo diverso, il che può portare alla visualizzazione di punti non è nell'ordine corretto. Il riavvio della VM reimposta l'ora di inizio e risolve il problema.

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

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

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

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

Per informazioni sulla sincronizzazione degli orologi di sistema, vedi Configura NTP su una VM.

L'agente sta registrando il "ricevitore delle metriche" con tipo "nvml" non è supportati"

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

Viene visualizzato il messaggio di errore "ricevitore delle metriche di tipo "nvml" non è supportati" dopo l'installazione Ops Agent 2.38.0 o versioni successive quando eseguivi utilizzando il ricevitore nvml di anteprima e hai sostituito la raccolta predefinita predefinito nel file di configurazione specificato dall'utente. L'errore si verifica perché il destinatario nvml non esiste più, ma è stato specificato dall'utente di configurazione del deployment.

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

Mancano metriche GPU

Se Ops Agent sta raccogliendo alcune metriche, ma alcune o tutte le metriche NVIDIA GPU della libreria di gestione (NVML) (agent.googleapis.com/gpu) metriche mancanti, è possibile che ci sia un problema di configurazione o che processi che utilizzano la GPU.

Se non stai raccogliendo metriche GPU, controlla il driver GPU. A raccolgono metriche GPU, Ops Agent richiede l'installazione del driver GPU e configurate sulla VM. Per controllare il conducente:

Per verificare che il driver sia installato e che funzioni correttamente: i passaggi per verificare l'installazione del driver GPU.

Se il driver non è installato:

Installa il driver GPU.
Riavvia Ops Agent.

Dopo l'installazione o l'upgrade, devi riavviare Ops Agent il driver 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 GPU è installato e i log di Ops Agent indicano che Ops Agent sta comunicando con il conducente, ma non ne vedi nessuno Metriche GPU, il problema potrebbe riguardare il grafico che stai utilizzando. Per informazioni sulla risoluzione dei problemi, consulta Il grafico non mostra alcun grafico i tuoi dati.

Se stai raccogliendo alcune metriche GPU, ma non disponi di processes metriche (processes/max_bytes_used e processes/utilization), quindi se non ci sono processi in esecuzione su GPU. Le metriche processes GPU non sono vengono raccolti se non ci sono processi in esecuzione sulla GPU.

Alcune metriche risultano mancanti o incoerenti

Esiste un numero limitato di metriche che la versione di Ops Agent 2.0.0 e versioni successive gestisce in modo diverso rispetto "anteprima" di Ops Agent (versioni inferiori a 2.0.0) o l'agente Monitoring.

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

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

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

Problemi specifici di Windows

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

Contatori delle prestazioni danneggiati su Windows

Se il sub-agente delle metriche non viene avviato, potresti vedere uno dei seguenti messaggi 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 creando nuovamente i contatori delle prestazioni. Nel PowerShell come amministratore, esegui:

cd C:\Windows\system32
lodctr /R

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

Una volta completato 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 ripristinare l'agente a un nuovo stato.

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 self log dell'agente su disco:

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

Rimuovi i buffer locali dell'agente su 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 il parametro i seguenti tipi di file:

File buffer: questi file sono voci di log memorizzate nel buffer che sono state inserite in coda e elaborati da Ops Agent, ma non ancora importati in Cloud Logging. Quando ci sono sono chunk danneggiati, Ops Agent dovrebbe ignorarli nelle versioni >= 2.15.0. Nel in alcuni casi, devono però essere puliti manualmente. Questi file sono archiviati nelle cartelle nidificate come: /var/lib/google-cloud-ops-agent/fluent-bit/buffers/tail.1/*
File di log di tailing position: questi file registrano la posizione in i file di log inseriti da Ops Agent. Se questi file vengono rimossi, Ops Agent inizierà dalla parte superiore dei file che è configurato per inserire. L'eliminazione di questi file può causare la duplicazione di log se questi erano in precedenza sono state importate correttamente. Questi file vengono archiviati direttamente la directory sotto forma di file come: /var/lib/google-cloud-ops-agent/fluent-bit/buffers/default_pipeline_syslog*.

La sintassi .../buffers/*/ nel comando precedente garantisce che vengono 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 self log dell'agente su disco:

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

Rimuovi i buffer locali dell'agente su 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 del buffer

Se la VM non ha blocchi del buffer danneggiati (ovvero, non sono presenti messaggi format check failed nel file di log autonomo di Ops Agent), puoi saltare il i comandi precedenti che rimuovono i buffer locali quando reimposta lo stato dell'agente.

Se la VM ha blocchi del buffer danneggiati, dovrai rimuoverli. La le seguenti opzioni descrivono diversi modi per gestire i buffer. Gli altri passaggi descritti in Reimpostare completamente lo stato dell'agente sono ancora applicabile.

Opzione 1: elimina l'intera directory buffers. È il metodo più ma ciò può causare la perdita dei log presenti nel buffer non danneggiati o duplicazione di log dovuta alla 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 nella sezione Reimpostazione totale lo stato dell'agente.

Opzione 3: se non vuoi eliminare tutti i file del buffer, puoi estrae i nomi dei file di buffer corrotti dai registri auto dell'agente e 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 i file di posizione (in cui vengono archiviati i progressi di Ops Agent per file di log). L'eliminazione del di posizione può causare la duplicazione di tutti i log già importati correttamente. Questa opzione rielabora solo i file di log correnti; questo elemento non rielabora i file già ruotati o i log di altri come una porta TCP. I file di posizione vengono archiviati in buffers ma sono archiviati come file. I buffer locali vengono memorizzati sottodirectory nella directory buffers,

Linux

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

Windows

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

Problemi noti nelle recenti release di Ops Agent

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

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

A partire dalla versione 2.46.0, Ops Agent include il nome della VM come parte dell'etichetta namespace quando importi le metriche in il 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 da con la versione 2.46.0, namespace è impostato su INSTANCE_ID/INSTANCE_NAME.

Se disponi di grafici, dashboard o criteri di avviso che utilizzano l'namespace potrebbe essere necessario aggiornare le query dopo aver eseguito l'upgrade di Ops Agent versione 2.46.0 o successiva. Ad esempio, se il tuo PromQL query simile a: http_requests_total{namespace="123456789"}, è necessario modificalo in http_requests_total{namespace=~"123456789.*"}, poiché L'etichetta namespace è nel formato INSTANCE_ID/INSTANCE_NAME.

Le metriche non digitate di Prometheus cambiano il 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 tipiche vengono trattate come entrambi indicatori e contatori. Gli utenti possono ora utilizzare operazioni cumulative su queste metriche di conseguenza.

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

Utilizza prometheus.googleapis.com/metric_name/unknown per la versione a contatore della metrica.
Utilizza prometheus.googleapis.com/metric_name/unknown:counter per la versione contatore della metrica.

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

Utilizzo elevato di memoria sulle VM Windows (versioni dalla 2.27.0 alla 2.29.0)

Su Windows, nelle versioni da 2.27.0 a 2.29.0 di Ops Agent, un bug che ha causato a volte la perdita di socket comporta un aumento dell'utilizzo della memoria e un handle del processo fluent-bit.exe.

Per limitare il problema, esegui l'upgrade delle operazioni all'agente alla versione 2.30.0 o successive, e riavvia l'agente.

I fusi orari del registro eventi sono errati in Windows (versioni dalla 2.15.0 alla 2.26.0)

I timestamp associati ai log eventi di Windows in Cloud Logging potrebbero essere non è corretto se cambi il fuso orario della VM da UTC. Il problema è stato risolto in Ops Agent 2.27.0, ma a causa del noto problema di Windows con memoria elevata, ti consigliamo di eseguire l'upgrade almeno ad Ops Agent 2.30.0 se esegui in questo problema. Se non riesci a eseguire l'upgrade, puoi provare una delle seguenti soluzioni: soluzioni alternative.

Utilizzare il fuso orario UTC

In PowerShell, esegui i comandi seguenti come amministratore:

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

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

In PowerShell, esegui i comandi seguenti 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 verrà non vengano analizzati correttamente su Windows. Questo problema è stato risolto in Ops Agent 2.27.0, ma al noto problema noto di Windows con memoria elevata, ti consigliamo esegui l'upgrade almeno ad Ops Agent 2.30.0 se ti trovi in questo problema.

Problemi noti nelle release precedenti di Ops Agent

Le sezioni seguenti descrivono i problemi noti che si verificano con la versione precedente di Ops Agent nuove versioni.

Log non dannosi (versioni 2.9.1 e precedenti)

Potresti visualizzare errori durante lo scraping di metriche da pseudo-processi o con restrizioni i processi di machine learning. I seguenti log non sono dannosi e possono essere ignorati tranquillamente. 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 self degli agenti 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 /var/log/google-cloud-ops-agent/subagents/logging-module.log file attivati VM Linux o C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log di file sulle VM Windows a causa di blocchi del buffer danneggiati. In questi casi, vedrai un numero elevato di messaggi come il seguente nel file logging-module.log.

  [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 delle operazioni agente alla versione 2.17.0 o e reimposta completamente lo stato dell'agente.

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