Veranstaltungen

Spring Boot (Michael Simons)

Do, 25. Januar 2018

Kalender als XML und iCal

Wir unterstützen...

Elterninitiative Kinderkrebsklinik e.V

Kinderkrebsklinik e.V

Sponsoren

Wir danken unseren Sponsoren:

Permanente Sponsoren

Uni Düsseldorf
(Raum und Beamer)


(Preise)


(Preise)


(Preise)


(Preise)

Mitgliedschaften



java.net Member

Events

Nachlese JBoss ON | Print |
Written by Harald Menke   
Sunday, 22 March 2009 17:04

Im folgenden haben wir wieder eine von Harald Menke geschriebene Nachlese. Heiko Rupp hat in seinem eigenen Blog ebenfalls eine Nachlese geschrieben.

(Das Video vom Vortrag ist on-line verfügbar)

Heiko Rupp von Red Hat stellte am heutigen Abend das Systemmanagement mit dem JBoss Operating Network 2 vor. Für die neue Version wurde das Datenmodell von Grund auf neu entwickelt, vorwiegend fand dabei JSF Verwendung. Das plugin-basierte Konzept ermöglicht eine einfache Erweiterung und lädt zur Plugin-Entwicklung für weitere Resourcen ein. Hier sind jetzt Plugin-Entwickler gefragt, die zu einer Erweiterung dieser Open Source Suite beitragen möchten.

RHQ, ein Gemeinschaftsprojekt von Red Hat und Hyperic, stellt die Basis für JBoss ON 2 und nutzt für das Reporting die Java Management Extensions (JMX), das eingebettete Jopr dient als Ersatz für dessen Konsole. Als Resource gilt grundsätzlich alles, was überwacht werden kann. Es wird zwischen Resourcentyp und Resourcenkategorie unterschieden. Zum Typ zählen z.B. Linux oder Mac OS X, Dateisystem, Linuxzeug, JBoss AS, Apache HTTP Server und Tomcat, auch jk_mod, und DB-Tabellen. Den Kategorien wird der Platz in der Hierarchie, die Vater-Kind-Relation und die Plattform (Maschine) zugerechnet. Bei os-spezifischen Resourcen z.B., ist darauf zu achten, das keine Veränderlichen gewählt werden: Eine Prozess-ID, die beim nächsten Start eine andere ist, macht wenig Sinn.

 

Die Resourcen lassen sich zu Gruppen klassifizieren. Per Mixed Group ist so eine differenzierte Zusammenstellung möglich, was der Überwachung von Konstellationen sensibler Ereignisse dienlich ist. Das Measurement wird im Dashboard gesetzt, hier werden dessen Werte festgelegt. Herr Rupp hat dies erfolgreich mit einem simplen Temperatur-Messfühler getestet. Das Dashboard zeigt in einer als Timeline dargestellten Metric diese Events an. Mit den Alerts kann zugleich die Art und Weise bestimmt werden, wie diese Information erfolgen soll, z.B. Benachrichtung per SMS bei Eintritt des Ereignisses.

 

Die Architektur zeigt die Agenten als zuständig für den Plug-in Container. Sie beenden und starten diese Container automatisch und halten so das Inventory auf dem aktuellen Stand. Dieses Inventar gibt Auskunft über die vom jeweiligen Agenten verwalteten Resourcen.

 

Eine gewisse Übereinstimmung mit der Architektur des Spring Frameworks und dem IoC-Konzept, scheint mir nicht von der Hand zu weisen zu sein.

Folien zum Vortrag