Tieni presente che stai visualizzando la documentazione di Looker. Per la documentazione di Looker Studio, visita https://support.google.com/looker-studio.

Questa pagina è stata tradotta dall'API Cloud Translation.

Monitorare Looker

Anche se il monitoraggio delle applicazioni Looker potrebbe non sembrare strettamente necessario, è molto importante configurarlo nelle istanze ospitate dal cliente. Nei rari casi in cui si verifichi un problema con il server, spesso è molto più difficile o impossibile per Looker aiutarti a risolvere il problema, a meno che tu non possa fornire informazioni di monitoraggio appropriate dal momento dell'incidente.

Monitoraggio delle applicazioni

URL

Esistono due semplici modi per verificare che l'istanza di Looker sia in esecuzione.

Aggiungi /alive all'URL dell'istanza di Looker come segue:

https://instance_name.looker.com/alive

Se l'istanza è in grado di rispondere a una richiesta web, riceverai un codice di stato HTTP 200 OK.
Aggiungi /availability all'URL dell'istanza di Looker come segue:

https://instance_name.looker.com/availability

Questo URL esegue un controllo più completo di diversi sottosistemi di base e risponderà anche con un codice di stato HTTP 200 OK se tutto va bene.

JMX

La macchina virtuale Java che esegue Looker può essere monitorata tramite JMX.

Molte applicazioni di monitoraggio come Zabbix e Nagios supportano JMX. Per saperne di più, consulta la documentazione dell'applicazione di monitoraggio.

Modificare lo script di avvio di Looker

Per abilitare il monitoraggio JMX, devi modificare lo script di avvio di Looker. Per impostazione predefinita, è denominato:

/home/looker/looker/looker

Cerca i parametri di avvio di Java:

java \
  -XX:+UseG1GC -XX:MaxGCPauseMillis=2000 \
  -Xms$JAVAMEM -Xmx$JAVAMEM \
  -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps \
  -Xloggc:/tmp/gc.log  ${JAVAARGS} \
  -jar looker.jar start ${LOOKERARGS}

A partire da Looker 6.18, il file JAR di Looker è stato suddiviso in due file JAR distinti: il file JAR principale di Looker e un file JAR delle dipendenze di Looker. All'avvio, il file JAR principale avvierà automaticamente il file JAR delle dipendenze. Entrambi i file JAR devono trovarsi nella stessa directory in modo che il file JAR principale possa trovare e avviare correttamente il file JAR delle dipendenze.

Per impostazione predefinita, l'opzione di avvio --no-daemonise non è impostata. Se non hai impostato l'opzione --no-daemonise, aggiungi una sezione dopo la riga che inizia con -Xms$JAVAMEM:

  -Dcom.sun.akuma.jvmarg.com.sun.management.jmxremote \
  -Dcom.sun.akuma.jvmarg.com.sun.management.jmxremote.port=9910 \
  -Dcom.sun.akuma.jvmarg.com.sun.management.jmxremote.ssl=false \
  -Dcom.sun.akuma.jvmarg.com.sun.management.jmxremote.local.only=false \
  -Dcom.sun.akuma.jvmarg.com.sun.management.jmxremote.authenticate=true \
  -Dcom.sun.akuma.jvmarg.com.sun.management.jmxremote.access.file=${HOME}/.lookerjmx/jmxremote.access \
  -Dcom.sun.akuma.jvmarg.com.sun.management.jmxremote.password.file=${HOME}/.lookerjmx/jmxremote.password \

Se hai impostato l'opzione di avvio --no-daemonise, aggiungi una sezione dopo la riga che inizia con -Xms$JAVAMEM:

  -Dcom.sun.management.jmxremote \
  -Dcom.sun.management.jmxremote.port=9910 \
  -Dcom.sun.management.jmxremote.ssl=false \
  -Dcom.sun.management.jmxremote.local.only=false \
  -Dcom.sun.management.jmxremote.authenticate=true \
  -Dcom.sun.management.jmxremote.access.file=${HOME}/.lookerjmx/jmxremote.access \
  -Dcom.sun.management.jmxremote.password.file=${HOME}/.lookerjmx/jmxremote.password \

Crea la directory `.lookerjmx`

Quindi, crea la directory .lookerjmx nella home directory dell'utente di Looker e imposta le autorizzazioni:

sudo su - looker
mkdir ~/.lookerjmx
chmod 700 ~/.lookerjmx
cd ~/.lookerjmx

Crea i file JMX

Utilizzando il tuo editor di testo preferito, crea un file nella nuova directory denominato jmxremote.access con i seguenti contenuti (che puoi personalizzare in base al tuo ambiente):

monitorRole   readonly
controlRole   readwrite \
              create javax.management.monitor.*,javax.management.timer.* \
              unregister

Quindi, crea un file denominato jmxremote.password nella stessa directory con il seguente contenuto, utilizzando le tue password sicure:

monitorRole   some_password_here
controlRole   some_password_here

Impostazione delle autorizzazioni

Imposta Java (e quindi Looker) in modo che non si avvii se le autorizzazioni dei file consentono a chiunque tranne all'utente di Looker di leggere il file della password.

chmod 400 jmxremote.*

Riavvia Looker

Per attivare JMX, è necessario riavviare Looker. Assicurati di eseguire questo comando *come utente Looker e non come utente root*:

cd ~/looker
./looker restart

L'istanza Looker è ora configurata per il monitoraggio JMX remoto sulla porta 9910, utilizzando la password che hai fornito. Potresti dover modificare le impostazioni del firewall o gli ACL di rete per consentire al server di monitoraggio di ottenere l'accesso alla rete su questa porta.

Monitoraggio dell'host

Per ogni host su cui è in esecuzione l'applicazione Looker, ti consigliamo di raccogliere, creare grafici e generare avvisi per almeno le seguenti metriche sul rendimento:

Utilizzo CPU: carico e percentuale di CPU utilizzata
Utilizzo della memoria: totale utilizzata e swap utilizzata
Utilizzo del disco

Soglie di avviso

Per stabilire soglie di avviso adeguate, devi prima stabilire una baseline. Raccogli i dati sul rendimento con l'istanza Looker in esecuzione con un carico normale. Dai un'occhiata ai grafici sul rendimento e osserva i picchi. Il periodo di tempo necessario per stabilire le linee di base dipende dalla tua attività e dai tuoi pattern di utilizzo di Looker. Alcune aziende potrebbero utilizzare Looker in modo stabile e ripetibile ogni settimana durante l'orario di apertura. Altri potrebbero utilizzare Looker in misura maggiore in momenti specifici (ad esempio alla fine di ogni mese).

In generale, gli avvisi devono essere inviati solo per gli eventi che possono essere gestiti. L'invio di avvisi quando non è necessario fare nulla maschera l'importanza degli avvisi critici.

Le seguenti soglie possono essere utilizzate come punto di partenza per gli avvisi. Quando i seguenti valori vengono superati per 15 minuti o più, potrebbe essere necessario un intervento manuale.

Metrica	Avviso	Critico	Commenti
Carico CPU	2	4	In genere, il carico deve essere pari o inferiore a 1 per un sistema a un solo core. Un carico elevato prolungato comporta scarse prestazioni.
% di CPU utilizzata	80	90	Un utilizzo elevato della CPU comporta prestazioni scadenti.
% di memoria utilizzata	60	70	Un utilizzo elevato della memoria può indicare che è stata allocata troppa memoria a Java.
% disco utilizzato	80	90	Assicurati che lo spazio sul disco non sia esaurito.

Note aggiuntive:

I sistemi con più di un core possono gestire carichi della CPU elevati senza ridurre le prestazioni. La regola generale è che il carico sostenuto non deve essere maggiore del numero di core del processore.
La percentuale di tempo totale della CPU in uso prima che un sistema subisca un degrado delle prestazioni varia in base al numero di core della CPU nel sistema. In altre parole, un sistema a un solo core potrebbe avere prestazioni scadenti quando la CPU è utilizzata all'80%, mentre un host a sedici core potrebbe essere ancora utilizzabile con un utilizzo del 95%.
L'utilizzo elevato e prolungato della CPU può essere corretto aggiornando l'hardware host o eseguendo l'upgrade a un'istanza più grande. A volte, un numero elevato di look pianificati o tabelle derivate da query lunghe può essere ridotto o reso più efficiente per migliorare le prestazioni.

Passaggi successivi

Dopo aver configurato il monitoraggio, puoi configurare i backup di Looker.