Voller Durchblick bei geringem Aufwand

Definition von Production States

Mit Production States unterscheidet das Zenoss-System zwischen Devices die es lediglich überwachen muss und Geräten, für die es auch Alerts generiert. Befindet sich eine Komponente beispielsweise im Status „Pre-Production“, so findet zwar ein Monitoring statt, es gibt aber keine Alarme. Im Status „Production“ kommen die Alarme dann hinzu. Ein anderer häufig vorkommender Production State ist „Maintenance“.

Die beiden genannten Dialogfelder, die über die Device Issues und die Production States informieren, lassen sich – je nach Wunsch des Anwenders aus der Dashboard-Seite entfernen, verschieben oder um andere Dialogfelder – der Hersteller nennt diese „Portlets“ – erweitern. So stehen beispielsweise Portlets wie eine Watch List, Google Maps (zum Einbinden von Karten, um darauf die Position einzelner Niederlassungen zu visualisieren) und Top Level Organizers zur Verfügung.

Die Top Level Organizers umfassen unterschiedliche Geräteklassen wie Server, Switches und so weiter und bieten so einen schnellen Zugriff auf die entsprechenden Geräteeinträge. Dazu kommt noch ein Portlet namens Zenoss Issues, das sich mit Zenoss selbst befasst.

Die Event Console bietet den Anwendern im Gegensatz dazu einen Zugriff auf die aktuell im System aufgetretenen Events, also Fehlermeldungen, Warnungen und Informationen über die analysierten Rechner. Die Events lassen sich auf Wunsch mit Klassen kombinieren (App/Job/Fail, Status/Ping, etc.), in die History verschieben (beispielsweise weil ein Problem gelöst wurde) oder als CSV-Datei exportieren, um sie anschließend in anderen Programmen weiterzubearbeiten. Über die Acknowledge-Funktion sind die Benutzer sogar dazu in der Lage, sich bestimmter Events anzunehmen, so dass andere IT-Mitarbeiter sehen, dass sich bereits jemand damit befasst.

Device List, Network Map und Classes

Mit Hilfe der Device List greifen die Administratoren auf die Daten der überwachten Geräte im Netz zu. Dazu gehören Name, IP-Adresse, Klasse (Server, Switch, etc.), Production State und eine gerätebezogene Eventzusammenfassung. Die zuständigen Mitarbeiter sind an dieser Stelle dazu in der Lage, den Production State zu beeinflussen, die Priorität einer Komponente festzulegen, die Klassenzugehörigkeit zu ändern, den Ort anzugeben, an dem ein Gerät läuft, Einträge zu löschen und ähnliches.

Die Network Map zeigt schließlich die Elemente in einem Netz als Symbole an. Auf diese Weise erhalten die Anwender die Option, auf einen Blick zu sehen, wie die Netzwerktopologie aussieht. Um eine bestmögliche Übersicht über das Netzwerk zu erhalten, lässt sich die Zahl der anzuzeigenden Geräte über die Angabe der maximal erlaubten Zahl der Hops begrenzen.

Die „Classes“ befassen sich mit Events, Devices, Services und ähnlichem. Was die Events angeht, so findet sich am oberen Rand der dazugehörigen Übersicht ein Farbbalken, über den die einzelnen Einträge abhängig von ihrer Bedeutung ansprechbar sind. Das System unterscheidet hier zwischen Events, die es – je nach Schwere des Problems – als Rot, Orange, Gelb, Blau, Grau oder Grün markiert.

Außerdem teilt das System sie in Unterklassen wie Archive, Cisco, Cluster oder Ignore auf, um ein so genanntes Event Class Mapping zu realisieren. Dieses Mapping definiert, wie Zenoss einen Event einordnet. In der Praxis analysiert das System einen eingehenden Eintrag und fügt ihn dann einer passenden Eventklasse zu. Danach berücksichtigt es den Kontext für die jeweilige Eventklasse und legt anhand der dadurch entstehenden Klassifizierung den Status fest. Auf diese Weise erfolgt die Einteilung in wichtige und weniger wichtige Events.

Das Event Mapping lässt sich jederzeit an die Anforderungen der IT-Abteilung anpassen. An gleicher Stelle finden sich auch noch eine Zugriffsmöglichkeit auf die bereits bekannte Eventliste und ein Befehl namens Zproperties, über den sich Einstellungen zu den Events (zum Beispiel Event Action) festlegen lassen.

weiter mit: Navigation

(ID:2017208)