Risoluzione dei problemi dell'agente operativo

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Nota: l'endpoint localhost:2020/api/v1/metrics menzionato alle 3:18 in questo video non è più disponibile nell'agente Ops. Per altre opzioni, vedi Agente in esecuzione ma i dati non vengono importati.

Questo documento consente di diagnosticare i problemi di installazione o di esecuzione dell'agente operativo.

Strumento di diagnostica degli agenti per le VM

Lo strumento di diagnostica degli agenti raccoglie informazioni critiche per il debug locale dalle VM per tutti i seguenti agenti: agente operativo, agente legacy di logging e agente Monitoring legacy. Le informazioni di debug includono elementi di progetto, informazioni sulla VM, configurazione dell'agente, log dell'agente, stato del servizio dell'agente e informazioni che in genere richiedono un lavoro manuale per essere raccolte. Lo strumento controlla anche l'ambiente VM locale per garantire che soddisfi determinati requisiti per il corretto funzionamento degli agenti, ad esempio la connettività di rete e le autorizzazioni richieste.

Quando invii la richiesta di un cliente per un agente su una VM, esegui lo strumento di diagnostica dell'agente e allega le informazioni raccolte alla richiesta. Prima di allegare le informazioni alla richiesta di assistenza, oscura eventuali informazioni sensibili, come le password. Queste informazioni riducono il tempo necessario per risolvere i problemi della tua richiesta di assistenza.

Lo strumento di diagnostica degli agenti deve essere eseguito dall'interno della VM, pertanto devi prima connetterti a SSH nella VM. Il comando seguente recupera lo strumento di diagnostica dell'agente ed lo esegue:

Linux

curl -sSO https://dl.google.com/cloudagents/diagnose-agents.sh
sudo bash diagnose-agents.sh

Windows

(New-Object Net.WebClient).DownloadFile("https://dl.google.com/cloudagents/diagnose-agents.ps1", "${env:UserProfile}\diagnose-agents.ps1")
Invoke-Expression "${env:UserProfile}\diagnose-agents.ps1"

Segui l'output dell'esecuzione dello script per individuare i file che includono le informazioni raccolte. In genere puoi trovarli nella directory /var/tmp/google-agents su Linux e nella directory $env:LOCALAPPDATA/Temp su Windows, a meno che tu non abbia personalizzato la directory di output durante l'esecuzione dello script.

Per informazioni dettagliate, esamina lo script diagnose-agents.sh su Linux o lo script diagnose-agents.ps1 su Windows.

Impossibile installare l'agente

Potresti riscontrare i seguenti errori durante l'esecuzione dello script di installazione.

  • Il sistema operativo non è supportato. Il messaggio di errore potrebbe essere simile al seguente:

    Linux

    https://packages.cloud.google.com/yum/repos/google-cloud-ops-agent-el6-x86_64-all/repodata/repomd.xml: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found"
    Trying other mirror.
    To address this issue please refer to the below wiki article
    
    https://wiki.centos.org/yum-errors
    
    If above article doesn't help to resolve this issue please use https://bugs.centos.org/.
    
    Error: Cannot retrieve repository metadata (repomd.xml) for repository: google-cloud-ops-agent. Please verify its path and try again
    
  • Nella VM è già installato l'agente Cloud Logging o l'agente Cloud Monitoring e sono in conflitto con il nuovo agente. Il messaggio di errore potrebbe essere simile al seguente:

    Linux

    Error:
    Problem: problem with installed package stackdriver-agent-6.0.5-1.el8.x86_64 - package google-cloud-ops-agent-0.1.0-1.el8.x86_64 conflicts with stackdriver-agent provided by stackdriver-agent-6.0.5-1.el8.x86_64
    

    L'agente operativo utilizza nuovi file di configurazione non compatibili con i vecchi agenti. Per ulteriori informazioni, consulta la guida Configura l'agente operativo.

    Per correggere questo errore:

    1. Salva i file di configurazione personalizzati per l'agente Cloud Monitoring e l'agente Cloud Logging.

    2. Disinstalla i vecchi agente Cloud Monitoring e agente Cloud Logging.

      Dopo che hai disinstallato l'agente, la console di Google Cloud potrebbe impiegare fino a un'ora per segnalare questa modifica.

L'agente è installato ma non in esecuzione

Servizi agente non in esecuzione

Quando il servizio agente è in esecuzione come previsto, potresti visualizzare il seguente stato:

Per Linux

computer@debian9:~$ sudo systemctl status google-cloud-ops-agent"*"
● google-cloud-ops-agent.service - Google Cloud Ops Agent
   Loaded: loaded (/lib/systemd/system/google-cloud-ops-agent.service; enabled; vendor preset: enabled)
   Active: active (exited) since Thu 2021-08-05 20:33:44 UTC; 7s ago
  Process: 2240 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
  Process: 2214 ExecStartPre=/opt/google-cloud-ops-agent/libexec/google_cloud_ops_agent_engine -in /etc/google-cloud-ops-agent/config.yaml (code=exited, status=0/SUCCESS)
 Main PID: 2240 (code=exited, status=0/SUCCESS)
    Tasks: 0 (limit: 4915)
   CGroup: /system.slice/google-cloud-ops-agent.service

Aug 05 20:33:44 debian9 systemd[1]: Starting Google Cloud Ops Agent...
Aug 05 20:33:44 debian9 systemd[1]: Started Google Cloud Ops Agent.

● google-cloud-ops-agent-fluent-bit.service - Google Cloud Ops Agent - Logging Agent
   Loaded: loaded (/lib/systemd/system/google-cloud-ops-agent-fluent-bit.service; static; vendor preset: enabled)
  Drop-In: /lib/systemd/system/google-cloud-ops-agent-fluent-bit.service.d
           └─directories.conf
   Active: active (running) since Thu 2021-08-05 20:33:44 UTC; 7s ago
  Process: 2234 ExecStartPre=/bin/mkdir -p ${RUNTIME_DIRECTORY} ${STATE_DIRECTORY} ${LOGS_DIRECTORY} (code=exited, status=0/SUCCESS)
  Process: 2216 ExecStartPre=/opt/google-cloud-ops-agent/libexec/google_cloud_ops_agent_engine -service=fluentbit -in /etc/google-cloud-ops-agent/config.yaml -logs ${LOGS_DIRECTORY} -state ${STATE_DIRECTORY} (code=exited, status=0/SUCCESS)
 Main PID: 2247 (fluent-bit)
    Tasks: 22 (limit: 4915)
   CGroup: /system.slice/google-cloud-ops-agent-fluent-bit.service
           └─2247 /opt/google-cloud-ops-agent/subagents/fluent-bit/bin/fluent-bit --config /run/google-cloud-ops-agent-fluent-bit/fluent_bit_main.conf --parser /run/google-cloud-ops-agent-fluent-bit/fluent_bit_parser.conf --log_file /var/log/google-cloud-ops-agent/subagents/logging-module.log --storage_path /var/lib/google-cloud-ops-agent/fluent-bit/buffers

Aug 05 20:33:44 debian9 systemd[1]: Starting Google Cloud Ops Agent - Logging Agent...
Aug 05 20:33:44 debian9 systemd[1]: Started Google Cloud Ops Agent - Logging Agent.
Aug 05 20:33:44 debian9 fluent-bit[2247]: Fluent Bit v1.7.8
Aug 05 20:33:44 debian9 fluent-bit[2247]: * Copyright (C) 2019-2021 The Fluent Bit Authors
Aug 05 20:33:44 debian9 fluent-bit[2247]: * Copyright (C) 2015-2018 Treasure Data
Aug 05 20:33:44 debian9 fluent-bit[2247]: * Fluent Bit is a CNCF sub-project under the umbrella of Fluentd
Aug 05 20:33:44 debian9 fluent-bit[2247]: * https://fluentbit.io

● google-cloud-ops-agent-opentelemetry-collector.service - Google Cloud Ops Agent - Metrics Agent
   Loaded: loaded (/lib/systemd/system/google-cloud-ops-agent-opentelemetry-collector.service; static; vendor preset: enabled)
  Drop-In: /lib/systemd/system/google-cloud-ops-agent-opentelemetry-collector.service.d
           └─directories.conf
   Active: active (running) since Thu 2021-08-05 20:33:44 UTC; 7s ago
  Process: 2237 ExecStartPre=/bin/mkdir -p ${RUNTIME_DIRECTORY} ${STATE_DIRECTORY} ${LOGS_DIRECTORY} (code=exited, status=0/SUCCESS)
  Process: 2215 ExecStartPre=/opt/google-cloud-ops-agent/libexec/google_cloud_ops_agent_engine -service=otel -in /etc/google-cloud-ops-agent/config.yaml -logs ${LOGS_DIRECTORY} (code=exited, status=0/SUCCESS)
 Main PID: 2251 (otelopscol)
    Tasks: 6 (limit: 4915)
   CGroup: /system.slice/google-cloud-ops-agent-opentelemetry-collector.service
           └─2251 /opt/google-cloud-ops-agent/subagents/opentelemetry-collector/otelopscol --add-instance-id=false --config=/run/google-cloud-ops-agent-opentelemetry-collector/otel.yaml

Aug 05 20:33:45 debian9 otelopscol[2251]: 2021-08-05T20:33:45.234Z        info        builder/pipelines_builder.go:51        Pipeline is starting...        {"pipeline_name": "metrics/system", "pipeline_datatype": "metrics"}
Aug 05 20:33:45 debian9 otelopscol[2251]: 2021-08-05T20:33:45.234Z        info        builder/pipelines_builder.go:62        Pipeline is started.        {"pipeline_name": "metrics/system", "pipeline_datatype": "metrics"}
Aug 05 20:33:45 debian9 otelopscol[2251]: 2021-08-05T20:33:45.234Z        info        service/service.go:192        Starting receivers...
Aug 05 20:33:45 debian9 otelopscol[2251]: 2021-08-05T20:33:45.235Z        info        builder/receivers_builder.go:70        Receiver is starting...        {"kind": "receiver", "name": "hostmetrics/hostmetrics"}
Aug 05 20:33:45 debian9 otelopscol[2251]: 2021-08-05T20:33:45.235Z        info        builder/receivers_builder.go:75        Receiver started.        {"kind": "receiver", "name": "hostmetrics/hostmetrics"}
Aug 05 20:33:45 debian9 otelopscol[2251]: 2021-08-05T20:33:45.236Z        info        builder/receivers_builder.go:70        Receiver is starting...        {"kind": "receiver", "name": "prometheus/agent"}
Aug 05 20:33:45 debian9 otelopscol[2251]: 2021-08-05T20:33:45.236Z        info        discovery/manager.go:195        Starting provider        {"kind": "receiver", "name": "prometheus/agent", "level": "debug", "provider": "static/0", "subs": "[otel-collector]"}
Aug 05 20:33:45 debian9 otelopscol[2251]: 2021-08-05T20:33:45.236Z        info        builder/receivers_builder.go:75        Receiver started.        {"kind": "receiver", "name": "prometheus/agent"}
Aug 05 20:33:45 debian9 otelopscol[2251]: 2021-08-05T20:33:45.236Z        info        service/collector.go:182        Everything is ready. Begin running and processing data.
Aug 05 20:33:45 debian9 otelopscol[2251]: 2021-08-05T20:33:45.256Z        info        discovery/manager.go:213        Discoverer channel closed        {"kind": "receiver", "name": "prometheus/agent", "level": "debug", "provider": "static/0"}

Per Windows

Get-Service google-cloud-ops-agent*

Status   Name               DisplayName
------   ----               -----------
Running  google-cloud-op... Google Cloud Ops Agent
Running  google-cloud-op... Google Cloud Ops Agent - Logging Agent
Running  google-cloud-op... Google Cloud Ops Agent - Metrics Agent

Se il servizio agente non è in esecuzione, potresti visualizzare il seguente stato:

Linux

$ sudo service google-cloud-ops-agent status
● google-cloud-ops-agent.service - Google Cloud Ops Agent
   Loaded: loaded (/lib/systemd/system/google-cloud-ops-agent.service; enabled; vendor preset: enabled)
   Active: inactive (dead) since Wed 2021-06-30 21:20:43 UTC; 6s ago

Windows

Get-Service google-cloud-ops-agent

Status   Name                    DisplayName
------   ----                    -----------
Stopped  google-cloud-ops-agent  Google Cloud Ops Agent

Per correggere questo errore, esegui il comando seguente per avviare il servizio:

Linux

sudo service google-cloud-ops-agent start

Windows

Start-Service google-cloud-ops-agent

Se il servizio non si avvia, la configurazione potrebbe non essere valida.

Conflitto con gli agenti attualmente installati

  • Nella VM è già installato l'agente Cloud Logging o l'agente Cloud Monitoring e la sua configurazione è in conflitto con la configurazione del nuovo agente. Il messaggio di errore potrebbe essere simile al seguente:

    Windows

    We detected an existing Windows service for the StackdriverLogging agent,
    which is not compatible with the Ops Agent when the Ops Agent configuration
    has a non-empty logging section. Please either remove the logging section
    from the Ops Agent configuration, or disable the StackdriverLogging agent,
    and then retry enabling the Ops Agent.
    

    Per correggere questo errore, puoi procedere in due modi:

    1. Disabilita la sezione in conflitto del file di configurazione dell'agente Ops. Per ulteriori informazioni, consulta la guida Configura l'agente operativo.

    2. Disabilita l'agente Cloud Logging in conflitto o l'agente Cloud Monitoring.

      1. Salva i file di configurazione personalizzati per l'agente Cloud Logging.
      2. Disinstalla i vecchi agente Cloud Monitoring e agente Cloud Logging.

      Dopo che hai disinstallato l'agente, la console di Google Cloud potrebbe impiegare fino a un'ora per segnalare questa modifica.

Configurazione non valida

Se la configurazione non è valida, potrebbe essere visualizzato il seguente errore durante il tentativo di riavviare il servizio di agenti:

Linux

$ sudo service google-cloud-ops-agent restart \
    && sudo service google-cloud-ops-agent status
● google-cloud-ops-agent-fluent-bit.service - Google Cloud Ops Agent - Logging Agent
   Loaded: loaded (/usr/lib/systemd/system/google-cloud-ops-agent-fluent-bit.service; static; vendor preset: disabled)
  Drop-In: /usr/lib/systemd/system/google-cloud-ops-agent-fluent-bit.service.d
           └─directories.conf
   Active: failed (Result: exit-code) since Wed 2021-06-30 22:21:08 UTC; 2s ago
  Process: 1141421 ExecStart=/opt/google-cloud-ops-agent/subagents/fluent-bit/bin/fluent-bit --config ${RUNTIME_DIRECTORY}/fluent_bit_main.conf --parser ${RUNTIME_DIRECTORY}/fluent_bit_parser.conf --log_>
  Process: 1141847 ExecStartPre=/opt/google-cloud-ops-agent/libexec/google_cloud_ops_agent_engine -service=fluentbit -in /etc/google-cloud-ops-agent/config.yaml -logs ${LOGS_DIRECTORY} -state ${STATE_DIR>
 Main PID: 1141421 (code=exited, status=0/SUCCESS)

Jun 30 22:21:08 centos8-2 systemd[1]: google-cloud-ops-agent-fluent-bit.service: Control process exited, code=exited status=1
Jun 30 22:21:08 centos8-2 systemd[1]: google-cloud-ops-agent-fluent-bit.service: Failed with result 'exit-code'.
Jun 30 22:21:08 centos8-2 systemd[1]: Failed to start Google Cloud Ops Agent - Logging Agent.
Jun 30 22:21:08 centos8-2 systemd[1]: google-cloud-ops-agent-fluent-bit.service: Service RestartSec=100ms expired, scheduling restart.
Jun 30 22:21:08 centos8-2 systemd[1]: google-cloud-ops-agent-fluent-bit.service: Scheduled restart job, restart counter is at 5.
Jun 30 22:21:08 centos8-2 systemd[1]: Stopped Google Cloud Ops Agent - Logging Agent.
Jun 30 22:21:08 centos8-2 systemd[1]: google-cloud-ops-agent-fluent-bit.service: Start request repeated too quickly.
Jun 30 22:21:08 centos8-2 systemd[1]: google-cloud-ops-agent-fluent-bit.service: Failed with result 'exit-code'.
Jun 30 22:21:08 centos8-2 systemd[1]: Failed to start Google Cloud Ops Agent - Logging Agent.

Utilizza journalctl per visualizzare esattamente il messaggio di errore:

sudo journalctl -xe | grep "google_cloud_ops_agent_engine"

Potresti vedere un messaggio simile al seguente:

Jun 30 22:00:26 centos8-2 google_cloud_ops_agent_engine[1141491]: 2021/06/30 22:00:26 the agent config file is not valid YAML. detailed error: yaml: line 21: did not find expected key

Windows

failed to generate config files: can't parse configuration: yaml: line 20: could not find expected ':'

Per correggere l'errore, correggi la configurazione non valida e riavvia l'agente. Come riferimento, consulta la guida Configurare l'agente Ops.

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

Usa Metrics Explorer per eseguire la 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 alla metrica.

  1. Nella console Google Cloud, seleziona Monitoring o fai clic sul seguente pulsante:

    Vai a Monitoring

  2. Nel riquadro di navigazione, seleziona Metrics Explorer.

  3. Seleziona la scheda MQL.

  4. Inserisci la query seguente, quindi 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?

Controllare le metriche locali

Questi passaggi richiedono l'uso di SSH nella VM.

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

Linux

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

Windows

Apri Windows PowerShell come amministratore ed esegui:

Get-Service google-cloud-ops-agent

Puoi anche controllare lo stato del servizio nell'app Servizi e controllare i processi in esecuzione nell'app Gestione attività.

Controlla il log del modulo di logging

Questo passaggio richiede l'uso di SSH nella VM.

Puoi trovare i log del modulo di logging all'indirizzo /var/log/google-cloud-ops-agent/subagents/*.log per Linux e C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log per Windows. Se non sono presenti log, il servizio agente non è in esecuzione in modo corretto. Vai alla sezione L'agente è installato ma non in esecuzione per risolvere 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 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 account di servizio o credenziali specificate. Per informazioni sulla risoluzione di questo problema, consulta Autorizzare l'agente operativo.

L'agente invia le metriche a Cloud Monitoring?

Controllare il log del modulo delle metriche

Questo passaggio richiede l'uso di SSH nella VM.

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

  • Potresti notare PermissionDenied errori durante la scrittura nell'API Monitoring. Questo errore si verifica se l'autorizzazione dell'agente Ops 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 Writer metrica.

  • Potresti notare ResourceExhausted errori durante la scrittura nell'API Monitoring. Questo errore si verifica se il progetto raggiunge il limite per qualsiasi quota 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 account di servizio o credenziali specificate. Per informazioni sulla risoluzione di questo problema, consulta Autorizzare l'agente operativo.

Ispeziona log automatici dell'agente

Se l'agente non riesce a importare i log in Cloud Logging, potresti dover ispezionarli a livello locale sulla VM per risolvere il problema.

Linux

Per controllare gli autolog scritti in Journald, esegui il comando seguente:

journalctl -u google-cloud-ops-agent*

Per controllare gli autolog scritti sul disco dal modulo di logging, esegui il comando seguente:

vim /var/log/google-cloud-ops-agent/subagents/logging-module.log

Windows

Per controllare gli autolog scritti in Windows Event Logs, esegui questo comando:

Get-WinEvent -FilterHashtable @{ Logname='Application'; ProviderName='google-cloud-ops-agent*' } | Format-Table -AutoSize -Wrap

Per controllare gli autolog scritti sul disco dal modulo di logging, esegui il comando seguente:

notepad "C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log"

Per esaminare i log dal servizio Windows Service Control Manager per gli agenti operativi, esegui il comando seguente:

Get-WinEvent -FilterHashtable @{ Logname='System'; ProviderName='Service Control Manager' } | Where-Object -Property Message -Match 'Google Cloud Ops Agent' | Format-Table -AutoSize -Wrap

Configura la rotazione dei file di log self-service sulle VM Linux

Per limitare le dimensioni del log dell'agente secondario di logging a /var/log/google-cloud-ops-agent/subagents/logging-module.log, installa e configura l'utilità logrotate.

  1. Installa l'utilità logrotate eseguendo questo comando:

    Su Debian e Ubuntu

    sudo apt install logrotate
    

    Su CentOS, RHEL e Fedora

    sudo yum install logrotate
    
  2. Crea un file di configurazione logrotate all'indirizzo /etc/logrotate.d/google-cloud-ops-agent.conf.

    sudo tee /etc/logrotate.d/google-cloud-ops-agent.conf > /dev/null << EOF
    # logrotate config to rotate Google Cloud Ops Agent self log file.
    # See https://manpages.debian.org/jessie/logrotate/logrotate.8.en.html for
    # the full options.
    /var/log/google-cloud-ops-agent/subagents/logging-module.log
    {
        # Log files are rotated every day.
        daily
        # Log files are rotated this many times before being removed. This
        # effectively limits the disk space used by the Ops Agent self log files.
        rotate 30
        # Log files are rotated when they grow bigger than maxsize even before the
        # additionally specified time interval
        maxsize 256M
        # Skip rotation if the log file is missing.
        missingok
        # Do not rotate the log if it is empty.
        notifempty
        # Old versions of log files are compressed with gzip by default.
        compress
        # Postpone compression of the previous log file to the next rotation
        # cycle.
        delaycompress
    }
    EOF
    
  3. Configura crontab o systemd timer per attivare periodicamente l'utilità logrotate.

Una volta applicata la rotazione dei log, vedrai i file ruotati nella directory /var/log/google-cloud-ops-agent/subagents/. I risultati hanno un aspetto simile al seguente:

/var/log/google-cloud-ops-agent/subagents$ ls -lh
total 24K
-rw-r--r-- 1 root root  717 Sep  3 19:54 logging-module.log
-rw-r--r-- 1 root root 6.8K Sep  3 19:51 logging-module.log.1
-rw-r--r-- 1 root root  874 Sep  3 19:50 logging-module.log.2.gz
-rw-r--r-- 1 root root  873 Sep  3 19:50 logging-module.log.3.gz
-rw-r--r-- 1 root root 3.2K Sep  3 19:34 logging-module.log.4.gz

Per testare la rotazione dei log:

  1. Riduci temporaneamente le dimensioni del file a cui viene attivata la rotazione impostando il valore maxsize su 1k nel file /etc/logrotate.d/google-cloud-ops-agent.conf.

  2. Fai in modo che il file di log self-service dell'agente abbia dimensioni superiori a 1K riavviando l'agente alcune volte:

    sudo service google-cloud-ops-agent restart
    
  3. Attendi che l'oggetto crontab o systemd timer abbia effetto per attivare l'utilità logrotate oppure attiva manualmente l'utilità logrotate eseguendo questo comando:

    sudo logrotate /etc/logrotate.d/google-cloud-ops-agent.conf
    
  4. Verifica che i file di log ruotati siano elencati nella directory /var/log/google-cloud-ops-agent/subagents/.

  5. Reimposta la configurazione della rotazione dei log ripristinando il valore maxsize originale.

Reimposta completamente lo stato dell'agente

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

Linux

Interrompi il servizio 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 self-service dell'agente su disco:

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

Rimuovi i buffer locali dell'agente sul disco:

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

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

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

Rimuovi i buffer locali dell'agente sul disco:

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

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 (ossia, non ci sono messaggi format check failed nel file di log self-service dell'agente Ops), puoi ignorare i comandi precedenti che eliminano i buffer locali quando reimposta lo stato dell'agente.

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

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

    Linux

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

    Windows

    rmdir -R -ErrorAction SilentlyContinue "C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers";
    
  • Opzione 2: elimina le sottodirectory del buffer dalla directory buffers, ma lascia i file di posizione. Questo approccio è descritto in Reimpostare completamente lo stato dell'agente.

  • Opzione 3: se non vuoi eliminare tutti i file di buffer, puoi estrarre i nomi dei file di buffer danneggiati dai log di buffer dell'agente ed 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 ci sono 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 sono archiviati l'avanzamento dell'agente operativo per ogni file di log. L'eliminazione dei file di posizione può comportare la duplicazione di tutti i log già importati. Questa opzione rielabora solo i file di log correnti; non rielabora i file già sottoposti a rotazione o i log di altre origini, come una porta TCP. I file di posizione vengono memorizzati nella directory buffers, ma sono archiviati come file. I buffer locali sono 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

La seguente sezione contiene i problemi comuni noti. Per quelle che sono già corrette o limitate, segui le istruzioni specifiche per scegliere la correzione.

Log non dannosi

  • Errori di scraping delle metriche da pseudo-processi o processi limitati

    I seguenti log non sono dannosi e possono essere ignorati in sicurezza. Per eliminarli, esegui l'upgrade dell'agente operativo 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
    
  • Errori quando il primo punto dati delle metriche cumulative viene eliminato:

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

Alcune metriche risultano mancanti o incoerenti

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

La tabella seguente descrive le differenze nei dati importati dall'agente Ops e dall'agente Monitoring.
Tipo di metrica, ometti
agent.googleapis.com
Agente operativo (GA) Agente Ops (anteprima) Agente Monitoring
disk/bytes_used e
disk/percent_used
Importazione con il percorso completo nell'etichetta device, ad esempio /dev/sda15.

Non importati per dispositivi virtuali come tmpfs e udev.
Importazione senza /dev nel percorso nell'etichetta device, ad esempio sda15.

Importazione per i dispositivi virtuali come tmpfs e udev.
Importazione senza /dev nel percorso nell'etichetta device, ad esempio sda15.

Importazione per i dispositivi virtuali come tmpfs e udev.
La colonna GA si riferisce all'agente operativo versione 2.0.0 e successive. La colonna Anteprima si riferisce alle versioni dell'agente operativo precedenti alla 2.0.0.

Agente rimosso segnalato da Google Cloud Console come installato

Dopo che hai disinstallato l'agente, la console di Google Cloud potrebbe impiegare fino a un'ora per segnalare questa modifica.

I log self-service dell'agente consumano troppa CPU, memoria e spazio su disco

Le versioni precedenti dell'agente Ops potrebbero consumare molto CPU, memoria e spazio su disco con file /var/log/google-cloud-ops-agent/subagents/logging-module.log sulle VM Linux o file C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log sulle VM Windows a causa di blocchi di buffer danneggiati. In questi casi, vedrai un numero elevato di messaggi, come quelli indicati di seguito, 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 dell'agente Ops alla versione 2.17 o successiva e reimposta completamente lo stato dell'agente.

Contatori delle prestazioni danneggiati su Windows

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

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

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

cd C:\Windows\system32
lodctr /R

A volte il comando precedente può non riuscire; in questo caso ricarica PowerShell e riprova fino a che l'operazione non riesce.

Una volta che il comando ha esito positivo, riavvia l'agente Ops:

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

I timestamp del log eventi non sono corretti su Windows

I timestamp associati ai log eventi di Windows in Cloud Logging potrebbero non essere corretti, a seconda delle impostazioni del fuso orario del sistema. Se noti questo problema, puoi provare una delle seguenti soluzioni alternative.

Utilizzare un 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

Ignora l'impostazione del fuso orario solo per il servizio di agente secondario 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