Stai visualizzando la documentazione per Looker 22.16. La documentazione più recente è disponibile qui.

Monitoraggio di Looker

Sebbene il monitoraggio delle applicazioni di Looker possa non sembrare strettamente necessario, è molto importante da configurare. Nella rara situazione in cui si verifica un problema con il server, spesso è molto più difficile o impossibile per Looker contribuire a risolvere il problema, a meno che tu non fornisca le informazioni di monitoraggio appropriate al 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 in questo modo:

https://instance_name.looker.com/alive

Se la tua 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 diversi sottosistemi sottostanti e risponderà con un codice di stato HTTP 200 OK se tutto funziona correttamente.

JMX

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

Molte applicazioni di monitoraggio come Zabbix e Nagios supportano JMX. Per scoprire di più, consulta la documentazione della tua applicazione di monitoraggio.

Modifica lo script di avvio di Looker

Per abilitare il monitoraggio JMX, devi modificare il tuo 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 separati: il file JAR principale di Looker e un file JAR delle dipendenze di Looker. All'avvio, il file JAR principale inizierà automaticamente il file JAR delle dipendenze. Entrambi i file JAR devono trovarsi nella stessa directory in modo che il file JAR di base 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 impostato 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 sotto la home directory dell'utente di Looker e imposta le autorizzazioni:

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

Creare i file JMX

Utilizzando il tuo editor di testo preferito, crea un file nella nuova directory denominato jmxremote.access con il seguente contenuto (puoi personalizzarlo per il 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 i contenuti seguenti, utilizzando le tue password sicure:

monitorRole   some_password_here
controlRole   some_password_here

Impostazione delle autorizzazioni

Assicurati che Java (e quindi Looker) non si avvii se le autorizzazioni del file consentono a tranne l'utente di Looker di leggere il file della password.

chmod 400 jmxremote.*

Riavvia Looker

È necessario riavviare Looker per attivare JMX. Assicurati di eseguire questa operazione *come utente Looker e non root*:

cd ~/looker
./looker restart

La tua istanza di Looker è ora configurata per il monitoraggio JMX remoto sulla porta 9910, utilizzando la password fornita. Potrebbe essere necessario modificare le impostazioni del firewall o gli ACL di rete per consentire al server di monitoraggio di accedere alla rete su questa porta.

Monitoraggio host

Per ogni host che esegue l'applicazione Looker, ti consigliamo di raccogliere, rappresentare graficamente e generare avvisi su almeno le seguenti metriche delle prestazioni:

Utilizzo della CPU: carico e percentuale di CPU utilizzata.
Utilizzo della memoria: totale utilizzato e scambio utilizzato.
Utilizzo del disco

Soglie di avviso

Per stabilire buone soglie di avviso, prima stabilisci una base di riferimento. Raccogli dati sulle prestazioni con l'istanza di 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 basi dipende dalla tua attività e dai tuoi modelli di utilizzo di Looker. Alcune aziende possono utilizzare Looker in modo stabile e ripetibile ogni settimana durante l'orario di apertura. Altri utenti possono utilizzare Looker in modo più frequente in momenti specifici (ad esempio, la fine di ogni mese).

In generale, gli avvisi dovrebbero essere inviati solo per gli eventi per cui è possibile intraprendere azioni. L'invio di avvisi quando non è necessario fare nulla maschera l'importanza degli avvisi importanti.

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

Metrica	Avviso	Critico	Commenti
Carico CPU	2	4	Il carico dovrebbe essere generalmente pari o inferiore a 1 per un sistema single-core. Un carico elevato e prolungato comporta prestazioni scarse.
% di CPU utilizzata	80	90	Un utilizzo elevato della CPU porta a prestazioni scarse.
% memoria utilizzata	60	70	Un utilizzo elevato della memoria può indicare che troppa memoria è allocata a Java.
% di disco utilizzata	80	90	Assicurati che il disco non sia pieno.

Note aggiuntive

I sistemi con più di un core possono gestire carichi di CPU elevati senza prestazioni ridotte. La regola generale è che il carico prolungato non deve essere maggiore del numero di core del processore.
La percentuale di tempo totale di CPU in uso prima che un sistema subisca un degrado delle prestazioni con il numero di core CPU del sistema. In altre parole, un sistema single-core potrebbe avere prestazioni scarse quando la CPU è utilizzata all'80%, mentre un host sedici core può comunque essere utilizzato con un utilizzo del 95%.
Un elevato utilizzo prolungato della CPU può essere rettificato aggiornando l'hardware host o eseguendo l'upgrade a un'istanza più grande. A volte un numero elevato di Look pianificati o di tabelle derivate con query lunghe può essere ridotto o reso più efficiente per migliorare le prestazioni.

Passaggi successivi

Dopo aver configurato il monitoraggio, è tutto pronto per configurare i backup di Looker.