JConsole ist eine seit Java Version 1.5 mitgelieferte Swing-Applikation zur Überwachung von Java Prozessen via JMX auf lokalen oder entfernten Systemen. JMX steht für Java Management Extension und ist eine in der Weiterentwicklung befindliche Erweiterung des Java Standards, welche auch die Kommunikation zwischen unterschiedlichen JVM ermöglicht.
Nach dem Start der JConsole auf der Commandline erscheinen bereits im Startscreen die lokalen Java-Prozesse auf die mit einem Doppelklick zugegriffen werden kann. Für das Monitoring entfernter JVM’s muss auf dem Zielsystem der entsprechende RMI-Zugriff aktiviert sein.
JConsole gibt eine schnellen Überblick über den aktuellen Speicherbedarf der virtuellen Machine und der durch Java verursachten Prozessorauslastung. Alle Hauptsichten bieten die Möglichkeit verschiedene Zeitbereiche auszuwählen, welche jedoch nur während der Laufzeit der JConsole aufgezeichnet werden. Die Übersicht der Screenshots lässt erkennen, dass in unserem Beispiel bereits knapp 6000 Javaklassen in der JVM geladen sind. Hierbei handelt es sich um einen neu gestarteten iReport-Designer ohne geöffneten Bericht.
Die gelisteten MBeans, deren Zustand und weitere Parameter können selbstverständlich direkt aus Nagios und Icinga überwacht werden um eine langfristige Analyse zu ermöglichen. Mit check_jmx und check_jmx4perl gibt es bei MonitoringExchange.org hier bereits gute Lösungen.
Um über die Prozessliste hinaus einen schnellen Einblick in die virtuelle Maschine zu bekommen, ist JConsole eine ausreichende und dazu meist schon vorhandene Alternative, deren Nutzung sich lohnt.
Hi Gerd,
das ist auch ein gute Möglichkeit. Jedoch lässt sich der integrierte SNMP Agent nicht um eigene MIBS oder dann folglich MBeans erweitern.
Gruss
Bernd
Ack. Im Zweifel bleibt es ja jedem selbst überlassen. Bevor ich jedoch meinen SNMP Agent erweitere nutze ich einfach Mittel die vorhanden sind und dem Standard entsprechen.
Ich überwache die Basics von JVMs per SNMP. Das erfordert keinen weiteren offenen Port (sofern man snmp schon nutzt). Bei den Nagios-Plugins is ja auch check_snmp schon von Anfang an dabei.
Naja, eigene snmpagents sind nicht so komplex. Hier mal ein Beispiel: Das ganze dann noch per „proxy“ an den primären SNMP-Daemon binden und fertig.
Gruß Gerd
auch Ack. Die Frage ist ja immer an welcher Seite man selbst erweitert. Deswegen gehen ich den standardisierten SNMP Weg.