Notez que vous consultez la documentation Looker. Pour accéder à la documentation sur Looker Studio, consultez la page https://support.google.com/looker-studio.

Surveillance de Looker

Même si la surveillance des applications Looker ne semble pas être obligatoire, elle est très importante. Dans les rares cas où un problème survient sur votre serveur, il est souvent beaucoup plus difficile, voire impossible, pour Looker de vous aider à résoudre le problème, sauf si vous pouvez fournir les informations de surveillance appropriées à partir de l'incident.

Surveillance des applications

URL

Il existe deux façons simples de vérifier que votre instance Looker est en cours d'exécution.

Ajoutez /alive à l'URL de votre instance Looker comme suit:

https://instance_name.looker.com/alive

Si votre instance peut répondre à une requête Web, vous recevez un code d'état HTTP 200 OK.
Ajoutez /availability à l'URL de votre instance Looker comme suit:

https://instance_name.looker.com/availability

Cette URL vérifie de manière plus complète plusieurs sous-systèmes sous-jacents et répond également avec un code d'état HTTP 200 OK si tout fonctionne correctement.

JMX

La machine virtuelle Java qui exécute Looker peut être surveillée via JMX.

De nombreuses applications de surveillance telles que Zabbix et Nagios sont compatibles avec JMX. Pour en savoir plus, consultez la documentation de votre application de surveillance.

Modifier le script de démarrage de Looker

Pour activer la surveillance JMX, vous devez modifier le script de démarrage de Looker. Par défaut, il est nommé:

/home/looker/looker/looker

Recherchez les paramètres de démarrage 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}

À partir de la version 6.18 de Looker, le fichier JAR Looker a été divisé en deux fichiers JAR distincts: le fichier JAR principal Looker et le fichier JAR de dépendances Looker. Au démarrage, le fichier JAR principal lancera automatiquement le fichier JAR des dépendances. Les deux fichiers JAR doivent se trouver dans le même répertoire afin que le fichier JAR principal puisse trouver et démarrer le fichier JAR des dépendances.

Par défaut, l'option de démarrage --no-daemonise n'est pas définie. Si vous n'avez pas défini l'option --no-daemonise, ajoutez une section après la ligne commençant par -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 \

Si vous avez défini l'option de démarrage --no-daemonise, ajoutez une section après la ligne commençant par -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 \

Créer le répertoire `.lookerjmx`

Ensuite, créez le répertoire .lookerjmx sous le répertoire d'accueil de l'utilisateur Looker et définissez les autorisations:

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

Créer les fichiers JMX

Dans votre éditeur de texte préféré, créez un fichier dans le nouveau répertoire nommé jmxremote.access avec le contenu suivant (vous pouvez le personnaliser pour votre environnement):

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

Créez ensuite un fichier nommé jmxremote.password dans le même répertoire avec le contenu suivant en utilisant vos propres mots de passe sécurisés:

monitorRole   some_password_here
controlRole   some_password_here

Définir des autorisations

Faites en sorte que Java (et donc Looker) ne démarre pas si les autorisations de fichier permettent à n'importe qui à l'exception de l'utilisateur Looker de lire le fichier de mot de passe.

chmod 400 jmxremote.*

Redémarrer Looker

Redémarrez Looker pour activer JMX. Assurez-vous d'exécuter cette commande en tant qu'utilisateur Looker et non en mode root*:

cd ~/looker
./looker restart

Votre instance Looker est maintenant configurée pour la surveillance JMX à distance sur le port 9910 à l'aide du mot de passe que vous avez fourni. Vous devrez peut-être modifier les paramètres de votre pare-feu ou de vos LCA réseau pour permettre à votre serveur de surveillance d'accéder au réseau sur ce port.

Surveillance de l'hôte

Pour chaque hôte qui exécute l'application Looker, nous vous recommandons de collecter, de représenter et de créer des alertes sur au moins les métriques de performances suivantes:

Utilisation du processeur:charge et pourcentage de processeur utilisés
Utilisation de la mémoire:utilisation totale et utilisation totale
Utilisation du disque

Seuils d'alerte

Pour établir des seuils d'alerte appropriés, établissez d'abord une référence. Collectez des données sur les performances avec une instance Looker exécutée sous une charge normale. Examinez les graphiques de performances et observez les pics. La durée nécessaire pour établir les références dépend de votre entreprise et de vos habitudes d'utilisation de Looker. Certaines entreprises peuvent utiliser Looker de manière stable et reproductible toutes les semaines pendant les heures de bureau. D'autres utilisent Looker plus fréquemment à des heures spécifiques (comme la fin de chaque mois).

En général, les alertes ne doivent être envoyées que pour des événements exploitables. L'envoi d'alertes lorsqu'il n'y a rien à faire masque l'importance des alertes critiques.

Les seuils suivants peuvent servir de point de départ pour définir des alertes. Lorsque les valeurs suivantes sont dépassées pendant 15 minutes ou plus, une intervention manuelle peut être nécessaire.

Métrique	Avertissement	Critique	Commentaires
Charge du processeur	2	4	Pour un système à cœur unique, la charge doit généralement être inférieure ou égale à 1. Une charge élevée et durable entraîne des performances médiocres.
Pourcentage d'utilisation du processeur	80	90	Une utilisation intensive du processeur entraîne de mauvaises performances.
Pourcentage d'utilisation de la mémoire	60	70	Une utilisation élevée de la mémoire peut indiquer qu'une quantité trop importante de mémoire est allouée à Java.
Pourcentage d'utilisation du disque	80	90	Vérifiez que le disque n'est pas saturé.

Remarques supplémentaires :

Les systèmes comportant plusieurs cœurs peuvent gérer des charges de processeur élevées sans baisse de performances. En règle générale, une charge soutenue ne doit pas être supérieure au nombre de cœurs de processeur.
Pourcentage de temps CPU total utilisé avant qu'un système ne dégrade la dégradation des performances en fonction du nombre de cœurs de processeur dans le système. En d'autres termes, un système à cœur unique peut avoir de mauvaises performances lorsque le processeur est utilisé à 80 %, tandis qu'un hôte à 16 cœurs peut être utilisable à 95% d'utilisation.
Pour rectifier une utilisation soutenue du processeur, vous pouvez mettre à jour le matériel hôte ou passer à une instance plus grande. Parfois, un grand nombre de styles programmés ou de tables dérivées de requêtes longues peuvent être réduits ou améliorés pour améliorer les performances.

Étapes suivantes

Après avoir configuré la surveillance, vous êtes prêt à configurer les sauvegardes Looker.