Surveiller Looker

Même si la surveillance des applications Looker ne vous semble pas obligatoire, il est très important de la configurer sur des instances hébergées par le client. Dans les rares cas où un problème survient sur votre serveur, il est souvent plus difficile, voire impossible, pour Looker de vous aider à résoudre le problème, sauf si vous fournissez des informations de surveillance appropriées au moment de l'incident.

Surveillance des applications

URL

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

  1. Ajoutez /alive à l'URL de votre instance Looker comme ceci:

    https://instance_name.looker.com/alive

    Si votre instance est capable de répondre à une requête Web, vous recevez un code d'état HTTP 200 OK.

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

    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 la version 6.18 de Looker, le fichier JAR de Looker a été divisé en deux fichiers JAR distincts: le fichier JAR principal de Looker et un fichier JAR des dépendances 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

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

Dans 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 de fichier permettent à l'exception de l'utilisateur Looker de lire le fichier de mot de passe.

chmod 400 jmxremote.*

Redémarrer Looker

Vous devez redémarrer Looker pour activer JMX. Assurez-vous d'exécuter ceci *en tant qu'utilisateur Looker et non en tant qu'utilisateur 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 vos listes de contrôle d'accès réseau pour permettre à votre 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 au moins sur les métriques de performances suivantes:

  • CPU Utilization (Utilisation du processeur) : charge et pourcentage d'utilisation du processeur
  • Memory Utilization (Utilisation de la mémoire) : nombre total d'utilisations et d'échanges utilisés
  • Utilisation du disque

Seuils d'alerte

Pour établir des seuils d'alerte fiables, commencez par établir une référence. Collectez des données sur les performances avec votre instance Looker exécutée à 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 de bureau. D'autres peuvent avoir recours à Looker de manière intensive à des moments précis (à la fin de chaque mois, par exemple).

En général, les alertes ne doivent être envoyées que pour des événements exploitables. Le fait d'envoyer des alertes lorsque vous n'avez rien à faire masque l'importance des alertes critiques.

Les seuils suivants peuvent être utilisés comme point de départ des alertes. Si les valeurs suivantes sont dépassées pendant au moins 15 minutes, 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 à cœur unique. Une charge élevée et soutenue entraîne de mauvaises performances.
Pourcentage d'utilisation du processeur 80 90 Une utilisation élevée 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 trop grande quantité 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 à plusieurs cœurs peuvent gérer des charges de processeur importantes sans réduire les performances. En règle générale, la charge soutenue ne doit pas être supérieure au nombre de cœurs de processeur.
  • Le pourcentage de temps CPU total utilisé avant la dégradation des performances d'un système évolue en fonction du nombre de cœurs de processeur dans le système. En d'autres termes, un système à un 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 utilisable à 95 %.
  • Vous pouvez y remédier en mettant à jour le matériel hôte ou en passant à une instance plus grande. Parfois, un grand nombre de Looks programmés ou de tables dérivées de longues requêtes peuvent être réduits ou rendus plus efficaces afin d'améliorer les performances.

Étapes suivantes

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