Surveiller Looker

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 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, à moins que vous ne puissiez fournir des informations de surveillance appropriées au moment 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.

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 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 de base 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 --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 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 l'éditeur de texte de votre choix, créez un fichier dans le nouveau répertoire jmxremote.access avec le contenu suivant (que vous pouvez personnaliser en fonction de 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 du fichier permettent à quiconque sauf l'utilisateur Looker de lire le fichier de mots de passe.

chmod 400 jmxremote.*

Redémarrer Looker

Vous devez redémarrer Looker 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 de vos listes de contrôle d'accès (LCA) pour permettre au serveur de surveillance d'obtenir un accès 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 avec votre instance Looker exécutée dans 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 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 général, les alertes ne doivent être envoyées que pour des événements exploitables. L'envoi d'alertes lorsqu'aucune action n'est requise de votre part 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.

Remarques supplémentaires :

• Les systèmes à 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 qu'un système ne subisse une dégradation des performances évolue 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 de requêtes longues pour améliorer les performances.

Étapes suivantes

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