Intrexx Server Monitoring mit Hilfe der
JMX-Konsole
In diesem Workshop möchten wir Ihnen die sogenannte JMX-Konsole etwas näher bringen. Mit den Java Management Extensions (JMX) stellt sie eine Technologie zur Verfügung, die es erlaubt, in Java programmierte Anwendungen zu überwachen und zu verwalten. Die verschiedenen Aufgaben übernehmen hierbei sogenannte MBeans. Mit diesem Werkzeug bieten sich dem Administrator noch umfangreichere Möglichkeiten zur Überwachung und Wartung des Intrexx-Servers.
Aus Sicherheitsgründen ist JMX für Ihr Intrexx-Portal standardmäßig deaktiviert, daher muss das Intrexx-Portal zunächst für den Einsatz der JMX-Konsole eingerichtet werden:
Erstellen Sie dazu zunächst ein Sicherung der Datei „portal.wcf“ im Verzeichnis <xtreme>\org\portalname\internal\cfg. Schauen Sie dann in der „portal.wcf“ nach dem Abschnitt „Java Additional Parameters“. Prüfen Sie, welche Ziffer der letzte Parameter hat. Am Ende der „portal.wcf“ befinden sich einige auskommentierte Zeilen, bei denen es sich um weitere „Java Additional Parameters“ handelt. Entfernen Sie in diesen Zeilen die # und tragen Sie einen freien Port zur Kommunikation zwischen der JConsole und dem Intrexx Server ein. Stellen Sie zudem sicher, dass die Nummerierung der „Java Additional Parameters“ in diesen drei Zeilen korrekt fortgeführt wird.
Bsp.:
# Java Additional Parameters
#wrapper.java.additional.1=
wrapper.java.additional.1=-Dde.uplanet.jdbc.dump=true
wrapper.java.additional.2=-Djavax.net.ssl.trustStore=internal/cfg/cacerts
wrapper.java.additional.3=-Djava.io.tmpdir=internal/tmp
wrapper.java.additional.4=-Dfile.encoding=UTF-8
wrapper.java.additional.5=-Dlog4j.configuration=file:internal/cfg/log4j.properties
wrapper.java.additional.6=-Djava.security.auth.login.config=file:internal/cfg/LucyAuth.cfg
wrapper.java.additional.7=-server
…
…
…
# To enable JMX, uncomment these lines, replace <port number> and
# make sure that the N+x placeholders are set to unique values.
wrapper.java.additional.8=-Dcom.sun.management.jmxremote.port=9001
wrapper.java.additional.9=-Dcom.sun.management.jmxremote.authenticate=false
wrapper.java.additional.10=-Dcom.sun.management.jmxremote.ssl=false
wrapper.working.dir=c:\xtreme\org\myportal
Nach einem Neustart des Portaldienstes ist die JMX-Konsole einsatzbereit. Zum Start der JMX-Konsole rufen Sie die „jconsole.bat“ (Linux: jconsole.sh) aus dem Verzeichnis <xtreme>\bin\windows (Linux: opt/xtreme/bin/linux) auf. Am Anmeldebildschirm melden Sie sich mit servername:port an. Ein Benutzername und Kennwort sind bei dieser Verbindung nicht notwendig. Diese Art der Anmeldung sollte daher nicht dauerhaft eingesetzt werden, da es jeder Person, der die Serveradresse und der Port bekannt sind, möglich ist, eine JMX-Verbindung aufzubauen. Zu Entwicklungs- und Diagnosezwecken ist dies jedoch vertretbar. Wenn Sie die JMX-Konsole also nicht benötigen, dann kommentieren Sie die entsprechenden Zeilen wieder aus und starten Sie den Portaldienst neu.
Nach dem Aufruf der JMX-Konsole öffnet sich nun ein neues Fenster. Dies ist das Überwachungsfenster mit diversen Reitern. Auf dem ersten Reiter sehen Sie eine Vielzahl an Diagrammen, die verschiedene Werte wie CPU-Auslastung und die Anzahl an Live-Threads anzeigen. Die Diagramme werden sekündlich aktualisiert. Somit ist eine genaue Verfolgung der Ressourcenauslastung möglich.
Auf den weiteren Reitern Memory, Threads, Classes und VM-Summary lassen sich zu den entsprechenden Themen weitere Informationen anzeigen und analysieren. Der letzte Reiter ist bezeichnet mit MBeans. Innerhalb dieses Reiters findet man eine Übersicht über die implementierten MBeans, die standardmäßig in JMX integriert sind. Zusätzlich dazu befinden sich im Ordner de.uplanet.lucy.server.management spezifische MBeans die von United Planet implementiert wurden und spezielle Portalanalysen und –methoden für Administrationsaufgaben zur Verfügung stellen.
Overview
Memory
In dieser Übersicht können Sie das Speicherverhalten Ihres Portalservers beobachten. Dies kennen Sie evtl. bereits vom System-Monitor des Portalmanagers. In der JMX-Konsole lassen sich diese Werte jedoch exakter ablesen. Der Speicherverbrauch wird in der Regel als Zickzackkurve dargestellt. Die Java Maschine führt automatische Garbage Collections durch, um immer wieder ausreichend Speicher frei zu halten. Sie können hier bei Bedarf auch manuelle Garbage Collections (GC) durchführen, um Speicher frei zu geben. Die Infos beinhalten z.B. den aktuellen Speicherverbrauch des Heap, den maximal zugeordneten Speicher für den Heap, maximale Speicherbelegung durch den Heap und Informationen zum Garbage Collector.
Threads
Bei den Threads interessieren in erster Linie die WebConnectorWorkerThreads. Die Informationen hier können hilfreich bei der Problemsuche sein, falls das Portal im Browser nicht mehr erreichbar ist, der Webserver (IIS / Tomcat) aber korrekt läuft. Idealerweise ist der Status eines WebConnectorThreads auf „waiting“ – das heißt er ist bereit, um Anfragen aus dem Browser zu beantworten. In der Grafik wird die aktuelle Anzahl an Live Threads sowie die höchste Anzahl an Live Threads seit dem letzten Portaldienststart angezeigt.
Classes
Hier wird die Anzahl der aktuell in den Speicher geladenen Klassen angezeigt, sowie die Anzahl der insgesamt geladenen sowie entladenen Klassen.VM Summary
Hier finden Sie Informationen zu Ihrem Portalserver wie z.B. Uptime, geladene Java-Klassen, Speicherverbrauch, Live Threads etc.
MBeans
Alle MBeans hier zu erwähnen würde den Rahmen des Werkstattbeitrags sprengen, im Folgenden werden deshalb einige spezifische Logging-MBeans von United Planet kurz vorgestellt und erläutert.
de.uplanet.lucy.server.management - Logging
| Attribut | Datentyp | Beschreibung |
|---|---|---|
| JdbcTrace | Boolean | Wenn true, werden alle an die Datenquelle gestellten Anfragen in die portal.log geschrieben. Somit kann die Dauer der Datenbankabfragen in der Logdatei geprüft werden, was z.B. nützlich sein kann, wenn bei einem Portal ein Performanceproblem besteht. |
| JdbcDumpOnClose | Boolean | Wenn true, werden Informationen (Herkunft, Erzeuger etc.) über nicht geschlossene DB-Verbindungen in die portal.log geschrieben. |
| ThrowExceptionOn-DeprecatedCall | Boolean | Wenn true, wird eine Fehlermeldung beim Aufruf einer deprecated-Methode in die portal.log geschrieben. |
| BpeeDumpContext | Boolean | Wenn true, werden die Bpee-Kontextvariablen und deren Werte in die portal.log geschrieben. |
| Operation | Beschreibung |
|---|---|
| logSeparator / logString | Schreibt Separator oder Text in die portal.log, was bei der Fehlersuche die Übersichtlichkeit des logs verbessert |
| logThreadStacks | Schreibt das Stacktrace der WebConnectorWorkerThreads in die portal.log. Dies kann hilfreich sein um z.B. die Ursache für einen Portalstillstand im Browser zu ermitteln. |
de.uplanet.lucy.server.management - WebConnector
| Attribut | Datentyp | Beschreibung |
|---|---|---|
| Timeout | Long | Timeout des Web-Connectors (in ms, default 10 min). |
| Running | Boolean | Ist der Webconnector aktiv? |
| WorkerThreadCount | Int | Anzahl der zur Verfügung stehenden Workerthreads. |
| AliveWorkerThreadCount | Int | Wieviele Workerthreads sind momentan nutzbar? |
| WatchdogInterval | Long | Überwacht Threads auf Aktivität. Wenn Timeout erreicht wird, wird der Workerthread recycelt. |
| RequestCount | Int | Anzahl der offenen Requests. |
| BusyCount | Int | Anzahl der momentan bearbeiteten Aufgaben. |
| LogRequestProcessingTime | Boolean | Wenn true, wird die Dauer der Ausführung eines Request vom Browser an den WebConnectorThread in Millisekunden in die portal.log geschrieben. Dies kann ebenfalls hilfreich sein, falls Performanceprobleme untersucht werden müssen. |
| Operation | Beschreibung |
|---|---|
| startConnector | Starten des Web-Connectors |
| stopConnector | Stoppen des Web-Connectors |
