Risolvere i problemi dell'agente Monitoring

Questa pagina ti aiuta a diagnosticare i problemi di installazione o esecuzione del Agente di monitoraggio.

Elenco di controllo

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

  • Se i comandi di installazione di Linux restituiscono errori, assicurati di aggiungi sudo come prefisso ai comandi di installazione.

  • Verifica che il servizio dell'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 comando seguente:

      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 riesce e l'output di log mostra "Disabilitato tramite metadati", è probabile che tu stia eseguendo un'immagine Google Cloud Marketplace, in cui l'agente Monitoring è disabilitato per impostazione predefinita. Questo valore è controllato 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 Impostare i 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 Registro eventi di Windows.

    • Su Linux, l'agente di monitoraggio è 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 Quote API di monitoraggio. Puoi visualizzare la quota disponibile selezionando API e servizi > Dashboard nella console Google Cloud. Scegli l'API Monitoring.

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

      • Se visualizzi problemi di accesso o autorizzazione all'API oppure messaggi di errore ad esempio "Impossibile determinare l'endpoint raccolto", consulta Verifica del progetto e delle credenziali.

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

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

        • Uno dei plug-in delle applicazioni di terze parti sta inviando nuovi sconosciute a Monitoring. Per informazioni dettagliate su come inviare una richiesta per la revisione e la classificazione di queste metriche, consulta la pagina di assistenza.

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

Verifica del progetto e delle credenziali

Se l'agente Monitoring segnala errori di accesso o di autorizzazione oppure se che l'agente sembra funzionare normalmente, ma non ci sono dati o è stato visualizzato che non funzionano come previsto, quindi verifica che la classe di archiviazione credenziali siano corrette e che specifichino il progetto corretto:

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

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

Se il problema persiste, consulta Reinstallare l'agente di monitoraggio.

Verifica delle credenziali di Compute Engine

Utilizza la pagina Istanze VM di Compute Engine della console Google Cloud per verifica che l'istanza VM di Compute Engine abbia credenziali adeguate per l'agente Monitoring. In genere le credenziali vengono aggiunte l'account di servizio predefinito per tutte le nuove istanze VM di Compute Engine, di sovrascrivere i valori predefiniti durante la creazione di un'istanza.

Nella console Google Cloud, 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, modifica il progetto Google Cloud attuale in modo che sia quello associato con la tua istanza VM di Compute Engine. Ad esempio, se dopo aver visualizzato Abilita la fatturazione, significa che il progetto attuale delle istanze VM di Compute Engine.
  2. Nella pagina Istanze VM, fai clic sul nome dell'istanza VM. Il dettaglio per la tua istanza VM.
  3. Nella pagina Dettagli istanza VM, guarda sotto Accesso all'API Cloud intestazione ambiti:
    • Se vedi "Consenti l'accesso completo a tutte le API Cloud", significa che disponi delle credenziali adeguate.
    • Se accanto a API Stackdriver Monitoring è visualizzato un nome precedente dell'API Cloud Monitoring e disponi dell'autorizzazione Scrittura solo o Completa, significa che disponi delle credenziali adeguate.
    • In caso contrario, l'account di servizio predefinito della tua istanza non include e le credenziali richieste dall'agente. Per utilizzare l'agente nell'istanza, devi aggiungere le credenziali dell'account di servizio con chiave privata. Per le istruzioni, consulta Aggiungere le credenziali.

Se disponi delle credenziali predefinite corrette, vai a Installazione su Linux e Windows.

Verifica delle credenziali della chiave privata in corso...

Per verificare che le credenziali con chiave privata valide siano installate nell'istanza VM, innanzitutto verifica che il file delle credenziali esista nella posizione prevista e poi verifica che le informazioni nel file delle credenziali siano valide. Valide in precedenza le credenziali possono essere revocate utilizzando IAM e Amministratore > Sezione Account di servizio della console Google Cloud. Se non sono presenti credenziali valide, consulta Aggiunta delle credenziali per sostituire le credenziali esistenti o per aggiungerne di nuove.

Le credenziali sono presenti?

Per verificare se le credenziali dell'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 visualizza un file come quello mostrato di seguito, la tua istanza potrebbe avere credenziali chiave privata valide. Se entrambi i comandi mostrano 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, vedi Aggiunta di credenziali.

Le credenziali sono valide?

Nel file delle credenziali, il campo project_id corrisponde al tuo progetto Google Cloud, client_email identifica l'account di servizio nel progetto, e private_key_id identifica la chiave privata nell'account di servizio. Confrontale con quelle riportate nella sezione IAM e amministrazione > Account di servizio della console Google Cloud.

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

  • Stai controllando un'istanza VM Compute Engine, ma il progetto Google Cloud nel file delle credenziali non è il progetto che contiene l'istanza.
  • Stai controllando un'istanza Amazon EC2, ma il progetto Google Cloud il file delle credenziali non è il progetto Google Cloud a cui stai inviando le metriche dal tuo account AWS.
  • L'account di servizio elencato non esiste. Potrebbe essere stato eliminato.
  • Per l'account di servizio in elenco non sono abilitati i ruoli corretti. 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 nella tua istanza. In caso contrario, devi creare un nuovo account di servizio come descritto nella sezione seguente, Aggiunta delle credenziali.

Generazione delle nuove credenziali in corso...

Se le credenziali non sono valide:

  1. Per ogni progetto collegato contenente istanze che devono essere autorizzate con una chiave privata, ovvero ogni progetto contenente istanze Compute Engine create senza includere l'ambito di accessohttps://www.googleapis.com/auth/monitoring.write, crea un account di servizio e genera una chiave privata, se non esistono già. Procedi nel seguente modo:

    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 che contiene le risorse Compute Engine in questione e accedi alla Console Google Cloud.
    4. Vai alla pagina Account di servizio IAM della console Google Cloud, seleziona il tuo progetto Google Cloud, crea un nuovo account di servizio e poi genera una nuova chiave privata per quell'account di servizio.

      Per farlo, procedi in uno dei seguenti modi:

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

        Vai ad Account di servizio IAM

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

        Creare l'account di servizio e scaricare la chiave

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

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

  2. Sostituisci la chiave privata nelle istanze che corrispondono dell'account di servizio in questione.

    • Su Linux, sostituisci la chiave privata situata in /etc/google/auth/application_default_credentials.json.
    • Su Windows, sostituisci la chiave privata in C:\ProgramData\Google\Auth\application_default_credentials.json. Per ulteriori informazioni, consulta 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 del servizio 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 Le credenziali sono presenti?. In particolare:

  • Leggi il file JSON della chiave privata nell'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 per il quale hai appena generato le credenziali.

Verifica dei dati dell'agente in corso...

Per verificare che l'agente invii correttamente le metriche, utilizza il metodo timeSeries.list dell'API Monitoring per cercare l'ora recente i dati della serie dall'istanza VM. Puoi chiamare il metodo utilizzando Explorer API nella pagina della documentazione del metodo. In caso contrario vedere i dati, è possibile che l'agente stia inviando dati al progetto sbagliato. Per verificarlo, consulta Verificare il progetto e le 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 Equivalente REST. L'ID è un numero di 19 cifre.

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

  2. Vai alla pagina della documentazione relativa al metodo timeSeries.list.

  3. Compila il modulo di Explorer API:

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

    2. Imposta filter sulla riga seguente per scegliere una metrica dell'agente dalla tua istanza VM. Copia e incollalo in Esplora 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 di ricerca. Ti consigliamo di lasciare un intervallo di circa cinque minuti:

      • Imposta interval.endTime sull'ora GMT corrente, che puoi trovare su time.is/GMT. L'ora deve essere formattata come nell'esempio seguente. Non includere il tag 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 Execute (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 di serie temporali dalla tua istanza VM, come mostrato sopra, significa che l'agente funziona correttamente e tu hai finito.

Se non vedi dati per le serie temporali, controlla quanto segue:

  • Se la chiamata API genera un messaggio di errore, non indica un problema con l'agente. Verifica che i campi di Explorer API siano compilati correttamente:

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

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

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

    • "Non autorizzata" possono significare che l'ID progetto non è stato digitato correttamente.

    • Gli errori "Non trovato" possono indicare che hai omesso il prefisso obbligatorioprojects/ nel campo "nome".

    Risolvi i problemi e riprova a eseguire la chiamata all'API.

  • Se la chiamata all'API va a buon fine, ma visualizzi solo una risposta vuota, { }, controlla che il filtro e l'intervallo di tempo siano corretti. Errori di formattazione i timestamp possono comportare la mancata restituzione di dati. Se tutto ti sembra è corretto ma non ricevi dati, significa che l'agente non invia la metrica o almeno non al progetto che ti aspetti. Questo potrebbe indicare un problema di credenziali; consulta Verifica delle credenziali della chiave privata.

Reinstallazione dell'agente Monitoring

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

Determinare in quali VM Linux è installato l'agente

  • Esegui una delle seguenti query per vedere su quali VM Linux è in esecuzione l'agente:

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

Riavvio automatico dell'agente

Puoi impostare uno script per verificare se l'agente è in esecuzione e quindi riavviare in caso di arresto anomalo.

Ad esempio, su Linux, puoi creare la seguente voce crontab per controllare la stato 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 all'agente Monitoring.

Problema di accesso ai dati di elaborazione (Windows)

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

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 nella tua di un sistema operativo completo. Per non visualizzare più questo messaggio, puoi fornire all'utente SYSTEM autorizzazioni sufficienti per leggere i dati di processo per i processi e i servizi elencati nei messaggi di errore. Se non hai bisogno di 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 di 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 la perdita di dati. Questi messaggi sono generati dall'implementazione del plug-in dei processi corrente in caso di mancata corrispondenza del timestamp.

Problema di eliminazione del punto dati con valore infinito (Linux)

Potresti visualizzare un messaggio di errore nel file di log di sistema di Linux (/var/log/syslog su Debian / Ubuntu o /var/log/messages su Red Hat / centOS / SLES) simili a:

write_gcm: can not take infinite value

Questo messaggio indica che un singolo punto dati con formato non corretto viene eliminato. Questo è normalmente innocui e possono essere ignorati.

Problema di limitazione della chiave dei metadati (Linux)

Potresti visualizzare un messaggio di errore nel file di log di sistema di 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 del throttling della memoria non è riuscito una volta. Normalmente è innocuo, ma potrebbe indicare che l'agente sta per esaurire soprattutto se si verificano di frequente.

Problema di quota dell'API Cloud Monitoring (Linux)

Potresti visualizzare un messaggio di errore nel file di log di sistema di Linux (/var/log/syslog su Debian / Ubuntu o /var/log/messages su Red Hat / centOS / SLES) simili a:

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 sulle quote per informazioni su come gestire il limite di quota.

Memoria utilizzata elevata a causa di un utilizzo ridotto di COLLECTD_INTERVAL (Linux)

Potresti notare un utilizzo elevato della memoria dell'agente quando COLLECTD_INTERVAL è configurato in modo da essere più breve del valore predefinito 60 seconds, ad esempio 10 seconds. Si tratta di una limitazione nota dell'agente perché invia in modo seriale da un singolo thread. Per attenuare questo problema, valuta la possibilità di ridurreCOLLECTD_INTERVAL solo per un sottoinsieme di metriche richieste e lascia il resto delle metriche con l'intervallo predefinito.

Problema di overflow del buffer dei token (Linux)

Nel file di log di sistema di Linux (/var/log/syslog su Debian / Ubuntu o /var/log/messages su Red Hat / CentOS / SLES) potresti visualizzare un messaggio di errore 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 successiva.

L'"Origine" del repository è stata modificata (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 essere diversa dalla relativa origine. Per risolvere il problema, esegui il seguente 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 richiedere fino a ora per segnalare la modifica.

L'agente Monitoring non viene visualizzato in Disinstalla un elenco dei programmi 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.