Risoluzione dei problemi dell'agente

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

Elenco di controllo

Se hai problemi a installare o utilizzare l'agente Monitoring, controlla quanto segue:

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

  • Verifica che il servizio agente sia in esecuzione sulla tua istanza VM:

    • Per una VM Windows, utilizza il seguente comando di 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, potresti doverlo riavviare utilizzando il seguente comando:

      sudo service stackdriver-agent restart
      

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

      Se l'agente non è disabilitato tramite i metadati, reinstallalo. Per informazioni su questo processo, consulta la sezione Reinstallare l'agente.

  • 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 quote dell'API Monitoring. Per visualizzare la tua quota disponibile, seleziona API e servizi > Dashboard in Cloud Console. Scegli l'API Monitoring.

      • Se visualizzi problemi relativi al proxy, verifica di averlo configurato correttamente. Le istruzioni sono parte dell'installazione su Linux e Windows.

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

      • Se nei log viene visualizzato il messaggio "combinazione plug-in/tipo raccolto non supportata" oppure "ID id"Non supportato, è possibile che tu stia inviando metriche relative all'agente non supportate. Ciò può accadere nei seguenti scenari:

        • Hai modificato una configurazione di applicazioni di terze parti dell'agente. Per annullare le modifiche, puoi reinstallare la configurazione per il plug-in specifico seguendo le istruzioni nella pagina sulla documentazione pertinente. Se vuoi utilizzare l'agente per inviare questa metrica a Monitoring, valuta la possibilità di convertirla in metriche personalizzate.

        • Uno dei plug-in delle applicazioni di terze parti sta inviando nuove metriche sconosciute a Monitoring. Vedi la pagina di supporto per i dettagli su come inviare una richiesta di revisione e classificazione di queste metriche.

  • Se l'agente sembra essere normalmente in esecuzione, ma non stai ricevendo dati o i tuoi criteri di avviso non agiscono come ritieni che dovresti, dovresti controllare che l'agente stia inviando i dati al progetto corretto. Consulta la sezione seguente, Verifica del progetto e delle credenziali.

Verifica del progetto e delle credenziali

Se l'agente segnala errori di accesso o di autorizzazione oppure se l'agente sembra essere in esecuzione normalmente, ma non sono presenti dati o i criteri di avviso non funzionano come previsto, devi verificare che le credenziali dell'istanza VM siano corrette, incluso se specifica il progetto corretto:

  • Per verificare se i dati stanno arrivando in Monitoring, prova a leggere alcuni dati della serie temporale. Per le istruzioni, consulta la sezione Verifica della connessione agente-progetto. Se sono presenti dati, il problema non è riscontrabile con l'agente.

  • Se utilizzi un'istanza VM di Compute Engine con credenziali standard (non private), è improbabile che i dati vengano inviati al progetto errato, ma le tue credenziali potrebbero comunque essere carenti. Per informazioni sulle credenziali, vedi Autorizzazione dell'agente. Per verificare le credenziali, consulta Verifica delle credenziali Compute Engine.

  • Se utilizzi un'istanza VM Amazon EC2 o se utilizzi credenziali di chiave privata nell'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 connettore AWS. Per informazioni sulle credenziali, consulta la sezione Autorizzazione dell'agente. Per verificare le credenziali, consulta Verifica delle credenziali della chiave privata.

Se non hai ancora risolto il problema, consulta la sezione Reinstallare l'agente.

Verifica dei dati dell'agente

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

Di seguito sono riportate le istruzioni dettagliate per l'utilizzo del metodo timeSeries.list:

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

    • Istanze Compute Engine: vai alla pagina dei dettagli di Compute Engine per l'istanza. In fondo alla pagina, fai clic su REST equivalente. L'ID è un numero di 19 cifre.

    • Istanze Amazon EC2: l'ID per ogni istanza è visualizzato nell'elenco delle istanze. L'ID ha questo aspetto: i-1a2b3c4d.

  2. Vai alla pagina della documentazione del metodo timeSeries.list.

  3. Compila il modulo Explorer API:

    1. Imposta nome sul progetto contenente l'istanza VM, preceduto da projects/. Ad esempio: projects/[YOUR_PROJECT_ID]. Per le istanze Amazon EC2, devi utilizzare il progetto connettore AWS per il tuo account Amazon.

    2. Imposta filtro sulla riga seguente per scegliere una metrica dell'agente dalla tua istanza VM. Copialo 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 di 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 racchiudi il tempo 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": "[GCP-OR-AWS-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 della serie temporale dalla tua istanza VM, come mostrato sopra, l'agente funziona correttamente e il traffico è terminato.

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

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

    • "Errori di argomento" non validi probabilmente indicano un problema di ortografia e 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 dati GAUGE, DELTA o CUMULATIVE. Per ulteriori informazioni, visita la pagina MetricKind.

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

    • "Non autorizzati", possono significare errori di ortografia nell'ID progetto.

    • "Errori non trovati" possono indicare che hai omesso il prefisso projects/ obbligatorio nel campo "nome".

    Risolvi i problemi e prova a richiamare l'API.

  • Se la chiamata API ha esito positivo ma viene visualizzata 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 dei dati. Se tutto sembra corretto ma non ricevi dati, l'agente non sta inviando i dati della metrica o almeno non al progetto. Ciò potrebbe indicare un problema di credenziali. Vedi Verificare le credenziali della chiave privata.

Verifica delle credenziali Compute Engine

Utilizza la pagina Istanze VM di Compute Engine di Cloud Console per verificare che la tua istanza VM di Compute Engine disponga di credenziali sufficienti per l'agente Monitoring. Le credenziali vengono in genere aggiunte nell'account di servizio predefinito di tutte le nuove istanze VM di Compute Engine, ma è possibile sovrascriverle per la creazione di un'istanza.

Vai alla pagina Istanze Compute Engine

  1. Se necessario, modifica il progetto Google Cloud corrente in modo che sia associato all'istanza VM di Compute Engine. Ad esempio, se ti viene richiesto di abilitare la fatturazione, significa che il progetto corrente non contiene istanze VM di Compute Engine.
  2. Nella pagina Istanze VM, fai clic sul nome della tua istanza VM. Viene visualizzata la pagina dei dettagli per l'istanza VM.
  3. Nella pagina Dettagli istanza VM, cerca l'intestazione Ambiti di accesso Cloud API:
    1. Se vedi "Consenti l'accesso completo a tutte le API Cloud", disponi delle credenziali appropriate.
    2. Se vedi accanto all'API Stackdriver Monitoring, un nome precedente per l'API Cloud Monitoring, che dispone dell'autorizzazione Scrittura solo o Completa, significa che possiedi le credenziali adeguate.
    3. In caso contrario, l'account di servizio predefinito dell'istanza non dispone delle credenziali necessarie dall'agente. Per utilizzare l'agente sull'istanza, devi aggiungere le credenziali dell'account di servizio con chiave privata. Per le istruzioni, vedi Aggiungere credenziali.

Se disponi delle credenziali predefinite corrette, vai alla sezione Installare Linux e Windows.

Verifica delle credenziali della chiave privata

Per verificare che nell'istanza VM siano installate credenziali di 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 di Cloud Console. Se non sono presenti credenziali valide, consulta la sezione Aggiungere credenziali per sostituire le credenziali esistenti o per aggiungerne altre.

Le credenziali sono presenti?

Per verificare se le credenziali dell'account di servizio private-key sono presenti nell'istanza, esegui i comandi Linux seguenti nell'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 mostrato di seguito, l'istanza potrebbe avere credenziali di 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, consulta la sezione Aggiungere credenziali.

Le credenziali sono valide?

Nel file delle credenziali, il tuo progetto Google Cloud è project_id, 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 ciò che è mostrato nella sezione IAM e AMP; account di servizio di Cloud Console.

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

  • Stai controllando un'istanza VM di Compute Engine, ma il progetto Google Cloud nel file delle credenziali non è il progetto che contiene la tua istanza.
  • Stai controllando un'istanza di 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 indicato non esiste. Potrebbe essere stato eliminato.
  • L'account di servizio indicato non dispone dei ruoli corretti. Deve avere almeno roles/monitoring.metricWriter (Writer metriche) per l'agente Monitoring e roles/logging.logWriter (Writer log) per l'agente Logging.
  • La chiave privata non esiste. Potrebbe essere stato revocato.

Se l'account di servizio funziona correttamente 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 seguente, Aggiungere credenziali.

Generazione delle nuove credenziali in corso...

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 (progetti di connettore AWS e progetti che contengono istanze di Compute Engine create senza includere l'ambito monitoring.write), crea un account di servizio e genera una chiave privata, se non esiste già. Procedi nel seguente modo:

    1. Per visualizzare l'elenco dei progetti collegati all'ambito delle metriche, vai a Monitoraggio:

      Vai a Monitoring

    2. Se nel riquadro di navigazione di Monitoring, seleziona Impostazioni e poi la scheda Riepilogo:

      • Per AWS, utilizza il link per passare direttamente alla Google Cloud Console per il progetto in questione.
      • Per Google Cloud, identifica il progetto contenente le risorse di Compute Engine in questione e vai alla Google Cloud Console.
    3. Da Google Cloud Console, vai alla pagina Account di servizio IAM.

    4. Crea un nuovo account di servizio e genera una nuova chiave privata.

      L'approccio più semplice consiste nel scaricare una chiave privata con la configurazione corretta. Per ottenere questa chiave, modifica l'URL dalla pagina corrente: aggiungi &createStackdriverServiceAccount alla fine dell'URL. Per ulteriori informazioni, consulta la sezione Creare un account di servizio.

  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 disponibile in C:\ProgramData\Google\Auth\application_default_credentials.json Per maggiori dettagli, consulta la sezione Copiare la chiave privata nell'istanza.
  3. Riavvia l'agente

    • Su Linux, esegui sudo service stackdriver-agent restart
    • Su Windows, accedi 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 ognuno.

Per verificare che la chiave privata sia corretta, vedi 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 di project-id corrisponda a quello del progetto monitorato per il quale hai appena generato le credenziali.

Reinstallazione dell'agente

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

Determinazione delle VM Linux su cui è installato l'agente

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

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

Riavvio automatico dell'agente

Puoi configurare uno script per verificare se l'agente è in esecuzione, quindi riavviare l'agente 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

  • Elabora il problema di accesso ai dati (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 sul tuo sistema. Per non visualizzare più questo messaggio, puoi fornire all'utente SYSTEM le autorizzazioni sufficienti per leggere i dati dei processi e i servizi elencati nei messaggi di errore. Se non hai bisogno di questi dati, puoi ignorare questi messaggi informativi.

  • Problemi di memorizzazione nella cache dei metadati (Linux):

    Potrebbe essere visualizzato un messaggio di errore nel file di log del 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 sono indicativi di perdita di dati. Questi messaggi vengono generati dall'implementazione del plug-in dei processi attuale quando si verifica una mancata corrispondenza del timestamp.

  • Problema interruzione del punto dati con valore infinito (Linux):

    Potrebbe essere visualizzato un messaggio di errore nel file di log del 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 ignorato. In genere questo comportamento è innocuo e può essere ignorato.

  • Problema di limitazione della chiave dei metadati (Linux):

    Potrebbe essere visualizzato un messaggio di errore nel file di log del 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 riesce una volta sola. In genere è innocuo, ma potrebbe anche indicare che l'agente sta per esaurirsi, soprattutto se si verifica spesso.

  • Fuori dal problema della quota dell'API Cloud Monitoring (Linux):

    Potrebbe essere visualizzato un messaggio di errore nel file di log del 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 a causa della scarsa disponibilità di COLLECTD_INTERVAL (Linux):

    Potresti notare un utilizzo elevato della memoria da parte dell'agente quando COLLECTD_INTERVAL è configurato in modo da essere inferiore all'impostazione predefinita 60 seconds, ad esempio 10 seconds. Si tratta di una limitazione nota dell'agente perché invia richieste in serie da un singolo thread. Per risolvere il problema, ti consigliamo di ridurre il valore COLLECTD_INTERVAL solo per un sottoinsieme di metriche obbligatorie e lasciare le altre metriche nell'intervallo predefinito.

  • Problema di overflow del buffer di token (Linux) :

    Nel file di log di sistema di Linux (/var/log/syslog su Debian / Ubuntu o /var/log/messages on Red Hat / CentOS / SLES) potrebbe essere visualizzato 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.

Agente rimosso segnalato da Google Cloud Console come installato

Dopo aver disinstallato l'agente, potrebbe essere necessaria fino a un'ora per segnalare la modifica in Google Cloud Console.