Risolvi i problemi dell'agente Monitoring

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

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

Elenco di controllo

Se riscontri problemi con l'installazione o l'utilizzo dell'agente Monitoring, ecco alcuni elementi da controllare:

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

  • 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 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 va a buon fine e l'output del log mostra "Disabilitato tramite metadati", è probabile che tu stia eseguendo un'immagine da Google Cloud Marketplace, in cui l'agente Monitoring è disabilitato per impostazione predefinita. Ciò viene controllato dalla chiave di metadati dell'istanza google-monitoring-enable (con il valore 0). Per riattivare l'agente, rimuovi la chiave oppure imposta il valore su 1 (consulta Impostazione dei metadati dell'istanza).

      Se l'agente non è disabilitato tramite metadati, reinstalla l'agente. Per informazioni su questo processo, consulta la pagina Reinstallare l'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 hanno come prefisso collectd o stackdriver-agent:

      • Se vengono visualizzati errori HTTP 429, potresti aver superato le quote dell'API Monitoring. Per visualizzare la quota disponibile, seleziona API e servizi & gt; Dashboard in Google Cloud Console. Scegli l'API Monitoring.

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

      • Se riscontri problemi di autorizzazione o di accesso 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 errori "Combinazione plug-in/tipo raccolti non supportati" o "ID raccolto non supportato", è possibile che tu stia inviando le metriche dell'agente non supportate. Questo può verificarsi nei seguenti scenari:

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

        • Uno dei plug-in delle applicazioni di terze parti invia nuove metriche sconosciute a Monitoring. Consulta la pagina di assistenza per i dettagli su come inviare una richiesta di controllo di queste metriche e di classificazione.

  • Se l'agente sembra essere in esecuzione normalmente, ma non stai ricevendo dati o i tuoi criteri di avviso non funzionano come dovrebbero, 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 se i criteri di avviso non funzionano come previsto, controlla se le credenziali dell'istanza VM sono corrette, incluso se specifica il progetto corretto:

  • Per verificare se i dati arrivano in Monitoring, prova a leggere alcuni dati della serie temporale. Per le istruzioni, consulta Verifica della connessione da agente a progetto. Se visualizzi dati, significa che il problema non riguarda l'agente.

  • Se utilizzi un'istanza VM di Compute Engine con credenziali standard (non a chiave privata), è improbabile che i dati vengano indirizzati al progetto errato, ma le credenziali potrebbero comunque risultare carenti. Per informazioni sulle credenziali, consulta Autorizza 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 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 Autorizza l'agente Monitoring. Per verificare le tue credenziali, consulta la pagina Verifica delle credenziali della chiave privata.

Se il problema persiste, consulta la pagina Reinstallare l'agente Monitoring.

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 vedi alcun dato, è possibile che l'agente stia inviando i dati al progetto sbagliato. Per farlo, consulta la sezione Verifica del progetto e delle credenziali.

Ecco le istruzioni dettagliate per utilizzare il metodo timeSeries.list:

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

    • Istanze di 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 è simile a i-1a2b3c4d.

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

  3. Compila il modulo Explorer API:

    1. Imposta name 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 il filtro sulla riga seguente per scegliere una metrica agente dall'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 della ricerca. Vuoi 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 inserire 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, significa che l'agente funziona correttamente e il processo è stato completato.

Se non vedi dati relativi alle serie temporali, verifica quanto segue:

  • Se la chiamata API genera un messaggio di errore, non è un problema di agente. Verifica che i campi 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 timestamp dipendono dal tipo di metrica specificato. Un tipo di metrica registra dati relativi a GAUGE, DELTA o CUMULATIVE. Per ulteriori informazioni, consulta il sito MetricKind.

      Per le metriche DELTA e CUMULATIVE, le ore di inizio e 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 le ore di inizio e di fine devono definire un intervallo diverso da zero.

    • Se gli errori sono "non autorizzati", l'ID progetto contiene errori di ortografia.

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

    Risolvi i problemi e riprova a chiamare l'API.

  • Se la chiamata API ha esito positivo ma vedi solo una risposta vuota, { }, controlla che il filtro e l'intervallo di tempo siano corretti. Gli errori di formattazione dei timestamp non possono restituire dati. Se sembra tutto corretto ma non ricevi dati, l'agente non sta inviando dati statistici, o almeno non al progetto che stai aspettando. Questo potrebbe indicare un problema con le credenziali; consulta la pagina Verifica delle credenziali con chiave privata.

Verifica delle credenziali di Compute Engine

Utilizza la pagina Istanze VM di Compute Engine di Google Cloud Console per verificare che l'istanza di VM di Compute Engine disponga di credenziali adeguate per l'agente Monitoring . Le credenziali vengono generalmente aggiunte all'account di servizio predefinito di tutte le nuove istanze VM di Compute Engine, ma è possibile sovrascriverle quando si crea un'istanza.

Vai alla pagina Istanze di 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 chiesto di abilitare 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 dei dettagli dell'istanza VM.
  3. Nella pagina Dettagli istanza VM, guarda sotto l'intestazione Ambiti di accesso API Cloud:
    1. Se vedi "Consenti l'accesso completo a tutte le API Cloud", significa che hai credenziali adeguate.
    2. Se accanto a API Stackdriver Monitoring, un nome precedente dell'API Cloud Monitoring, disponi dell'autorizzazione Write only o Full, significa che le credenziali sono adeguate.
    3. In caso contrario, l'account di servizio predefinito dell'istanza non ha le credenziali necessarie dall'agente. Per utilizzare l'agente nell'istanza, devi aggiungere le credenziali dell'account di servizio con chiave privata. Per le istruzioni, consulta la pagina Aggiungere credenziali.

Se hai le credenziali predefinite corrette, vai direttamente alla pagina Installare su Linux e Windows.

Verifica delle credenziali della chiave privata

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

Le credenziali sono presenti?

Per verificare se l'istanza ha credenziali di account di servizio con chiave privata, esegui i comandi Linux seguenti sull'istanza:

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

Se uno dei comandi visualizza un file come quello mostrato di seguito, l'istanza potrebbe avere credenziali di chiave privata valide. Se in entrambi i comandi viene visualizzato 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 la sezione Aggiungere credenziali.

Le credenziali sono valide?

Nel file delle credenziali, 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 ciò che viene mostrato nella sezione IAM e amministrazione & gt; Account di servizio di Google 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 elencato non esiste. Potrebbe essere stato eliminato.
  • L'account di servizio elencato non ha i ruoli corretti attivati. Deve avere almeno roles/monitoring.metricWriter (Monitoring Metric Writer) per l'agente Monitoring e roles/logging.logWriter (Logs Writer) 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 di 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 progetti contenenti istanze Compute Engine create senza includere l'ambito monitoring.write), crea un account di servizio e genera una chiave privata, se non esiste già. Procedi come indicato di seguito.

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

      Vai a Monitoring

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

      • Per AWS, utilizza il link per passare direttamente alla console Google Cloud per il progetto in questione.
      • Per Google Cloud, identifica il progetto contenente le risorse Compute Engine in questione e vai a 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 Creazione di un account di servizio.

  2. Sostituisci la chiave privata nelle istanze corrispondenti 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 dettagli, 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 hanno bisogno di nuove chiavi private, ripeti questa procedura per ognuno.

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

Reinstallazione dell'agente Monitoring

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 eseguono l'agente:

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

Riavvio automatico dell'agente in corso...

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

  • Problema di accesso ai dati di processo (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 interrompere la visualizzazione di questo messaggio, puoi fornire all'utente SYSTEM le autorizzazioni necessarie per leggere i dati di processo relativi ai processi e ai servizi elencati nei messaggi di errore. Se non hai bisogno di questi dati, puoi ignorare questi messaggi informativi.

  • Problemi di cache dei metadati (Linux):

    Potresti visualizzare un messaggio di errore nel file di log del sistema Linux (/var/log/syslog su Debian/Ubuntu o /var/log/messages su Red Hat/CenOS/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 vengono generati dall'implementazione corrente del plug-in dei processi quando si verifica una mancata corrispondenza del timestamp.

  • Problema con il calo di dati relativo a un valore infinito (Linux):

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

    write_gcm: can not take infinite value
    

    Questo messaggio indica che un singolo punto dati non valido viene eliminato. Questa operazione è normalmente innocua e può essere ignorata.

  • Problema di limitazione delle chiavi dei metadati (Linux):

    Potresti visualizzare un messaggio di errore nel file di log del sistema Linux (/var/log/syslog su Debian/Ubuntu o /var/log/messages su Red Hat/CenOS/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. In genere è innocuo, ma potrebbe essere un segnale che l'agente sta per esaurire la memoria, in particolare se si verifica di frequente.

  • Problema di quota API Cloud Monitoring (Linux):

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

    collectd[25198]: write_gcm: Unsuccessful HTTP request 429
    

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

  • Utilizzo elevato della memoria a causa dello scarso COLLECTD_INTERVAL (Linux):

    Potresti notare un utilizzo elevato della memoria da parte dell'agente quando COLLECTD_INTERVAL è configurato in modo più breve rispetto al valore predefinito di 60 seconds, 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, considera la possibilità di ridurre il valore COLLECTD_INTERVAL solo per un sottoinsieme di metriche obbligatorie, e lascia il resto delle metriche nell'intervallo predefinito.

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

    Potresti visualizzare 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: 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.

Agente rimosso segnalato da Google Cloud Console come installato

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