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.

Monitoraggio di Looker

Anche se il monitoraggio delle applicazioni di Looker potrebbe non sembrare strettamente necessario, è molto importante configurarlo nelle istanze ospitate dal cliente. Nei rari casi in cui si verifica 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 in questo modo:

https://instance_name.looker.com/availability

Questo URL esegue un controllo più completo di vari sottosistemi sottostanti e, se non ci sono problemi, risponde con un codice di stato HTTP 200 OK.

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.

Modifica lo script di avvio di Looker

Per attivare il monitoraggio JMX, devi modificare lo script di avvio di Looker. Per impostazione predefinita il nome:

/home/looker/looker/looker

Cerca i parametri di avvio 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 separati: 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 di --no-daemonise non è configurata. Se non hai impostato l'opzione --no-daemonise, aggiungi una sezione seguendo 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 configurato l'opzione di avvio di --no-daemonise, aggiungi una sezione seguendo 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.*

Riavviare Looker

Looker deve essere riavviato per abilitare JMX. 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. Potrebbe essere necessario modificare le impostazioni del firewall o gli ACL di rete per consentire al server di monitoraggio di ottenere l'accesso di 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 utilizzato e scambio utilizzato
Utilizzo del disco

Soglie di avviso

Per stabilire soglie di avviso efficaci, devi prima definire una base di riferimento. 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 tempo necessario per stabilire le basi dipende dalla tua attività e dai pattern di utilizzo di Looker. Alcune aziende possono utilizzare Looker con un pattern stabile e ripetibile ogni settimana durante l'orario di apertura. Altri possono utilizzare Looker in modo più intensivo in momenti specifici (ad esempio alla fine di ogni mese).

In generale, gli avvisi devono essere inviati solo per gli eventi strategici. 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. Se i valori indicati di seguito 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 sostenuto porta a un rendimento scarso.
% CPU utilizzata	80	90	Un utilizzo elevato della CPU comporta scarse prestazioni.
% di memoria utilizzata	60	70	Un utilizzo elevato della memoria può indicare che è allocata troppa memoria a Java.
% disco utilizzato	80	90	Assicurati che il disco non sia pieno.

Note aggiuntive:

I sistemi con più di un core possono gestire carichi 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 di CPU in uso prima che un sistema riscontri un peggioramento delle prestazioni viene scalata in base al numero di core CPU nel sistema. In altre parole, un sistema single-core può avere prestazioni scarse quando la CPU è utilizzata all'80%, mentre un host a sedici core può essere comunque 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.