Looker-Monitoring

Das Monitoring von Looker-Anwendungen ist zwar nicht unbedingt erforderlich, sollte aber auf vom Kunden gehosteten Instanzen eingerichtet werden. In seltenen Fällen, in denen ein Problem mit Ihrem Server auftritt, ist es für Looker oft viel schwieriger oder unmöglich, Ihnen bei der Behebung des Problems zu helfen, es sei denn, Sie können entsprechende Monitoring-Informationen zum Zeitpunkt des Auftretens des Problems zur Verfügung stellen.

Anwendungsmonitoring

URL

Es gibt zwei einfache Möglichkeiten, zu prüfen, ob Ihre Looker-Instanz ausgeführt wird.

  1. Hängen Sie /alive an die URL Ihrer Looker-Instanz an:

    https://instance_name.looker.com/alive

    Wenn Ihre Instanz auf eine Webanfrage reagieren kann, erhalten Sie den HTTP-Statuscode 200 OK.

  2. Hängen Sie /availability an die URL Ihrer Looker-Instanz an:

    https://instance_name.looker.com/availability

    Über diese URL wird eine umfassendere Prüfung mehrerer zugrunde liegender Subsysteme durchgeführt. Wenn alles in Ordnung ist, wird auch der HTTP-Statuscode „200 OK“ zurückgegeben.

JMX

Die Java Virtual Machine, auf der Looker ausgeführt wird, kann über JMX überwacht werden.

Viele Monitoring-Anwendungen wie Zabbix und Nagios unterstützen JMX. Weitere Informationen finden Sie in der Dokumentation Ihrer Monitoring-Anwendung.

Looker-Startskript bearbeiten

Wenn Sie das JMX-Monitoring aktivieren möchten, müssen Sie das Looker-Startskript bearbeiten. Standardmäßig lautet der Name:

/home/looker/looker/looker

Suchen Sie nach den Java-Startparametern:

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}

Ab Looker 6.18 wurde die Looker-JAR-Datei in zwei separate JAR-Dateien aufgeteilt: die Looker-Kern-JAR-Datei und eine Looker-Abhängigkeits-JAR-Datei. Beim Starten startet die JAR-Datei des Kerns automatisch die JAR-Datei der Abhängigkeiten. Beide JAR-Dateien müssen sich im selben Verzeichnis befinden, damit die JAR-Datei des Hauptprogramms die JAR-Datei der Abhängigkeiten finden und starten kann.

Standardmäßig ist die --no-daemonise-Startoption nicht festgelegt. Wenn Sie die Option --no-daemonise nicht festgelegt haben, fügen Sie nach der Zeile, die mit -Xms$JAVAMEM beginnt, einen Abschnitt hinzu:

  -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 \

Wenn Sie die Startoption für --no-daemonise festgelegt haben, fügen Sie nach der Zeile, die mit -Xms$JAVAMEM beginnt, einen Abschnitt hinzu:

  -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 \

Erstellen Sie das Verzeichnis .lookerjmx.

Erstellen Sie als Nächstes das Verzeichnis .lookerjmx im Basisverzeichnis Ihres Looker-Nutzers und legen Sie Berechtigungen fest:

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

JMX-Dateien erstellen

Erstellen Sie mit Ihrem bevorzugten Texteditor im neuen Verzeichnis eine Datei namens jmxremote.access mit folgendem Inhalt (kann für Ihre Umgebung angepasst werden):

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

Erstellen Sie als Nächstes im selben Verzeichnis eine Datei namens jmxremote.password mit folgendem Inhalt und verwenden Sie dabei Ihre eigenen sicheren Passwörter:

monitorRole   some_password_here
controlRole   some_password_here

Berechtigungen festlegen

Achten Sie darauf, dass Java (und damit Looker) nicht gestartet wird, wenn die Dateiberechtigungen es jemandem außer dem Looker-Nutzer erlauben, die Passwortdatei zu lesen.

chmod 400 jmxremote.*

Looker neu starten

Looker muss neu gestartet werden, um JMX zu aktivieren. Führen Sie diesen Befehl *als Looker-Nutzer und nicht als Root aus*:

cd ~/looker
./looker restart

Ihre Looker-Instanz ist jetzt für das Remote-JMX-Monitoring über Port 9910 mit dem von Ihnen angegebenen Passwort konfiguriert. Möglicherweise müssen Sie Ihre Firewalleinstellungen oder Netzwerk-ACLs ändern, damit Ihr Monitoring-Server Netzwerkzugriff auf diesen Port erhält.

Hostüberwachung

Wir empfehlen, für jeden Host, auf dem die Looker-Anwendung ausgeführt wird, mindestens die folgenden Leistungsmesswerte zu erfassen, in Diagrammen darzustellen und Benachrichtigungen zu senden:

  • CPU-Auslastung:Auslastung und prozentuale CPU-Auslastung
  • Arbeitsspeicherauslastung:Gesamtverbrauch und Auslagerung
  • Laufwerksnutzung

Grenzwerte für Benachrichtigungen

Um sinnvolle Grenzwerte für Benachrichtigungen festzulegen, müssen Sie zuerst einen Referenzwert festlegen. Erfassen Sie Leistungsdaten, wenn Ihre Looker-Instanz mit einer normalen Auslastung ausgeführt wird. Sehen Sie sich die Leistungsdiagramme an und achten Sie auf die Spitzen. Wie lange Sie brauchen, um die Baselines festzulegen, hängt von Ihrem Unternehmen und Ihrem Looker-Nutzungsverhalten ab. Einige Unternehmen nutzen Looker möglicherweise jede Woche während der Geschäftszeiten in einem stabilen, wiederholbaren Muster. Andere Nutzer verwenden Looker möglicherweise zu bestimmten Zeiten intensiver, z. B. am Ende jedes Monats.

Im Allgemeinen sollten Benachrichtigungen nur für Ereignisse gesendet werden, die Maßnahmen erfordern. Wenn Benachrichtigungen gesendet werden, obwohl nichts zu tun ist, wird die Bedeutung wichtiger Benachrichtigungen verdeckt.

Die folgenden Grenzwerte können als Ausgangspunkt für Benachrichtigungen verwendet werden. Wenn die folgenden Werte 15 Minuten oder länger überschritten werden, ist möglicherweise manuelles Eingreifen erforderlich.

Messwert Warnung Kritisch Kommentare
CPU-Auslastung 2 4 Bei einem Ein-Kern-System sollte die Auslastung in der Regel 1 oder weniger betragen. Eine anhaltende hohe Auslastung führt zu einer schlechten Leistung.
Verwendete CPU in % 80 90 Eine hohe CPU-Auslastung führt zu einer schlechten Leistung.
Verwendeter Arbeitsspeicher in % 60 70 Eine hohe Arbeitsspeichernutzung kann darauf hindeuten, dass Java zu viel Arbeitsspeicher zugewiesen wird.
Verwendeter Festplattenspeicher in % 80 90 Achten Sie darauf, dass das Laufwerk nicht voll ist.

Zusätzliche Hinweise:

  • Systeme mit mehreren Kernen können hohe CPU-Auslastungen bewältigen, ohne dass die Leistung beeinträchtigt wird. Als Faustregel gilt, dass die dauerhafte Auslastung nicht höher als die Anzahl der Prozessorkerne sein sollte.
  • Der Prozentsatz der gesamten CPU-Zeit, der genutzt wird, bevor es zu einer Leistungsminderung des Systems kommt, skaliert mit der Anzahl der CPU-Kerne im System. Mit anderen Worten: Ein System mit einem einzelnen Kern kann eine schlechte Leistung haben, wenn die CPU zu 80% ausgelastet ist, während ein Host mit 16 Kernen bei einer Auslastung von 95% noch verwendet werden kann.
  • Eine hohe, anhaltende CPU-Auslastung kann durch Aktualisieren der Hosthardware oder durch ein Upgrade auf eine größere Instanz behoben werden. Manchmal können große Mengen an geplanten Looks oder Tabellen, die aus langen Abfragen abgeleitet wurden, reduziert oder effizienter gestaltet werden, um die Leistung zu verbessern.

Nächste Schritte

Nachdem Sie das Monitoring eingerichtet haben, können Sie Looker-Sicherungen einrichten.