Auf die Finger geschaut

Systemmanagement mit RHQ

Heiko W. Rupp

Spätestens wenn man eine Applikation in Betrieb genommen hat und die ersten Kunden anrufen, dass sie nicht erreichbar ist, möchte man doch genauer wissen, wie sich die Applikation und ihre Infrastruktur verhält. Zu diesem Zweck gibt es Systemmanagementsoftware. Dieser Artikel stellt das in Java geschriebene System RHQ vor, dessen Version 4.0 in Entwicklung ist. Die Funktionalität von RHQ ist dabei nicht hart kodiert, sondern kann über Plug-ins erweitert werden, sodass es möglich ist, eigene Applikationen mit in das Management zu nehmen.

RHQ steht als Open-Source-Projekt unter der GPL und existiert bereits seit 2008. Anfang Juli 2010 wurde die Version 3.0 freigeben (Kasten: „Historie“); die Version 4.0 ist in Arbeit und soll Anfang 2011 freigegeben werden; eine Betaversion wird beim Erscheinen dieses Artikels verfügbar sein. Die Architektur von RHQ folgt dem klassischen Nabe-Speicherprinzip, bei dem auf zu managenden Maschinen ein Agent installiert wird. Dieser beherbergt Plug-ins, die mit den zu managenden Ressourcen kommunizieren und diese überwachen. Der Agent sendet die Messergebnisse zu einem zentralen Server, auf dem diese zum einen gespeichert werden und andererseits in die Alarmverarbeitung kommen, sodass in Fehlersituationen Administratoren informiert werden können. Administratoren können über den Server (bzw. Cluster von Servern) via Browser den Zustand des Systems einsehen und auch Aktionen anstoßen, die dann auf den zu managenden Ressourcen ausgeführt werden. Abbildung 1 zeigt die Architekturübersicht.

Abb. 1: Nabe-Speicherarchitektur von RHQ

In dieser Übersicht sieht man auch, dass der Server nie selbst mit einer zu managenden Ressource interagiert; dies geschieht ausschließlich über das Plug-in, das im Agent läuft. Dies bedeutet in den allermeisten Fällen, dass diese Kommunikation lokal auf dem Rechner abläuft, auf dem die Ressource läuft. Neben dem Zugang via Browser gibt es auch einen Kommandozeilenclient, der in Skripten verwendet werden kann. Im Client selbst kann via JavaScript programmiert werden, sodass man hier wiederkehrende Aufgaben einfach erledigen kann.

Historie

RHQ wurde Februar 2008 als Teil des Quellcodes für JBoss Operations Network 2 (JBoss ON 2) in die Open Source entlassen. Die restlichen Bits blieben bis Herbst 2008 proprietär und wurden dann als Jopr ebenfalls als Open Source freigegeben, wurden aber in einem separaten Repository gehostet. RHQ diente dabei als Basis für Jopr und diese gemeinsam als Upstream für JBossON. Im September 2009 erfolgte der Umzug der Quellen in ein git Repository bei Fedorahosted. In diesem Rahmen wurden die Jopr-Quellen ebenfalls zu RHQ migriert, sodass RHQ nun der alleinige Upstream für JBossON ist. Der aktuelle Release 3.0.0 wurde im Juli 2010 freigeben.

Während der Arbeit an 3.0.0 wurde bereits parallel angefangen, am Release 4 zu arbeiten – größte geplante Änderung wird die grafische Oberfläche sein, die von Struts/JSP und JSF/Facelets nach GWT umgebaut wird.

Ressourcen und so

Bevor wir uns der Applikation widmen, gilt es ein paar Begriffe zu klären, die für das spätere Verständnis hilfreich sind:

  • Plug-in: Hiermit werden meist die Agent-Plug-ins gemeint, die die Funktionalität für die Interaktion mit zu managenden Ressourcen implementieren und als Metadaten dem RHQ-System beschreiben.
  • ResourceType: Hiermit werden die Eigenschaften eines Typs von Ressourcen beschrieben – beispielsweise ob sie Monitoring oder Operationen unterstützen und welche Metriken und Operationen vorhanden sind. Man kann einen ResourceType mit einer Java-Klasse vergleichen. Er wird innerhalb eines Plug-ins definiert und muss für dieses eindeutig sein.
  • Resource: Dies ist eine konkrete Entität, die gemonitored oder gemanaged werden kann. Dies kann ein Prozess sein oder auch ein Thermometerchip, ein Motor, ein Applikationsserver oder ein Apache httpd. Analog zu Java wäre dies eine Objekt als Instanz des passenden ResourceType.
  • ResourceCategory: Jeder ResourceType gehört einer ResourceCategory an, die beschreibt, wo innerhalb der Hierarchie eine Ressource angesiedelt ist. Die drei Möglichkeiten sind Folgende:
  • Plattform – ein Rechner
  • Server – ein Prozess oder Subsystem wie der JbossAS, Tomcat, Infinispan oder auch Apache Httpd
  • Dienst (Service) – eine einzelne Ressource, z. B. eine Datenquelle, eine JMS Queue oder eine Netzwerkschnittstelle

Abbildung 2 zeigt, wie ResourceType hierarchisch geschachtelt werden können. So ist es beispielsweise möglich, dass eine Ressource der Kategorie ‚Server‘ eine andere Ressource dieser Kategorie beinhaltet, wie dies im Fall des JBoss AS mit dem eingebetteten Tomcat der Fall ist. Ob eine Ressource der Kategorie Server oder Dienst angehört, entscheidet der Entwickler eines Plug-ins; hier gibt es keine eindeutigen Vorgaben.

Abb. 2: Hierarchie der ResourceCategory
Geschrieben von
Heiko W. Rupp
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.