Beachten Sie, dass Sie sich gerade die Looker-Dokumentation ansehen. Die Looker Studio-Dokumentation finden Sie unter https://support.google.com/looker-studio.

Diese Seite wurde von der Cloud Translation API übersetzt.

Looker-Monitoring

Das Monitoring von Looker-Anwendungen ist zwar nicht unbedingt erforderlich, sollte aber auf vom Kunden gehosteten Instanzen eingerichtet werden. In dem seltenen Fall, dass 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 die entsprechenden Überwachungsinformationen ab dem Zeitpunkt des Vorfalls bereitstellen.

Anwendungsmonitoring

URL

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

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

https://instance_name.looker.com/alive

Wenn Ihre Instanz auf eine Webanfrage antworten kann, erhalten Sie den HTTP-Statuscode 200 OK.
Hängen Sie /availability an die URL Ihrer Looker-Instanz an:

https://instance_name.looker.com/availability

Diese URL führt eine umfassendere Prüfung mehrerer zugrunde liegender Subsysteme durch und gibt als Antwort den HTTP-Statuscode "200 OK" zurück, wenn alles in Ordnung ist.

JMX

Die virtuelle Java-Maschine, 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 Core-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 einen Abschnitt nach der Zeile hinzu, die mit -Xms$JAVAMEM beginnt:

  -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 --no-daemonise festgelegt haben, fügen Sie einen Abschnitt nach der Zeile hinzu, die mit -Xms$JAVAMEM beginnt:

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

Verzeichnis `.lookerjmx` erstellen

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

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

JMX-Dateien erstellen

Erstellen Sie mit Ihrem bevorzugten Texteditor eine Datei im neuen Verzeichnis namens jmxremote.access mit dem folgenden Inhalt. Sie können diese Datei an Ihre Umgebung anpassen:

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

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

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. Achten Sie darauf, dies *als Looker-Nutzer und nicht als Root* auszuführen:

cd ~/looker
./looker restart

Ihre Looker-Instanz ist nun für die JMX-Remote-Überwachung an Port 9910 mit dem von Ihnen angegebenen Passwort konfiguriert. Möglicherweise müssen Sie Ihre Firewalleinstellungen oder Netzwerk-ACLs ändern, damit Ihr Monitoring-Server über diesen Port auf das Netzwerk zugreifen kann.

Host monitoring

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

CPU-Auslastung: Auslastung und prozentuale CPU-Auslastung
Arbeitsspeicherauslastung: Insgesamt verwendet und verwendeter Swap
Laufwerksnutzung

Benachrichtigungsgrenzwerte

Legen Sie zuerst einen Ausgangswert fest, um gute Schwellenwerte für Benachrichtigungen festzulegen. 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 verwenden Looker möglicherweise jede Woche während der Geschäftszeiten in einem stabilen, wiederholbaren Muster. Andere setzen Looker möglicherweise zu bestimmten Zeiten (z. B. zum Monatsende) intensiver ein.

Benachrichtigungen sollten im Allgemeinen nur für Ereignisse gesendet werden, bei denen eine Aktion möglich ist. Das Senden von Benachrichtigungen, wenn nichts erledigt werden muss, verschleiert die Wichtigkeit wichtiger Benachrichtigungen.

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 Einzelkernsystem sollte die Last im Allgemeinen 1 oder weniger betragen. Eine anhaltend hohe Belastung führt zu schlechter Leistung.
Verwendete CPU in %	80	90	Eine hohe CPU-Auslastung führt zu schlechter Leistung.
Verwendeter Arbeitsspeicher in %	60	70	Eine hohe Arbeitsspeichernutzung kann darauf hinweisen, 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 mehr als einem Kern können hohe CPU-Lasten ohne Leistungseinbußen bewältigen. Als Faustregel gilt, dass die dauerhafte Last nicht größer sein sollte als die Anzahl der Prozessorkerne.
Der Prozentsatz der Gesamt-CPU-Zeit, der genutzt wird, bevor eine Leistungsbeeinträchtigung auftritt, wird mit der Anzahl der CPU-Kerne im System skaliert. Mit anderen Worten: Ein Einzelkernsystem kann eine schlechte Leistung aufweisen, wenn die CPU zu 80% ausgelastet ist, während ein Host mit 16 Kernen bei einer Auslastung von 95% noch verwendbar ist.
Eine hohe dauerhafte 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.