Big Sister überwacht das Netzwerk und seine Hosts: Eigene Agenten testen laufend, ob die Dienste noch funktionieren. Bei Bedarf alarmiert die große Schwester ihren Administrator. Eine hübsche Weboberfläche zeigt den aktuellen Zustand.

Der Name deutet es schon an: Big Sister[1] ist mit Big Brother[2] verwandt, dem Netzwerk-Monitoring-Produkt von Quest. Die Schwester ist kompatibel zum großen Bruder, steht im Gegensatz zu Quests Software aber unter der GNU GPL. Beide Familienmitglieder überwachen ein Netzwerk, archivieren die gesammelten Daten und bereiten sie als HTML auf (siehe Abbildung 1). Bruder und Schwester unterscheiden sich vor allem in der Flexibilität, den Haken und Ösen des jeweiligen Produkts und im Kleingedruckten, also der Lizenz.

Agenten und Daemons

Ein überwachtes Netzwerk benötigt einen Big-Sister-Server und mindestens einen Agent-Host. Der Server speichert, verarbeitet und visualisiert die gesammelten Daten. Auf den Agent-Hosts läuft der Daemon »uxmon«. Er führt die eigentlichen Healthchecks durch und sendet seine Ergebnisse über eine TCP-Verbindung (Default: Port 1984) an den Big-Sister-Server. Dort nimmt »bbd« die Daten aller Agenten entgegen und leitet sie an »bsmon« weiter, der alle weiteren Aufgaben erledigt (Alarmierung, Webseiten erstellen …). »bbd« und »bsmon« entsprechen »BBDISPLAY« in einer Big-Brother-Umgebung[4], »uxmon« ist mit »BBNET« vergleichbar.

Big Sister kennt drei Techniken, mit denen sie Systeme überwacht:

• Der Agent ist auf dem zu überwachenden Host installiert. Er sendet seine Statusmeldungen über einen TCP-Port zum Server.
• Jeder installierte Agent kann auch die Netzwerkdienste anderer Hosts (zum Beispiel SMTP, NTP, HTTP …) überwachen und deren Status an den Big-Sister-Server melden.
• Big Sister unterstützt auch das Standardprotokoll SNMP (Simple Network Management Protocol).

Immer der passende Test

Je nach Zielsystem und Einsatzart (lokaler Agent, remote) versuchen die Module des Uxmon-Agenten, das optimale (zuverlässigste) Testverfahren zu wählen. Beispielsweise nutzt der »procs«-Test lokal auf einem Unix-Rechner das »ps«-Kommando, unter Windows die Win32-API (lokal wie remote) und in den restlichen Fällen SNMP.

Wenn Big Sister für den überwachten Host keine gerätespezifischen Eigenschaften kennt, versucht sie es mit jener Abfrage, die erfahrungsgemäß auf den meisten Geräte funktioniert. Dank dieser Mehrfachimplementierung hat der Admin die Wahl, ob er den Big-Sister- oder einen SNMP-Agent auf dem überwachten System installiert. Big Sister wählt automatisch den passenden Agenten, der Admin kann dies mit der Gerätebeschreibung steuern. Die Uxmon-Konfiguration sieht unabhängig davon immer gleich aus, die Anzeige auf dem Display-Server ebenfalls.

Die SNMP-Agenten der meisten Geräte unterstützen die Host-MIB (Management Information Base). Sie zeigt unter anderem die freie und die belegte Kapazität der Festplatten und des Speichers. Leider sind diese Werte oft schwer zu interpretieren: Manche Produkte liefern Ergebnisse, die etwas anderes bedeuten, als es sich der Monitoring-Produktentwickler wünscht. Big Sister kennt die gängigsten MIBs, sie sind in der Datei »mibs.txt« nachzulesen.

Objekte und Gruppen

Big Sister fasst die überwachten Netzwerkobjekte zu Gruppen zusammen und versieht sie mit einer gemeinsamen Statusanzeige. Die Netzkomponente mit dem schlechtestem Zustand bestimmt den Zustand ihrer Gruppe. Es ist sinnvoll, Geräte geografisch zu gruppieren und die voneinander abhängigen Dienste und Netzkomponenten zusammenzulegen. So sieht der Admin bei einer Störung auf einen Blick, wer von dem Ausfall betroffen ist und wie es um die SLAs (Service Level Agreements) steht. Per Default gibt es drei Gruppen:

• »NEW«: Alle Hosts, die von der Sicherheitsrichtlinie zugelassen sind, sich aber zum ersten Mal beim Big-Sister-Server anmelden.
• »ALL«: Die oberste Ebene der Host-Hierarchie. Diese Gruppe enthält alle bekannten Hosts, aber keine weiteren Gruppen.
• »UNIVERSE«: Die oberste Ebene der gesamten Hierarchie. In dieser Gruppe befinden sich alle Hosts und auch alle Gruppen.

Bei Big Sister ist es nützlich, sich eine hierarchische Sicht der Dinge anzueignen. Besonders bei den Abhängigkeiten von Diensten und SLAs helfen Hierarchien die Übersicht zu behalten. Jede Hierarchie darf beliebig viele Ebenen enthalten, von jeder Ebene können beliebig viele Zweige ausgehen. Kreisbeziehungen und zu unübersichtliche Strukturen sollte man aber vermeiden.

Abbildung 1: Big Sister zeigt den Zustand des Netzwerks in übersichtlichen Tabellen (rechts unten). Sie bindet Grafiken als Imagemap ein (rechts oben) und trägt dort den Zustand der Geräte und Verbindungen farbig ein.

Aktueller und alter Zustand

Per Default stellt Big Sister sowohl den aktuellen Zustand der überwachten Systeme als auch die Historie tabellarisch dar. Abbildung 2 zeigt den zeitlichen Verlauf der Zustände. Der Admin kann auf diese Tabellen auch Abfragen nach bestimmten Feldern oder gewünschten Ereignissen anwenden.

Mit etwas zusätzlichem Konfigurationsaufwand füttert Big Sister RRDTool ([5],[6]) mit den gesammelten Daten. Dieses Werkzeug gibt dann den zeitlichen Verlauf einer Messreihe als Graph wieder. Graphen bewähren sich in der Praxis, um morgens während der ersten drei Tassen Kaffee etwas Interessantes zu beobachten statt zu arbeiten – richtig angewendet liefern sie aber auch sehr nützliche Hinweise auf das Normalverhalten (die Basislinie) des Netzwerks.

Wichtig ist oft die Vorgeschichte eines Problems. Mit Graphen lässt sich nachträglich feststellen, was im Umfeld eines Ausfalls geschehen ist. Ist die Disk plötzlich vollgelaufen, etwa durch einen unliebsamen Benutzer, oder kontinuierlich im Rahmen der üblichen Arbeiten? Hat sich die Netzlast plötzlich und unerwartet erhöht, beispielsweise durch eine Denial-of-Service-Attacke, oder handelt es sich um eine normale Spitzenlast? Graphen liefern Hintergrunddaten bei der Analyse von Ausfällen und helfen so, die passenden Maßnahmen zu finden, um Ausfälle künftig zu vermeiden.

Übersichtskarte

Hierarchien und gemeinsame Statuslampen sind zwar praktisch, es geht aber sogar noch übersichtlicher, denn Big Sister bindet externe (selbst gezeichnete) Darstellungen der Netzwerktopologie als GIF- oder PNG-Grafik ein und nutzt sie als Imagemap. Mit dieser räumlichen Anordnung der Netzwerkelemente kann der Admin die aktuellen Zustände sehr einfach den realen Geräten zuordnen. Auf der Imagemap zeigt Big Sister Statuslampen und Verbindungselemente (Linien). Die Linien verbinden Netzwerkobjekte oder Gruppen. Die Farbe der Statuslampen und Verbindungselemente entspricht deren Status. Ein Klick auf die Elemente führt in die jeweilige Tabellenansicht.

Um diese Elemente einzubinden, ist etwas Handarbeit erforderlich. Die Position der gewünschten Elemente in Pixeln bestimmt man am besten mit einem externen Editor und hinterlegt sie dann in einer Konfigurationsdatei. Listing 1 zeigt den Ausschnitt einer Imagemap-Konfiguration; ihr Name wird vom »%image«-Tag in der Datei »bb-display .cfg« bestimmt. Die Konfiguration der beiden Verbindungselemente (Zeilen 10 und 11) beginnt mit den Namen der Endpunkte. Am Ende jeder Zeile steht dann, zu welcher tabellarischen Ansicht diese Verbindung gehört.

Alarm und Trouble

Neben dem reinen Monitoring und der History-Funktion bietet Big Sister eine regelbasierte Alarmierung und eine einfache Trouble-Ticket-Funktion. Überschreitet ein Messwert einen vorher festgelegten Schwellenwert oder ist ein System nicht mehr erreichbar, dann bestimmen die Regeln, welchen Admin Big Sister wie oft und auf welchem Weg (etwa per E-Mail) benachrichtigen soll.

Gleichzeitig taucht der Alarm auf der Alarmseite des Webinterface auf und wartet darauf, dass sich ein Techniker seiner annimmt. Im Idealfall bestätigt der den Alarm mit »ACK« und sagt, wie lange er ungefähr braucht, um die Störung zu beheben. Diese Information geht per E-Mail an denselben Empfängerkreis (Abbildung 3). Während dieser Zeit erscheint zusätzlich ein Häkchen in der Alarmliste. So ist dokumentiert, welcher Alarm gerade bearbeitet wird und welcher noch nicht – das ist die wohl wichtigste Funktion eines Trouble-Ticket-Systems.

Abbildung 2: Mit der History-Funktion protokolliert Big Sister den zeitlichen Ablauf der Zustände. Um 0:15 Uhr stieg die Systemlast auf 0,25 und löste einen gelben Alarm aus, der um 0:17 endete. Um 11:38 trat ein roter Alarm auf.

Wartungsfenster

Wartungsfenster sind genauso wie die Fehlerbehebung zeitlich begrenzt. Der Maintenance Mode läuft daher ähnlich wie ein Trouble-Ticket ab. Solange ein Dienst noch in Wartung ist, erscheint eine weiße Statuslampe und Big Sister löst keine Alarme aus. Sie überwacht den Dienst aber weiter. Nach dem Ablauf der voreingestellten Zeit (egal ob es sich um ein Trouble-Ticket oder ein Wartungsfenster handelt) schaltet sie die Alarmierung automatisch wieder auf Normalbetrieb um.

Big Sister verwendet ein eigenes Protokoll. Es ist kompatibel zu Big Brother, beide haben mit dem SNMP-Standard nichts gemein. Das ist bei freien Monitoring-Paketen ein verbreiteter Ansatz (zum Beispiel bei Spong[3]). Die Client-Server-Architektur mit einem einzigen TCP-Port (bei Big Sister 1984) vereinfacht die Firewall-Konfiguration. Zudem lässt sich das Protokoll sehr einfach über SSH tunneln.

Besonders in den letzten Monaten gingen Entwicklung und Design von Big Sister recht schnell voran. Die Programmierer haben zum Beispiel das Konzept der Healthchecks geändert, die nun selbst feststellen, auf welcher Plattform sich der Agent befindet, und den Benutzer über die richtige Syntax informieren. Die Installation verläuft dank GNU Autoconf jetzt auf üblichen Wegen, sogar fertige RPM-Pakete sind verfügbar. Auch ein offizielles Logo und eine dazu passende Skin für das Webfrontend sind entstanden. Mit zunehmender Verbreitung kümmern sich mehr Entwickler um die Schwester: Sie soll größer, erfolgreicher und hübscher werden. (fjl)

Abbildung 3: Big Sister alarmiert die Admins per E-Mail. Auf diesem Weg informiert sie auch, sobald sich ein Techniker für ein Problem zuständig erklärt.

01 # Definition von Start- und Endpunkten für
02 # die Verbindungselemente um desasterix
03 name 255,171 p-desasterix-start
04 name 255,136 p-desasterix-end
05 name 257,171 p-desasterix2-start
06 name 257,136 p-desasterix2-end
07 
08 # Definition der beiden Verbindungselemente
09 # und Link zum Ping-check
10 line p-desasterix-start  p-desasterix-end  desasterix.conn
11 line p-desasterix2-start p-desasterix2-end desasterix.conn
12 
13 # Definition der Statuslampe von desasterix
14 name 250,192 p-desasterix
15 
16 # Verlinkung der Statuslampe mit der Gruppe DESASTERIX
17 at p-desasterix DESASTERIX