Application Monitoring (JMX MBean Design Patterns)

Damit diese einfachen (komprimierten) Snapshot Informationen dennoch aussagekräftig sind bietet es sich an bestimmte Designmuster einzuhalten. Diese stellen sicher dass die verschiedensten Arten von monitorring Anwendungen maximalen Nutzen aus den Daten ziehen können:


Komponentenstatus
Der einfachste Fall eines überwachbaren Attributs ist der aktuelle Zustand einer Komponente. Entspricht der Zustand nicht einem vorgegebenen Wert, so kann ein Alarm ausgelöst werden. Ebenso kann man den Zustand regelmäßig abfragen, und durch dieses Sampling dann die Verfügbarkeit über die Zeit plotten. Das Management Bean muss dazu nicht die Verfügbarkeit selbst berechnen (es genügt also wenn Servicezeiten und Abhängigkeiten nur in der Monitorring Anwendung definiert sind).

Damit der aktuelle Zustand aber nicht nur für eine Management Anwendung nutzbar ist, die regelmäßig den Zustand abfragt, bietet es sich an weitere Attribute mitzuführen. Dazu gehört der Zeitpunkt und der Grund des letzten Statuswechsels. Damit kann ein Administrator mit kurzem Blick sehen, ob er näher nachforschen muss (wenn der Status sich seit Tagen nicht geändert hat und dieser "ONLINE" ist gibt es keinen Grund nachzusehen). Eine schnelle Fehleranalyse wird durch ein Kommentarfeld vereinfacht, das den Grund für die letzte Statusänderung beschreibt. z.B. "State set to OFFLINE by user ADMIN", "Component automatically set to ONLINE at System start", "Component blocked because of too many errors. Last Error=Connection refused".

Um einen Alarm zu definieren, der bei einem instabilen System (oft Status Wechsel) ausgelöst wird ist es zudem sinnvoll einen Counter zu benutzen. Counter bestehen mindestens aus einem numerischen Attribut, das bei jedem Statuswechsel hochgezählt wird. Sinnvollerweise gibt es noch ein Attribut für den Counter, der das letzte Reset angibt. Damit kann eine pollende Anwendung sowohl auf absolute Schwellwerte (mehr als 5 Status Änderungen) als auch auf relative (mehr als 5 Status Änderungen pro Stunde) reagieren.

Attribut	Datentyp	Werte, Bemerkung
state	String	ONLINE, OFFLINE, BLOCKED, STARTING, STOPPING, ...
stateChangeReason	String	Brought automatically Online on System start
stateChangeTime	TIMESTAMP	CCYY-MM-DD hh:mm:ss.ccc
stateStatsSince	TIMESTAMP	CCYY-MM-DD hh:mm:ss.ccc
stateStatsChangeCounter	long	1

Die Anzahl der Status-Änderungen zu überwachen (statt bei jeder einzelnen Änderungen zu alarmieren) reduziert die Anzahl der Alarme. Das ist wichtig damit diese nicht ignoriert werden. Wenn die Komponente nur von sekundärer Bedeutung ist, oder deren Statuswechsel im Betrieb oft vorkommen sollte man nur eine Obergrenze setzen um "flatterndes" System zu erkennen. Dies wird z.b. sehr oft bei Netzwerkinterfaces eingesetzt.

Die Überwachung des Komponentenstatus liefert somit taktische Zustandsinformationen genauso wie Trendanalysen (nehmen die Ausfälle zu) und Statistiken zur Einhaltung von SLAs.


Kapazitätsauslastung
Ein weiterer typischer Bereich der überwacht werden will sind limitierte Ressourcen (Kanäle. parallele Connections, Threads). Die aktuelle Auslastung (und der konfigurierten Maximalwert) können regelmäßig überwacht werden, und so ein Diagramm der Auslastung gezeichnet werden. Um auch eine Momentaufnahme (ohne Historie) wertvoll für den Beobachter zu machen sollten aber noch weitere Werte angegeben werden. Durchschnittliche Auslastung und Trends sind nichts was das Managementbean selbst überwachen sollte, aber Höchst- und Niedrigstpegel sind einfache Werte die gespeichert werden können. Je nach wie die Komponente sich verhält wenn der Maximalwert erreicht wird kann auch noch gezählt werden wie viele Anfragen deswegen abgelehnt wurden, und ebenfalls kann gezählt werden wie viele Anfragen überhaupt gestellt (und bewilligt wurden). Aus diesen Werten läßt sich dann nämlich noch zusätzlich Durchsatzzahlen ablesen. Wird eine Anfrage nicht abgelehnt sondern verzögert bearbeitet, so ist es ebenfalls sinnvoll die Wartezeit zu akkumulieren. Solche Summen geben schnell Aufschluss darüber wo Performance verloren geht.

Attribut	Datentyp	Werte, Bemerkung
channelsUsed	long	1
channelsCapacity	long	10
channelsStatsSince	TIMESTAMP	2005-01-01 00:00:00
channelsStatsHigh	long	5
channelsStatsRequests	long	10000
channelsStatsDenied	long	0

Die Statistiken (HighWaterMark, Anfragen, Abgelehnte Anfragen) können zurückgesetzt werden, der Zeitpunkt ab dem die Werte ermittelt werden wird im Timestamp festgehalten. Das erlaubt Netzwerk Management Systeme Profile der Anfragen zu erstellen (durch regelmäßiges Sampling), auch wenn der Administrator die Counter manuell resettet.


Pools
Eine besondere Form von limitierten Ressourcen sind Pools. Diese können neben den oben genannten Attributen noch weitere statistische Werte haben wie Mindestgröße, Anzahl der (wegen Fehler) zerstörten Ressourcen und Anzahl der frei gegebenen Ressourcen (weil diese Idle waren).


Durchsatz
Bei einem System das Anfragen verarbeitet kann es Sinnvoll sein ein Profil der Anfragen zu erstellen (durchschnittliche Verarbeitungszeiten, Anfragegrößen, Häufung). All diese Werte können nur schwer von Snapshot Countern ermittelt werden. Dazu müssen die Datenreihen in Logfiles oder Tabellen ausgewertet werden. Allerdings ist es durchaus möglich mit dem bereits vorgeführten Counter Pattern eine grobe Systemauslastung zu plotten: einen Counter für die Anzahl der Anfragen und einen Counter für die Anzahl der verarbeiteten Bytes (oder KBs). Natürlich auch hier wieder eine reset Funktion und ein Zeitstempel seit wann der Counter erfasst wird. Diese Counter sind z.b. im Netzwerk Bereich sehr beliebt, die Anzahl der Pakete und die Anzahl der Bytes die über ein Interface transferiert wurden. Diese Counter sind auch meistens so, dass sie nach wenigen Tagen ihre Bereichsgrenze erreichen, in dem Fall muss das Netzwerk Management System einfach mit einem Wrap-Around zurechtkommen, und oft genug den aktuellen Counter Wert abfragen (ist der aktuelle Counterwert kleiner als der zuletzt gelesene so geht das NMS davon aus, dass es genau einen Wrap Around gab).


Fazit
Die (JMX) Statistiken sollten aus Performance und Stabilitätsgründen einfach sein. Da die Komplexität der gewünschten statistischen Auswertungen vorher nicht bekannt ist macht es Sinn diese komplett dem überwachenden Management System zu überlassen (Trends, Durchschnitte, Plots, Verfügbarkeiten). Ein Minimum an Attributen erlaubt aber auch dem gelegentlichen Beobachter aus den Snapshots Informationen zu extrahieren. Dazu gehören Zeitstempel und Counter.