Risolvere i problemi dell'agente Monitoring

Questa pagina ti aiuta a diagnosticare i problemi di installazione o esecuzione dell'agente di monitoraggio.

Elenco di controllo

Se hai difficoltà a installare o utilizzare l'agente Monitoring, ecco alcune cose da controllare:

  • Se i comandi di installazione di Linux restituiscono errori, assicurati di anteporre ai comandi di installazione sudo.

  • Verifica che il servizio agente sia in esecuzione sull'istanza VM:

    • Per una VM Windows, utilizza il seguente comando PowerShell:

      Get-Service -Name StackdriverMonitoring

      Cerca un servizio chiamato Stackdriver Monitoring. Se l'agente non è in esecuzione, potrebbe essere necessario riavviarlo.

    • Per una VM Linux, utilizza il seguente comando:

      sudo service stackdriver-agent status

      Se l'agente non è in esecuzione, potrebbe essere necessario riavviarlo utilizzando il seguente comando:

      sudo service stackdriver-agent restart

      Se il riavvio non va a buon fine e l'output del log mostra "Disabilitato tramite metadati", è probabile che tu stia eseguendo un'immagine di Google Cloud Marketplace, in cui l'agente Monitoring è disabilitato per impostazione predefinita. Questa operazione è controllata dalla chiave dei metadati dell'istanza google-monitoring-enable (con il valore 0). Per riattivare l'agente, rimuovi la chiave o imposta il valore su 1 (vedi Impostazione dei metadati dell'istanza).

      Se l'agente non è disattivato tramite i metadati, reinstallalo. Per informazioni su questa procedura, consulta Reinstallazione dell'agente Monitoring.

  • Controlla se l'agente ha scritto messaggi di errore nei log.

    • Su Windows, l'agente Monitoring scrive i messaggi nel log eventi di Windows.

    • Su Linux, l'agente Monitoring è un pacchetto collectd e registra i messaggi in /var/log/syslog o /var/log/messages. I messaggi di log sono preceduti da collectd o stackdriver-agent:

      • Se visualizzi errori HTTP 429, potresti aver superato le tue quote API di monitoraggio. Puoi visualizzare la quota disponibile selezionando API e servizi > Dashboard nella consoleGoogle Cloud . Scegli l'API Monitoring.

      • Se riscontri problemi con il proxy, verifica di aver configurato correttamente il proxy HTTP. Le istruzioni fanno parte di Installazione su Linux e Windows.

      • Se riscontri problemi di accesso o autorizzazione API o visualizzi messaggi di errore come "Impossibile determinare l'endpoint collectd", consulta la sezione seguente, Verifica del progetto e delle credenziali.

      • Se nei log vengono visualizzati errori "Combinazione di plug-in/tipo collectd non supportata" o "ID collectd non supportato", è possibile che tu stia inviando metriche dell'agente non supportate. Ciò può verificarsi nei seguenti scenari:

        • Hai modificato una delle configurazioni dell'applicazione di terze parti dell'agente. Per ripristinare le modifiche, puoi reinstallare la configurazione per il plug-in specifico seguendo le istruzioni nella pagina della documentazione pertinente. Se vuoi utilizzare l'agente per inviare la metrica a Monitoring, valuta la possibilità di convertirla in metriche definite dall'utente.

        • Uno dei plug-in dell'applicazione di terze parti invia nuove metriche sconosciute a Monitoring. Consulta la pagina di assistenza per informazioni su come inviare una richiesta per far esaminare e categorizzare queste metriche.

  • Se l'agente sembra funzionare normalmente, ma non ricevi dati o i criteri di avviso non funzionano come previsto, devi verificare che l'agente invii i dati al progetto corretto. Consulta la sezione seguente, Verifica del progetto e delle credenziali.

Verifica del progetto e delle credenziali

Se l'agente di monitoraggio segnala errori di accesso o autorizzazione oppure se l'agente sembra funzionare normalmente, ma non sono presenti dati o i criteri di avviso non funzionano come previsto, verifica che le credenziali dell'istanza VM siano corrette, incluso il progetto specificato:

  • Se utilizzi un'istanza VM di Compute Engine con credenziali standard (non con chiave privata), è improbabile che i dati vengano inviati al progetto sbagliato, ma le tue credenziali potrebbero comunque essere insufficienti. Per informazioni sulle credenziali, vedi Autorizzare l'agente Monitoring. Per verificare le tue credenziali, consulta la pagina Verifica delle credenziali di Compute Engine.

  • Se utilizzi un'istanza VM Amazon EC2 o se utilizzi credenziali con chiave privata sull'istanza Compute Engine, le credenziali potrebbero non essere valide o potrebbero provenire dal progetto sbagliato. Per gli account AWS, il progetto utilizzato dall'agente deve essere il progetto Google Cloud a cui invii le metriche. Per informazioni sulle credenziali, vedi Autorizzare l'agente Monitoring. Per verificare le tue credenziali, consulta Verifica delle credenziali con chiave privata.

Se il problema persiste, consulta Reinstallazione dell'agente di monitoraggio.

Verifica delle credenziali di Compute Engine

Utilizza la pagina Istanze VM di Compute Engine della console Google Cloud per verificare che l'istanza VM di Compute Engine disponga di credenziali adeguate per l'agente Monitoring. Le credenziali vengono in genere aggiunte alaccount di serviziot predefinito di tutte le nuove istanze VM di Compute Engine, ma è possibile sovrascrivere questi valori predefiniti durante la creazione di un'istanza.

Nella Google Cloud console, vai alla pagina Istanze VM.

Vai a Istanze VM

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

  1. Se necessario, cambia il progetto Google Cloud corrente in quello associato alla tua istanza VM di Compute Engine. Ad esempio, se ti viene chiesto di attivare la fatturazione, significa che il progetto attuale non contiene istanze VM di Compute Engine.
  2. Nella pagina Istanze VM, fai clic sul nome dell'istanza VM. Viene visualizzata la pagina di dettaglio dell'istanza VM.
  3. Nella pagina Dettagli istanza VM, cerca la sezione Ambiti di accesso all'API Cloud:
    • Se vedi "Consenti l'accesso completo a tutte le API Cloud", significa che hai credenziali adeguate.
    • Se accanto all'API Stackdriver Monitoring vedi un nome precedente per l'API Cloud Monitoring e disponi dell'autorizzazione Solo scrittura o Completa, le credenziali sono adeguate.
    • In caso contrario, l'account di servizio predefinito della tua istanza non dispone delle credenziali necessarie all'agente. Per utilizzare l'agente sull'istanza, devi aggiungere le credenziali dell'account di servizio chiavi privata. Per le istruzioni, vedi Aggiungere le credenziali.

Se hai le credenziali predefinite corrette, vai a Installazione su Linux e Windows.

Verifica delle credenziali della chiave privata

Per verificare che le credenziali della chiave privata valide siano installate sull'istanza VM, verifica innanzitutto che il file delle credenziali esista nella posizione prevista, quindi verifica che le informazioni nel file delle credenziali siano valide. Le credenziali precedentemente valide possono essere revocate utilizzando la sezione IAM e amministrazione > Service account della console Google Cloud . Se non sono presenti credenziali valide, consulta la sezione Aggiunta di credenziali per sostituire quelle esistenti o aggiungerne di nuove.

Sono presenti le credenziali?

Per verificare se le credenziali del account di servizio con chiave privata sono presenti nell'istanza, esegui i seguenti comandi Linux sull'istanza:

sudo cat $GOOGLE_APPLICATION_CREDENTIALS
sudo cat /etc/google/auth/application_default_credentials.json

Se uno dei due comandi mostra un file come quello riportato di seguito, la tua istanza potrebbe avere credenziali di chiave privata valide. Se entrambi i comandi visualizzano un file, viene utilizzato il file indicato da GOOGLE_APPLICATION_CREDENTIALS.

{
  "type": "service_account",
  "project_id": "{your-project-id}",
  "private_key_id": "{your-private-key-id}",
  "private_key": "{your-private-key}",
  "client_email": "{your-project-number}-{your-key}@developer.gserviceaccount.com",
  "client_id": "{your-client-id}",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://accounts.google.com/o/oauth2/token",
  "auth_provider_x509_cert_url": "{x509-cert-url}",
  "client_x509_cert_url": "{client-x509-cert-url}"
}

Se non sono presenti file di credenziali, consulta Aggiunta di credenziali.

Le credenziali sono valide?

Nel file delle credenziali, il campo project_id è il tuo progetto Google Cloud , client_email identifica il account di servizio nel progetto e private_key_id identifica la chiave privata nel account di servizio. Abbina queste informazioni a quelle visualizzate nella sezione IAM e amministrazione > Service account della consoleGoogle Cloud .

Il file delle credenziali non è valido se una delle seguenti condizioni è vera:

  • Stai controllando un'istanza VM di Compute Engine, ma il progettoGoogle Cloud nel file delle credenziali non è il progetto che contiene l'istanza.
  • Stai controllando un'istanza Amazon EC2, ma il progetto Google Cloud nel file delle credenziali non è il progetto Google Cloud a cui stai inviando le metriche dal tuo account AWS.
  • Il account di servizio elencato non esiste. Potrebbe essere stato eliminato.
  • Il account di servizio elencato non dispone dei ruoli corretti attivati. Deve avere almeno roles/monitoring.metricWriter (Monitoring Metric Writer) per la raccolta delle metriche e roles/logging.logWriter (Logs Writer) per la scrittura dei log.
  • La chiave privata non esiste. Potrebbe essere stato revocato.

Se l'account di servizio è corretto, ma la chiave privata è stata revocata, puoi creare una nuova chiave privata e copiarla nell'istanza. In caso contrario, devi creare un nuovo account di servizio come descritto nella sezione successiva, Aggiunta delle credenziali.

Generazione di nuove credenziali

Se le credenziali non sono valide, procedi nel seguente modo:

  1. Per ogni progetto connesso contenente istanze che devono essere autorizzate con una chiave privata, ovvero ogni progetto contenente istanze Compute Engine create senza includere l'ambito di accesso https://www.googleapis.com/auth/monitoring.write, crea un account di servizio e genera una chiave privata, se non esistono già. Segui questi passaggi:

    1. Nella console Google Cloud , vai alla pagina  Impostazioni:

      Vai a Impostazioni

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

    2. Seleziona la scheda Ambito metrica.
    3. Identifica il progetto contenente le risorse Compute Engine in questione e vai alla consoleGoogle Cloud .
    4. Vai alla pagina Account di servizio IAM della console Google Cloud , seleziona il tuo progetto Google Cloud , crea un nuovo service account e poi genera una nuova chiave privata per questo service account.

      Per eseguire questi passaggi, procedi in uno dei seguenti modi:

      • Vai alla pagina Service account IAM, seleziona il tuo progetto Google Cloud e poi segui i passaggi descritti in Creare un service account:

        Vai a Service account IAM

      • Fai clic sul pulsante seguente e seleziona il tuo progetto Google Cloud :

        Crea account di servizio e scarica la chiave

        Il pulsante precedente automatizza il processo di creazione e download di una chiave nel sistema locale per l'account di servizio specifico dell'agente. Se necessario, il processo crea anche il account di servizio richiesto e garantisce che disponga delle autorizzazioni corrette. I service account specifici dell'agente hanno un nome simile a stackdriver-1234@PROJECT_ID.iam.gserviceaccount.com. Riceverai una notifica del completamento di queste azioni con una finestra di dialogo simile alla seguente:

        Un banner che informa l'utente che sono stati creati un account di servizio e una chiave.

  2. Sostituisci la chiave privata sulle istanze corrispondenti al account di serviziot in questione.

    • Su Linux, sostituisci la chiave privata che si trova in /etc/google/auth/application_default_credentials.json.
    • Su Windows, sostituisci la chiave privata che si trova in C:\ProgramData\Google\Auth\application_default_credentials.json. Per saperne di più, vedi Copiare la chiave privata nell'istanza.

  3. Riavvia l'agente

    • Su Linux, esegui sudo service stackdriver-agent restart
    • Su Windows, vai alla console di gestione dei servizi e riavvia il servizio Cloud Monitoring.

Se hai più progetti che richiedono nuove chiavi private, ripeti questa procedura per ciascuno di essi.

Per verificare che la chiave privata sia corretta, consulta Sono presenti le credenziali?. In particolare:

  • Leggi il file JSON della chiave privata sull'istanza, ad esempio (su Linux): sudo cat /etc/google/auth/application_default_credentials.json
  • Assicurati che il valore del campo project_id corrisponda a quello del progetto monitorato per cui hai appena generato le credenziali.

Verifica dei dati dell'agente

Per verificare che l'agente invii correttamente le metriche, utilizza il metodo timeSeries.list dell'API Monitoring per cercare dati recenti delle serie temporali dall'istanza VM. Puoi chiamare il metodo utilizzando Explorer API nella pagina della documentazione del metodo. Se non vedi dati, è possibile che l'agente stia inviando dati al progetto sbagliato. Per verificarlo, consulta Verifica del progetto e delle credenziali.

Ecco le istruzioni dettagliate per l'utilizzo del metodo timeSeries.list:

  1. Determina l'ID istanza dell'istanza VM in cui hai installato l'agente:

    • Istanze Compute Engine: vai alla pagina dei dettagli di Compute Engine per la tua istanza. Nella parte inferiore della pagina, fai clic su REST equivalente. L'ID è un numero di 19 cifre.

    • Istanze Amazon EC2: l'ID di ogni istanza viene visualizzato nell'elenco delle istanze. L'ID è simile a i-1a2b3c4d.

  2. Vai alla pagina della documentazione per il metodo timeSeries.list.

  3. Compila il modulo di Explorer API:

    1. Imposta name sul progetto contenente l'istanza VM, con il prefisso projects/. Ad esempio: projects/[YOUR_PROJECT_ID].

    2. Imposta filter sulla riga seguente per scegliere una metrica dell'agente dall'istanza VM. Copia e incollalo in Explorer API, quindi modifica l'ID istanza VM:

      metric.type = "agent.googleapis.com/memory/bytes_used" AND resource.label.instance_id = "[YOUR-VM-INSTANCE-ID]"

    3. Imposta l'intervallo di tempo della ricerca. Vuoi un intervallo di circa cinque minuti:

      • Imposta interval.endTime sull'ora GMT corrente, che puoi trovare all'indirizzo time.is/GMT. L'ora deve essere formattata come nell'esempio seguente. Non racchiudere l'ora tra virgolette:

        2016-10-31T14:10:00Z

      • Imposta interval.startTime su circa cinque minuti prima dell'ora di fine, utilizzando lo stesso formato.

    4. Lascia vuoti tutti gli altri campi.

  4. Fai clic su Esegui.

Dovresti vedere un output simile al seguente:

{
 "timeSeries": [
  {
   "metric": {
    "labels": {
     "state": "buffered"
    },
    "type": "agent.googleapis.com/memory/bytes_used"
   },
   "resource": {
    "type": "[INSTANCE-TYPE]",
    "labels": {
     "instance_id": "[YOUR-VM-INSTANCE-ID]",
     "zone": "[YOUR-INSTANCE-ZONE]",
     "project_id": "[YOUR-PROJECT-ID]"
    }
   },
   "metricKind": "GAUGE",
   "valueType": "DOUBLE",
   "points": [
    {
     "interval": {
      "startTime": "[START_TIME]",
      "endTime": "[END_TIME]"
     },
     "value": {
      "doubleValue": 27451392
     }
    },
    ...

Se la chiamata API restituisce dati delle serie temporali dalla tua istanza VM, come mostrato sopra, l'agente funziona correttamente e hai terminato.

Se non vedi dati delle serie temporali, controlla quanto segue:

  • Se la chiamata API restituisce un messaggio di errore, non si tratta di un problema dell'agente. Verifica che i campi di Explorer API siano compilati correttamente:

    • Gli errori "Argomento non valido" probabilmente indicano un problema con l'ortografia e il formato dell'ID progetto, del filtro o dei due timestamp.

      I requisiti per gli argomenti del timestamp dipendono dal tipo di metrica specificato. Un tipo di metrica registra dati GAUGE, DELTA o CUMULATIVE. Per saperne di più, consulta MetricKind.

      Per le metriche DELTA e CUMULATIVE, sono necessari sia l'ora di inizio sia l'ora di fine e l'ora di fine deve essere successiva all'ora di inizio. Questi tipi di metriche registrano le variazioni misurate nel tempo, pertanto l'ora di inizio e l'ora di fine devono definire un intervallo diverso da zero.

    • Gli errori "Non autorizzato" possono significare che hai digitato in modo errato l'ID progetto.

    • Gli errori "Non trovato" possono indicare che hai omesso il prefisso projects/ richiesto nel campo "name".

    Risolvi i problemi e riprova a chiamare l'API.

  • Se la chiamata API ha esito positivo, ma visualizzi solo una risposta vuota, { }, controlla che il filtro e l'intervallo di tempo siano corretti. Errori di formattazione dei timestamp possono comportare la mancata restituzione di dati. Se tutto sembra corretto, ma non ricevi dati, significa che l'agente non invia i dati delle metriche o almeno non al progetto che ti aspetti. Questo potrebbe indicare un problema con le credenziali; vedi Verifica delle credenziali della chiave privata.

Reinstallazione dell'agente Monitoring

L'installazione della versione più recente dell'agente può risolvere molti problemi:

Determinare quali VM Linux hanno installato l'agente

  • Esegui una delle seguenti query per vedere quali VM Linux eseguono l'agente:

    Tieni presente che per ogni query devi inserire il nome del progetto e modificare i limiti di tempo.

Riavvio automatico dell'agente

Puoi configurare uno script per verificare se l'agente è in esecuzione e riavviarlo in caso di arresto anomalo.

Ad esempio, su Linux puoi creare la seguente voce crontab per controllare lo stato dell'agente ogni 5 minuti:

  */5 * * * * /bin/pidof stackdriver-collectd >/dev/null 2>&1 || /usr/sbin/service stackdriver-agent restart >/dev/null 2>&1

Problemi noti

Le sezioni seguenti descrivono i problemi noti dell'agente Monitoring.

Problema di accesso ai dati del processo (Windows)

Nel Registro eventi di Windows potrebbe essere visualizzato un messaggio di errore dell'agente simile al seguente:

Read access denied for processes: Registry (84), smss.exe (264), csrss.exe (376), wininit.exe (448), csrss.exe (456), services.exe (580), NisSrv.exe (3008), MsMpEng.exe (3624), csrss.exe (7044)

Questo messaggio indica che l'agente non ha accesso a questi dati sul tuo sistema. Per non visualizzare più questo messaggio, puoi fornire autorizzazioni sufficienti all'utente SYSTEM per leggere i dati di processo per i processi e i servizi elencati nei messaggi di errore. Se non ti servono questi dati, puoi ignorare tranquillamente questi messaggi informativi.

Problemi relativi alla cache dei metadati (Linux)

Potresti visualizzare un messaggio di errore nel file di log di sistema Linux (/var/log/syslog su Debian / Ubuntu o /var/log/messages su Red Hat / CentOS / SLES) simile al seguente:

collectd[25571]: uc_update: Value too old: name = myhost/processes-all/ps_vm;
value time = 1511345468.180; last cache update = 1511345468.180;
write_gcm: wg_update_stats failed.
write_gcm: uc_update returned an error.

Questi messaggi sono avvisi innocui e non indicano una perdita di dati. Questi messaggi vengono generati dall'implementazione del plug-in dei processi attuali quando si verifica una mancata corrispondenza del timestamp.

Problema relativo al punto dati con valore infinito eliminato (Linux)

Potresti visualizzare un messaggio di errore nel file di log di sistema Linux (/var/log/syslog su Debian / Ubuntu o /var/log/messages su Red Hat / CentOS / SLES) simile al seguente:

write_gcm: can not take infinite value

Questo messaggio indica che un singolo punto dati non valido è stato eliminato. Questo di solito è innocuo e può essere ignorato.

Problema di limitazione della chiave dei metadati (Linux)

Potresti visualizzare un messaggio di errore nel file di log di sistema Linux (/var/log/syslog su Debian / Ubuntu o /var/log/messages su Red Hat / CentOS / SLES) simile al seguente:

collectd[7440]:match_throttle_metadata_keys: uc_meta_data_add returned an error
collectd[7440]:match_throttle_metadata_keys: mtg_update_stats failed

Questo messaggio indica che l'aggiornamento dello stato della limitazione della memoria non è riuscito una volta. Normalmente è innocuo, ma potrebbe essere un segnale che l'agente sta esaurendo la memoria, soprattutto se si verifica di frequente.

Problema di esaurimento della quota dell'API Cloud Monitoring (Linux)

Potresti visualizzare un messaggio di errore nel file di log di sistema Linux (/var/log/syslog su Debian / Ubuntu o /var/log/messages su Red Hat / CentOS / SLES) simile al seguente:

collectd[25198]: write_gcm: Unsuccessful HTTP request 429

Questo messaggio indica che è stato raggiunto il limite di quota dell'API Cloud Monitoring. Segui la guida Quota per informazioni sulla gestione del limite di quota.

Utilizzo elevato della memoria dovuto a COLLECTD_INTERVAL basso (Linux)

Potresti notare un utilizzo elevato della memoria dell'agente quando COLLECTD_INTERVAL è configurato in modo che sia più breve di 60 seconds predefinito, ad esempio 10 seconds. Si tratta di una limitazione nota dell'agente perché invia le richieste in serie da un singolo thread. Per risolvere il problema, valuta la possibilità di ridurre il COLLECTD_INTERVAL solo per un sottoinsieme di metriche richieste e lascia il resto delle metriche all'intervallo predefinito.

Problema di overflow del buffer dei token (Linux)

Potresti visualizzare un messaggio di errore nel file di log di sistema Linux (/var/log/syslog su Debian / Ubuntu o /var/log/messages su Red Hat / CentOS / SLES) simile al seguente:

write_gcm: Error or buffer overflow when building auth_header
write_gcm: wg_oauth2_get_auth_header failed.
write_gcm: wg_transmit_unique_segment failed.
write_gcm: wg_transmit_unique_segments failed. Flushing.

Questi messaggi indicano che è necessario eseguire l'upgrade dell'agente di monitoraggio alla versione 6.1.2 o successive.

Il repository ha modificato il valore "Origine" (Linux)

Quando esegui l'upgrade dell'agente, lo installi o esegui apt-get update su Debian/Ubuntu Linux, potresti visualizzare un messaggio di errore simile al seguente:

E: Repository 'https://packages.cloud.google.com/apt google-cloud-monitoring-buster-all InRelease' changed its 'Origin' value from 'google-cloud-monitoring-buster' to 'namespaces/cloud-ops-agents-artifacts/repositories/google-cloud-monitoring-buster-all'
E: Repository 'https://packages.cloud.google.com/apt google-cloud-monitoring-buster-all InRelease' changed its 'Label' value from 'google-cloud-monitoring-buster' to 'namespaces/cloud-ops-agents-artifacts/repositories/google-cloud-monitoring-buster-all'

Questo messaggio indica che la cache del repository dei pacchetti potrebbe essersi discostata dalla sua origine. Per risolvere il problema, esegui questo comando:

apt-get --allow-releaseinfo-change update

Quindi, esegui di nuovo l'upgrade o l'installazione.

Agente rimosso segnalato dalla console Google Cloud come installato

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

L'agente di monitoraggio non viene visualizzato nell'elenco Disinstalla un programma di Windows

Per disinstallare l'agente di monitoraggio quando non è elencato nell'elenco Disinstalla un programma del Pannello di controllo di Windows, esegui uninstall.exe dalla directory in cui l'hai installato.