WGA-Server per JMX überwachen
Das Kürzel JMX steht für "Java Management Extensions". Kurz beschrieben handelt es sich bei JMX um eine in die Java-Plattform integrierte Funktionalität, mit welcher Java-Programme sowie die Java-Plattform selbst Metriken über ihre "Gesundheit" liefern können. Diese können dann, eventuell sogar über das Netzwerk, mit geeigneten Tools ausgelesen und somit ausgewertet werden.
JMX ist für WGA-Administratoren in doppelter Hinsicht interessant:
Da zu kommt dass ein Java-Server Im Problemfall, in welchem eine Website eventuell nicht mehr reagiert, oft immernoch per JMX erreichbar ist und darüber wichtige Informationen über die Ursache des Problems liefern kann.
JMX ist für WGA-Administratoren in doppelter Hinsicht interessant:
- WGA liefert über JMX spezifische Laufzeit-Informationen, insbesondere über den Zustand der für die Verbindungen zu relationalen Datenbanken verwendeten Verbindungs-Pools
- Die Java-Laufzeit selbst gibt eine Vielzahl von Daten aus, die für die Optimierung der Performance des Systems verwendet werden können
Da zu kommt dass ein Java-Server Im Problemfall, in welchem eine Website eventuell nicht mehr reagiert, oft immernoch per JMX erreichbar ist und darüber wichtige Informationen über die Ursache des Problems liefern kann.
Aktivieren von JMX
Der hier beschriebene Ablauf gilt für die Java-Runtime von Sun Microsystems. Sie benötigen zum Nachvollziehen der hier beschriebenen Funktionalitäten eine volle JDK-Installation. Eine Java-Runtime-Installation alleine (JRE) verfügt nicht über die notwendigen Tools.Für Instruktionen zur Aktivierung dieser Funktionalität bei anderen JVM-Herstellen konsultieren sie bitte deren Dokumentation.
JMX ist ab Version 5 Bestandteil von Java. Es wird per Java-Systemvariablen aktiviert. Hierbei gibt es verschiedene Stufen die sich darin unterscheiden, von wo aus die JMX-Metriken gelesen werden können.
Die simpelste Stufe ist die lokale Aktivierung die über eine einzige Java-Systemvariable ohne Wert erzielt wird. Hier sehen sie die Systemvariable wie sie als Kommandozeilen-Argument direkt an die Java-VM übergeben werden würde:
-Dcom.sun.management.jmxremote
Auf dieser Stufe kann nur ein lokaler Client, der auf der Servermaschine selbst läuft, JMX-Metriken dieses Programms einlesen. Ein Zugriff über das Netzwerk ist damit ausgeschlossen.
Die nächste Stufe bietet "ungeschützten" Zugriff über das Netzwerk, jedoch eingeschränkt auf einen speziellen TCP/IP-Port. Alle Personen im Netzwerk die auf diesen Port zugreifen können sind somit in der Lage die JMX-Metriken auszulesen. Folgende Variablen sind dafür notwendig:
-Dcom.sun.management.jmxremote.port=1557
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
Diese Lösung kann akzeptabel sein wenn der Port, der durch die Variable "...jmxremote.port" angegeben wird, nur befugten Personen zur Verfügung steht, kann jedoch auch ein Sicherheitsrisiko bedeuten. An dieser Stelle sollte nicht unerwähnt bleiben dass über JMX nicht nur Metriken geliefert werden sondern dass darüber auch serverseitige Aktionen ausgeführt werden können die den Server oder sogar das Netzwerk eventuell gefährden. Daher sollte diese Einstellung nur mit Bedacht gewählt werden.
Eine höhere Sicherheitsstufe bietet der passwortgeschützte Zugriff über das Netzwerk, der jedoch bereits komplizierter herzustellen ist. Dabei sind die Systemvariablen nicht wirklich das Hauptproblem:
-Dcom.sun.management.jmxremote.port=1557
-Dcom.sun.management.jmxremote.authenticate=true
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.password.file=C:\java\jmx\jmxremote.password
-Dcom.sun.management.jmxremote.access.file=C:\java\jmx\jmxremote.access
-Dcom.sun.management.jmxremote.authenticate=true
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.password.file=C:\java\jmx\jmxremote.password
-Dcom.sun.management.jmxremote.access.file=C:\java\jmx\jmxremote.access
Wie hier zu sehen ist referenzieren zwei Systemvariablen zwei unterschiedliche Konfigurationsdateien. Die Datei die per "...password.file" adressiert wird ist eine simple Textdatei die Definitionen von Anmeldenamen und deren Passwörtern enthält. Sie finden in ihrer JDK-Installation in Ordner "jre/lib/management" eine Datei "jmxremote.password.template" welche eine Schablone für diese Art von Datei darstellt.
Hier einmal ein exemplarischer Inhalt der "jmxremote.password" der lediglich einen Benutzer "admin" mit Kennwort "wga" definiert:
admin wga
Wie sie bemerken befindet sich das Kennwort als Klartext in dieser Datei. Aus Sicherheitsgründen stellt JMX deswegen spezielle Ansprüche an die Zugreifbarkeit dieser Passwort-Datei. Es akzeptiert sie nur, wenn ausschliesslich der Benutzer unter welchem das Java-Programm ausgeführt wird Zugriff darauf besitzt. Was unter Linux-Systemen sehr simpel über die Befehle "chown javabenutzer dateiname" und "chmod 600 dateiname" zu bewerkstelligen ist stellt für Windows-Systeme eine entscheidende Hürde dar. Konsultieren sie dazu folgendes Dokument von Sun Microsystems welches das Vorgehen unter Windows genau beschreibt.
Achtung: Entspricht der Dateizugriff nicht den Anforderungen von JMX so verweigern einige Java-VMs sogar den Start!
Des weiteren wird per Systemvariable "...access.file" eine weitere Konfigurationsdatei adressiert, welche den in der Passwort-Datei vergebenen Benutzern JMX-Berechtigungen zuweist. Auch hierzu finden sie im oben genannten JDK-Verzeichnis eine Datei "jmxremote.access" welche als Schablone dienen kann.
Auch hier wieder ein exemplarischer Inhalt von "jmxremote.access" der dem Benutzer "admin" volle Rechte zuweist:
admin readwrite
Weiter zur nächsten Seite ...