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 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 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 è controllata dalla chiave di metadati dell'istanza
google-monitoring-enable
(con il valore0
). Per riattivare l'agente, rimuovi la chiave o imposta il valore in1
(vedi impostazione dei metadati dell'istanza).Se l'agente non viene disabilitato tramite i metadati, reinstallalo. Per informazioni su questo processo, vedi Reinstallare l'agente Monitoring.
Verifica 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 Monitoring è un pacchetto
collectd
e registra i messaggi in/var/log/syslog
o/var/log/messages
. Il log i messaggi hanno il prefissocollectd
ostackdriver-agent
:Se visualizzi errori HTTP 429, potresti aver superato Quote API di monitoraggio. Puoi vedere le quota disponibile selezionando API e servizi > Dashboard nella nella console Google Cloud. Scegli l'API Monitoring.
Se riscontri problemi con il proxy, verifica di aver eseguito la configurazione corretta Proxy HTTP. Le istruzioni fanno parte 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 visualizzi "Combinazione di plug-in/tipo raccolto non supportata" o "ID raccolto non supportato" errori nei log, è possibile che tu stia inviando metriche degli agenti non supportate. Ciò può verificarsi nei seguenti casi: scenari aggiuntivi:
Hai modificato una delle applicazioni di terze parti dell'agente configurazioni. Per annullare le modifiche, puoi reinstallare il per il plug-in specifico seguendo la procedura istruzioni nella documentazione pertinente . Se vuoi utilizzare l'agente per inviare la metrica a Monitoring, convertendoli in metriche definite dall'utente.
Uno dei plug-in delle applicazioni di terze parti sta inviando nuovi sconosciute a Monitoring. Consulta le pagina di assistenza per maggiori dettagli su come inviare una richiesta di revisione di queste metriche categorizzato.
Se l'agente sembra funzionare normalmente, ma non ricevi dati o che i criteri di avviso non agiscono come dovrebbero, e controllare che l'agente stia inviando i dati al progetto corretto. Consulta le sezione seguente, Verifica del progetto e delle credenziali.
Verifica del progetto e delle credenziali in corso...
Se l'agente Monitoring segnala errori di accesso o 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 di Compute Engine con standard (non chiave privata), è improbabile che i dati vengano inviati progetto errato, ma le tue credenziali potrebbero essere comunque carenti. Per informazioni su credenziali, consulta Autorizzare l'agente Monitoring. Per verificare le tue credenziali, vedi Verifica delle 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 usato dall'agente deve essere Progetto connettore AWS. Per informazioni sulle credenziali, consulta Autorizzare l'agente Monitoring. Per verificare le tue credenziali, vedi Verifica delle credenziali della chiave privata.
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:
Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato con il sottotitolo Compute Engine.
- 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.
- Nella pagina Istanze VM, fai clic sul nome dell'istanza VM. Il dettaglio per la tua istanza VM.
- Nella pagina Dettagli istanza VM, guarda sotto Accesso API Cloud
intestazione ambiti:
- .
- Se vedi il messaggio "Consenti l'accesso completo a tutte le API Cloud", allora avrai un'adeguata e credenziali.
- Se accanto all'API Stackdriver Monitoring vedi, un nome precedente per l'API Cloud Monitoring, ed è necessario disporre del ruolo Write Solo o Completa, significa che disponi di 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 sull'istanza, devi aggiungere le credenziali dell'account di servizio chiavi privata. Per istruzioni, vedi Aggiunta di credenziali.
Se disponi delle credenziali predefinite corrette, passa direttamente al Installazione su Linux e Windows.
Verifica delle credenziali della chiave privata in corso...
Per verificare che sulla tua istanza VM siano installate credenziali per chiave privata valide, verifica innanzitutto che il file delle credenziali esista nella posizione prevista e quindi verifica che le informazioni nel file delle credenziali siano valide. Valide in precedenza e 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 vedere se nell'istanza sono presenti credenziali dell'account di servizio chiavi privata, esegui il comando i seguenti comandi Linux sulla tua 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 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, 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. Associa queste informazioni ai
mostrato in IAM e Amministratore > nella sezione Account di servizio
nella console Google Cloud.
Il file delle credenziali non è valido se una delle seguenti condizioni è vera:
- Stai controllando un'istanza VM di Compute Engine, progetto Google Cloud in delle credenziali non è il progetto che contiene la tua istanza.
- Stai controllando un'istanza Amazon EC2, ma il progetto Google Cloud del file delle credenziali non è 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. Dovrebbe
avere almeno
roles/monitoring.metricWriter
(Autore delle metriche di Monitoring) per raccolta metriche eroles/logging.logWriter
(Writer log) per e scrivere i 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 di credenziali.
Generazione delle nuove credenziali in corso...
Se le credenziali non sono valide:
- Per ogni progetto connesso contenente istanze che devono essere autorizzate.
con una chiave privata,
Progetti per il connettore AWS
e ogni progetto contenente
le istanze Compute Engine
creati senza includere l'ambito di accesso
https://www.googleapis.com/auth/monitoring.write
- creare un account di servizio e generare una chiave privata, se non ne esiste già. Procedi come riportato di seguito:-
Nella console Google Cloud, vai alla settings 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 Monitoraggio.
- Seleziona la scheda Riepilogo.
- Per AWS, utilizza il link per accedere direttamente alla Console Google Cloud per il progetto connettore AWS.
- Per Google Cloud, identifica il progetto contenente alle risorse Compute Engine in questione e nella console Google Cloud.
- Vai alla pagina Account di servizio IAM della
console Google Cloud, seleziona il tuo progetto Google Cloud, crea un nuovo
account di servizio e generi una nuova chiave privata
l'account di servizio.
Per farlo, procedi in uno dei seguenti modi:
Vai alla pagina Account di servizio IAM, selezionare il tuo progetto Google Cloud e seguire i passaggi . Crea un account di servizio:
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 scaricare una chiave nel sistema locale per e un account di servizio specifico dell'agente. Se necessario, crea anche l'account di servizio richiesto e assicura che l'account di servizio abbia autorizzazioni aggiuntive. Gli account di servizio specifici dell'agente 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:
-
Sostituisci la chiave privata nelle istanze che corrispondono dell'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 ulteriori informazioni, vedi Copia della chiave privata nell'istanza in corso.
- Su Linux, sostituisci la chiave privata che si trova in
Riavvia l'agente
- Su Linux, esegui
sudo service stackdriver-agent restart
- Su Windows, vai alla console di gestione dei servizi e riavvia
Servizio
Cloud Monitoring
.
- Su Linux, esegui
Se hai più progetti che richiedono nuove chiavi private, ripeti questa procedura per ciascuna di esse.
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 richiamare il metodo utilizzando
Explorer API attivo
pagina della documentazione del metodo. In caso contrario
vedere i dati, è possibile che l'agente stia inviando dati al progetto sbagliato. A
verificalo, consulta Verifica del progetto e delle credenziali.
Di seguito sono riportate le istruzioni dettagliate per l'utilizzo
Metodo timeSeries.list
:
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 ciascuna istanza è riportato nell'elenco di di Compute Engine. L'ID sembra essere
i-1a2b3c4d
.
Vai alla pagina della documentazione per
timeSeries.list
.Compila il modulo di Explorer API:
Imposta name sul progetto contenente la tua istanza VM, preceduto da
projects/
. Ad esempio:projects/[YOUR_PROJECT_ID]
. Per Amazon EC2 , devi utilizzare la classe Progetto connettore AWS per il tuo account Amazon.Imposta il filtro sulla riga seguente per scegliere una metrica dell'agente da dell'istanza VM. Copialo e incollalo in Explorer API, e poi modifica l'ID istanza VM:
metric.type = "agent.googleapis.com/memory/bytes_used" AND resource.label.instance_id = "[YOUR-VM-INSTANCE-ID]"
Imposta l'intervallo di tempo della ricerca. Vuoi una durata di circa 5 minuti intervallo:
Imposta interval.endTime sull'ora GMT corrente, che puoi trovare alle ore time.is/GMT. L'ora devono essere formattati come nell'esempio seguente. Non racchiudere il valore ora tra virgolette:
2016-10-31T14:10:00Z
Imposta interval.startTime su circa cinque minuti prima dell'ora di fine, utilizzando lo stesso formato.
Lascia vuoti tutti gli altri campi.
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, questo non indica che problema dell'agente. Verifica che i campi di Explorer API siano compilati correttamente:
"Argomento non valido" gli errori probabilmente indicano 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
GAUGE
,DELTA
oCUMULATIVE
. Per saperne di più, visitaMetricKind
informazioni.Per le metriche
DELTA
eCUMULATIVE
, le ore di inizio e di fine sono entrambe e l'ora di fine deve essere successiva all'ora di inizio. Questi tipi dei tipi di metriche registrano le variazioni misurate nel tempo, pertanto l'inizio e le ore di fine devono definire un intervallo diverso da zero."Non autorizzata" possono significare che l'ID progetto non è stato digitato correttamente.
"Non trovato" e errori possono indicare che hai omesso i campi obbligatori Prefisso
projects/
nel "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. Errori di formattazione i timestamp possono comportare la 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:
Se hai la certezza che il problema non dipenda dalle credenziali, puoi saltare vai alla sezione Installazione su Linux e Windows.
Per un'installazione completa dell'agente e delle eventuali credenziali necessarie, consulta Installare l'agente Monitoring.
Determinare in quali VM Linux è installato l'agente
Esegui una delle seguenti query per vedere quali VM Linux stanno eseguendo 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 nell'elaborazione (Windows)
Nel log eventi di Windows potrebbe essere visualizzato un messaggio di errore dell'agente simile a questo: 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, fornisci autorizzazioni sufficienti per
all'utente SYSTEM
di leggere i dati di processo per i processi e i servizi elencati
nei messaggi di errore. Se non hai bisogno di questi dati, puoi tranquillamente ignorarli
questi messaggi informativi.
Problemi di 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) simili
a:
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 relativo all'eliminazione di punti dati a 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 viene eliminato un singolo punto dati non valido. Questo è normalmente innocui e possono essere ignorati.
Problema della limitazione della chiave di 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) simili
a:
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. 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 le Quota guida per informazioni sulla gestione del limite di quota.
Memoria utilizzata elevata a causa di un utilizzo ridotto di COLLECTD_INTERVAL
(Linux)
L'utilizzo della memoria da parte dell'agente potrebbe essere elevato quando COLLECTD_INTERVAL
è
configurato per essere più breve del valore predefinito di 60 seconds
, ad esempio 10
seconds
. Si tratta di una limitazione nota dell'agente perché invia
in modo seriale da un singolo thread. Per mitigare questo problema, valuta la possibilità di ridurre
COLLECTD_INTERVAL
solo per un sottoinsieme di metriche obbligatorie e lascia il valore
altre 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 Monitoring alla versione 6.1.2
o successiva.
L'"Origine" del repository è stata modificata (Linux)
Potresti visualizzare un messaggio di errore simile al seguente quando esegui l'upgrade del
installando l'agente o eseguendo 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 essere divergente dalla sua 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 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 Monitoring quando non è elencato nel controllo di Windows:
Seleziona l'elenco Disinstalla un programma del riquadro, esegui uninstall.exe
dalla directory
in cui l'hai installata.