Looker Monitoring

Bien que la surveillance des applications Looker ne semble pas strictement nécessaire, il est très important de la configurer sur les instances hébergées par le client. Dans de rares cas, il peut arriver que votre serveur rencontre un problème. Il est alors souvent beaucoup plus difficile, voire impossible, pour Looker de vous aider à le résoudre, sauf si vous pouvez fournir des informations de surveillance appropriées datant du moment de l'incident.

Surveillance des applications

URL

Il existe deux façons simples de vérifier que votre instance Looker s'exécute.

  1. 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 recevrez un code d'état HTTP 200 OK.

  2. Ajoutez /availability à l'URL de votre instance Looker comme suit:

    https://instance_name.looker.com/availability

    Cette URL effectue une vérification plus complète de plusieurs sous-systèmes sous-jacents et renvoie également un code d'état HTTP 200 OK si tout va bien.

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 votre script de démarrage 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 Looker 6.18, le fichier JAR de Looker a été divisé en deux fichiers JAR distincts: le fichier JAR principal de Looker et un fichier JAR de dépendances de Looker. Au démarrage, le fichier JAR principal lance automatiquement le fichier JAR des dépendances. Les deux fichiers JAR doivent se trouver dans le même répertoire pour que le fichier JAR principal puisse trouver et démarrer le fichier JAR des dépendances.

Par défaut, l'option de démarrage de --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

Créez ensuite le répertoire .lookerjmx dans le répertoire d'accueil de votre utilisateur Looker, puis définissez les autorisations:

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

Créer les fichiers JMX

À l'aide de 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

Assurez-vous que Java (et donc Looker) ne démarre pas si les autorisations de fichier permettent à toute personne sauf l'utilisateur Looker de lire le fichier de mot de passe.

chmod 400 jmxremote.*

Redémarrer Looker

Looker doit être redémarré pour activer JMX. Veillez à exécuter cette commande *en tant qu'utilisateur Looker et non en tant qu'utilisateur racine*:

cd ~/looker
./looker restart

Votre instance Looker est désormais 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 les ACL réseau pour autoriser votre serveur de surveillance à accéder au réseau sur ce port.

Surveillance de l'hôte

Pour chaque hôte exécutant l'application Looker, nous vous recommandons de collecter, de représenter graphiquement et d'envoyer des alertes sur au moins les métriques de performances suivantes:

  • Utilisation du processeur:charge et pourcentage d'utilisation du processeur
  • Memory Utilization (Utilisation de la mémoire) : mémoire totale utilisée et mémoire de swap utilisée
  • Utilisation du disque

Seuils d'alerte

Pour définir des seuils d'alerte appropriés, commencez par établir une référence. Collectez des données de performances lorsque votre instance Looker s'exécute sous une charge normale. Examinez les graphiques de performances et observez les pics. La durée nécessaire pour établir les bases de référence dépend de votre entreprise et de vos habitudes d'utilisation de Looker. Certaines entreprises peuvent utiliser Looker de manière stable et reproductible chaque semaine pendant les heures ouvrées. D'autres peuvent utiliser Looker plus intensivement à des moments spécifiques (par exemple, à la fin de chaque mois).

En règle générale, les alertes ne doivent être envoyées que pour les événements pouvant être traités. Envoyer des alertes alors qu'aucune action n'est requise masque l'importance des alertes critiques.

Les seuils suivants peuvent être utilisés comme point de départ pour les 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 La charge doit généralement être inférieure ou égale à 1 pour un système à un seul cœur. Une charge élevée prolongée entraîne des performances médiocres.
Pourcentage d'utilisation du processeur 80 90 Une utilisation élevée du processeur entraîne de mauvaises performances.
Pourcentage de mémoire utilisée 60 70 Une utilisation élevée de la mémoire peut indiquer qu'trop de mémoire est allouée à Java.
Espace disque utilisé (en %) 80 90 Assurez-vous 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 réduire les performances. En règle générale, la charge soutenue ne doit pas dépasser le nombre de cœurs de processeur.
  • Le pourcentage du temps CPU total utilisé avant que les performances d'un système ne se dégradent varie en fonction du nombre de cœurs de processeur du système. En d'autres termes, un système à un seul cœur peut présenter de mauvaises performances lorsque le processeur est utilisé à 80 %, tandis qu'un hôte à seize cœurs peut toujours être utilisé à 95% d'utilisation.
  • Pour corriger une utilisation élevée et soutenue du processeur, vous pouvez mettre à jour le matériel hôte ou passer à une instance plus grande. Il est parfois possible de réduire ou d'optimiser un grand nombre de vues planifiées ou de tables dérivées à partir de requêtes longues pour améliorer les performances.

Étapes suivantes

Une fois la surveillance configurée, vous pouvez configurer les sauvegardes Looker.