Risolvi i problemi dell'agente Monitoring

Questa pagina consente di diagnosticare i problemi di installazione o esecuzione dell'agente Monitoring.

Elenco di controllo

Se hai difficoltà a installare o utilizzare l'agente Monitoring, puoi verificare quanto segue:

  • Se i comandi di installazione di Linux generano errori, assicurati di precedere sudo per i comandi di installazione.

  • Verifica che il servizio dell'agente sia in esecuzione sulla tua 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", probabilmente stai eseguendo un'immagine da 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 (consulta Impostazione dei metadati dell'istanza).

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

  • Verifica 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 dal prefisso collectd o stackdriver-agent:

      • Se vengono visualizzati errori HTTP 429, potresti aver superato le quote dell'API Monitoring. Puoi visualizzare la quota disponibile selezionando API e servizi > Dashboard nella console Google Cloud. Scegli l'API Monitoring.

      • Se riscontri problemi con il proxy, controlla 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 come "Impossibile determinare l'endpoint raccolto", consulta la sezione seguente, Verifica del progetto e delle credenziali.

      • Se nei log visualizzi gli errori "Combinazione di plug-in/tipo raccolto non supportata" o "ID raccolto 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 delle applicazioni di terze parti sta inviando nuove metriche sconosciute a Monitoring. Consulta la pagina di assistenza per i dettagli su come inviare una richiesta di revisione e categorizzazione di queste metriche.

  • Se l'agente sembra funzionare normalmente, ma non stai ricevendo dati o i tuoi criteri di avviso non agiscono come ritieni che dovrebbero, devi verificare che l'agente stia inviando dati al progetto corretto. Consulta la sezione Verifica del progetto e delle credenziali riportata di seguito.

Verifica del progetto e delle credenziali in corso...

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

Se non hai ancora risolto il problema, consulta Reinstallazione dell'agente Monitoring.

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. In genere le credenziali vengono aggiunte nell'account di servizio predefinito di tutte le nuove istanze VM di Compute Engine. Tuttavia, è possibile sovrascrivere queste impostazioni durante la creazione di un'istanza.

Nella console Google Cloud, vai alla pagina Istanze VM:

Vai a Istanze VM

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

  1. Se necessario, modifica l'attuale progetto Google Cloud in modo che corrisponda a quello associato alla tua istanza VM di Compute Engine. Ad esempio, se ti viene chiesto di abilitare la fatturazione, significa che nel progetto attuale non sono presenti istanze VM di Compute Engine.
  2. Nella pagina Istanze VM, fai clic sul nome dell'istanza VM. Viene visualizzata la pagina dei dettagli dell'istanza VM.
  3. Nella pagina Dettagli istanza VM, cerca sotto l'intestazione Ambiti di accesso all'API Cloud:
    • Se vedi il messaggio "Consenti l'accesso completo a tutte le API Cloud", significa che disponi di credenziali adeguate.
    • Se accanto all'API Stackdriver Monitoring vedi un nome meno recente per l'API Cloud Monitoring, che indica che disponi dell'autorizzazione di sola scrittura o completa, significa che disponi delle credenziali adeguate.
    • In caso contrario, l'account di servizio predefinito della tua istanza non dispone delle credenziali necessarie dall'agente. Per usare l'agente sull'istanza, devi aggiungere le credenziali dell'account di servizio chiavi privata. Per le istruzioni, consulta Aggiungere le credenziali.

Se disponi delle credenziali predefinite corrette, passa direttamente alla sezione Installazione su Linux e Windows.

Verifica delle credenziali della chiave privata in corso...

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

Le credenziali sono presenti?

Per verificare se nell'istanza sono presenti credenziali dell'account di servizio chiavi privata, esegui i seguenti comandi Linux nell'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, l'istanza potrebbe avere credenziali di chiave privata valide. Se entrambi i comandi visualizzano un file, viene utilizzato il file indicato con 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 delle credenziali.

Le credenziali sono valide?

Nel file delle credenziali, il campo project_id è il 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. Abbina queste informazioni a quanto visualizzato 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 di Compute Engine, ma il progetto Google Cloud nel file delle credenziali non è quello che contiene la tua istanza.
  • Stai controllando un'istanza Amazon EC2, ma il progetto Google Cloud nel file delle credenziali non è il progetto connettore AWS per il 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 (Writer metriche Monitoring) per la raccolta delle metriche e roles/logging.logWriter (Writer log) per la scrittura di log.
  • La chiave privata non esiste. Potrebbe essere stato revocato.

Se l'account di servizio è a posto, 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 Aggiunta di credenziali riportata di seguito.

Generazione delle nuove credenziali in corso...

Se le credenziali non sono valide:

  1. Per ogni progetto connesso contenente istanze che devono essere autorizzate con una chiave privata (progetti del connettore AWS e ogni progetto contenente istanze di 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à. Procedi come indicato di seguito:

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

      Vai alle impostazioni di Monitoring

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

    2. Seleziona la scheda Riepilogo.
      • Per AWS, utilizza il link per accedere direttamente alla console Google Cloud per il progetto del connettore AWS.
      • Per Google Cloud, identifica il progetto contenente le risorse Compute Engine in questione e vai alla console Google Cloud.
    3. Vai alla pagina Account di servizio IAM della console Google Cloud, seleziona il progetto Google Cloud, crea un nuovo account di servizio, quindi genera una nuova chiave privata per quell'account.

      Per farlo, procedi in uno dei seguenti modi:

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

        Vai agli account di servizio IAM

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

        Crea l'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 l'account di servizio richiesto e assicura che l'account di servizio 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 del completamento di queste 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 all'account di servizio 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 maggiori informazioni, consulta Copia della 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.

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 progetto monitorato 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 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 i dati al progetto sbagliato. Per verificarlo, consulta la pagina Verifica del progetto e delle credenziali.

Di seguito sono riportate le istruzioni dettagliate per utilizzare il 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 per ogni istanza è riportato nell'elenco delle istanze. L'ID sembra essere 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 la tua istanza VM, preceduto dal prefisso projects/. Ad esempio: projects/[YOUR_PROJECT_ID]. Per le istanze Amazon EC2, devi utilizzare il progetto del connettore AWS per il tuo account Amazon.

    2. Imposta il filtro sulla riga seguente per scegliere una metrica dell'agente dalla tua istanza VM. Copialo e incollalo in Explorer API, quindi modifica l'ID dell'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. Occorre 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 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 dall'istanza VM, come mostrato sopra, 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 significa che si sia verificato un problema con l'agente. Verifica che i campi di Explorer API siano compilati correttamente:

    • Gli errori di tipo "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 timestamp dipendono dal tipo di metrica specificato. Un tipo di metrica registra i dati GAUGE, DELTA o CUMULATIVE. Per saperne di più, consulta MetricKind.

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

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

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

    Risolvi i problemi e riprova a eseguire la chiamata API.

  • Se la chiamata API riesce, ma vedi solo una risposta vuota, { }, verifica che il filtro e l'intervallo di tempo siano corretti. Gli 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 previsto. Questo potrebbe indicare un problema con le credenziali; consulta Verificare le 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 viene eseguito 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 impostare uno script per verificare se l'agente è in esecuzione e poi 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 all'agente Monitoring.

Problema di accesso ai dati nell'elaborazione (Windows)

Nel log 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 nel tuo sistema. Per non visualizzare più questo messaggio, puoi fornire all'utente SYSTEM autorizzazioni sufficienti per leggere i dati di elaborazione per i processi e i servizi elencati nei messaggi di errore. Se non hai bisogno di questi dati, puoi tranquillamente ignorare questi messaggi informativi.

Problemi di cache dei metadati (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:

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 vengono generati dall'implementazione del plug-in dei processi attuali in caso di mancata corrispondenza del timestamp.

Problema relativo all'eliminazione di punti dati a valore infinito (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: can not take infinite value

Questo messaggio indica che viene eliminato un singolo punto dati non valido. Questo comportamento è generalmente innocuo e può essere ignorato.

Problema della limitazione della chiave di metadati (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:

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 riesce una sola volta. Di solito è innocuo, ma potrebbe indicare che l'agente sta esaurendo la memoria, soprattutto se si verifica di frequente.

Problema di quota dell'API Cloud Monitoring (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:

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 alla quota 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 da parte dell'agente quando COLLECTD_INTERVAL è configurato in modo da essere più breve del valore predefinito di 60 seconds, ad esempio 10 seconds. Si tratta di una limitazione nota dell'agente perché invia le richieste in modo seriale da un singolo thread. Per mitigare questo problema, valuta la possibilità di ridurre il valore COLLECTD_INTERVAL solo per un sottoinsieme di metriche richieste e lascia il resto delle metriche sull'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 Monitoring alla versione 6.1.2 o successiva.

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

Potresti visualizzare un messaggio di errore simile al seguente durante l'upgrade dell'agente, l'installazione dell'agente o l'esecuzione di apt-get update su Debian/Ubuntu Linux:

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 di pacchetti potrebbe essersi disconnessa dall'origine. Per risolvere il problema, esegui questo comando:

apt-get --allow-releaseinfo-change update

Quindi, esegui l'upgrade o installa di nuovo.

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 Monitoring non viene visualizzato in Disinstalla un elenco dei programmi di Windows

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