Installation des Integration-Servers

Die Installation des OIS kann über die OpenNMS-Yum- und -Debian-Repositories erfolgen. Der Java-Quellcode steht ebenfalls zur Verfügung und kann selbst übersetzt werden. Die Installationsvarianten sind im OpenNMS-Wiki zur OCS-Integration [4] beschrieben. In diesem Beispiel ist der OIS auf demselben Server wie OpenNMS installiert. Der Server lauscht auf der lokalen Adresse 127.0.0.1 auf Port TCP/8000 und stellt die Daten der zu importierenden Server im XML-Format bereit. Den Aufbau der Konfigurationsdateien des OIS zeigt Abbildung 5 .

Abbildung 5: Die Struktur der Konfigurationsdateien des OpenNMS-Integration-Servers.

Die Verzeichnisse »ocs-dbserver« , »ocs-mailserver« und »ocs-webserver« repräsentieren die Konfiguration für die OpenNMS-Requisition wie in Abbildung 2 skizziert. Die grundlegende Funktion des OIS wird in der Datei »global.properties« wie in Listing 1 beschrieben. Der Parameter »driver« gibt an, dass ein HTTP-Output erwartet wird. Mit »host« und »port« lässt sich festlegen, auf welcher Netzwerkschnittstelle und welchem Port auf eingehende Verbindungen gelauscht werden soll.

In dem Unterverzeichnis »ocs-webserver« liegt eine Datei »requisition.properties« , die wie in Listing 2 aufgebaut ist. Hier wird festgelegt, von welchem OCS-Server die Daten geholt werden sollen. Der OCS-Server ist in unserem Beispiel unter 192.168.30.112 erreichbar und die SOAP-Schnittstelle kann mit dem Benutzer »SOAP_USER« und dem Passwort »mypass« angesprochen werden.

Der Parameter »ocs.accountinfo« legt fest, dass für die Requisition »ocs-webserver« lediglich OCS-Computer auszuwählen sind, die »Monitored« und als Verwendungszweck »Webserver« gesetzt haben. Für Mail- und Datenbank-Server wird ebenfalls ein entsprechendes Verzeichnis angelegt. In der jeweiligen »requisition.properties« wird der Parameter für »ocs.accountinfo« entsprechend des Verwendungszwecks »Mailserver« und »Datenbankserver« angepasst.

Der Parameter »mapper« legt fest, welche Inventarinformationen von OCS in OpenNMS zu überführen sind. Falls das Standardverfahren nicht genügt, lässt sich ein eigenes Groovy-Skript angeben, dass die Daten zuordnet. In diesem Beispiel ist das unnötig.

Der letzte Parameter »categoryMap« definiert eine Datei, in der die Umgebung (Environment) der OpenNMS-Surveillance-Category zugewiesen wird. Im vorliegenden Szenario wird definiert, dass die Umgebungen für »Production« und »Stage« auf gleichnamige Surveillance-Categories in OpenNMS zuzuweisen sind. Die Datei »categoryMap.properties« sieht für Mail-, Web- und Datenbank-Server identisch aus:

ENVIRONMENT.Production=Production
ENVIRONMENT.Stage=Stage

Der OIS stellt unter der URL http://localhost:8000/ocs-webserver die Server entsprechend der Konfiguration aus dem Verzeichnis »ocs-webserver« zum Import zur Verfügung. Der Pfad »/ocs-webserver« entspricht hier dem angelegten Verzeichnis im Dateisystem. Entsprechend erhält man unter den Pfaden »/ocs-dbserver« sowie »/ocs-mailserver« kategorisierte Mail- und Datenbank-Server aus OCS. Die Konfiguration des Integration-Servers ist abgeschlossen und im nächsten Schritt wird OpenNMS für die automatische Synchronisation eingerichtet.

Import mit Provisiond

Um die Systeme in OpenNMS automatisch zu importieren und gegen OCS abzugleichen, wird der Daemon Provisiond von OpenNMS konfiguriert. Dazu ist im Verzeichnis »/opt/opennms/etc« die Datei »provisiond-configuration.xml« wie in Listing 3 zu bearbeiten. Relevant sind hier die Abschnitte der Requisition-Definition ( »requisition-def« ). Für Mail-, Web- und Datenbank-Server gibt es jeweils einen entsprechenden Eintrag. Er sorgt dafür, dass in OpenNMS jeweils eine Requisition für Web-, Mail- und Datenbank-Server entsteht. Jede Requisition konfiguriert das Verhalten für das Monitoring. Listing 3 legt ebenfalls fest, dass täglich um null Uhr, Mail-, Web- und Datenbank-Server von einem lokalen OIS über Port 8000 synchronisiert werden.

Der nächste Schritt legt die drei Requisitions in der OpenNMS-Weboberfläche an. Dazu wählt der Administrator im Hauptmenü den Punkt »Admin« und anschließend »Manage Provisioning Requisitions« aus. Über das Eingabefeld legt er die drei Requisitions »ocs-webserver« , »ocs-mailserver« und »ocs-dbserver« wie in Abbildung 6 an.

Abbildung 6: Vorbereiten der Requisition in OpenNMS für den automatischen Import.

Um ein Profil zu erzeugen, das bestimmt, wie die Systeme beim Import zu behandeln sind, konfiguriert man die Service-Detektoren (Detectors) für jede Requisition. Dazu gibt man unter »Requisition Edit« (1) an, welche Service-Detektoren anzuwenden sind. Nach dem Anlegen einer Requisition werden einfach alle zur Verfügung stehenden Service-Detektoren zugeordnet. Es ist daher sinnvoll, nur die Service-Detektoren auszuwählen, die für Mail-, Web- und Datenbank-Server passen. Abbildung 7 zeigt, dass für Web-Server nur die Service-Detektoren ICMP, HTTP, HTTPS und SNMP in der Konfiguration behalten und alle anderen gelöscht wurden. In der Gruppe der Mail- und Datenbank-Server werden relevante Service-Detektoren wie zum Beispiel SMTP, IMAP, POP3 und JDBC-Detektoren ausgewählt.

Abbildung 7: Auswahl von Service-Detektoren für Web-Server.

Die Konfiguration hat zur Folge, dass OpenNMS beim Import aus OCS prüft, ob beispielsweise HTTP oder HTTPS über das Netzwerk von dem zu importierenden Server verfügbar sind. Falls ja, werden die Services automatisch zugeordnet und automatisch ins Monitoring überführt.

Weiterhin können unter »Foreign Source Definition Edit« (2) für eine Requisition Richtlinien (Policies) festgelegt werden. Sie bestimmen, wie beim Import mit der Leistungsdatenerfassung umgegangen oder ob eine regelbasierte Kategorisierung der Systeme vorgenommen werden soll. Für das vorliegende Beispiel ist das jedoch nicht relevant. Weiterführende Informationen zu Richtlinien finden sich im OpenNMS-Wiki im Provisioning Users Guide [5] .