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.
|
Listing 1: Imagemap
|
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
|
Hardware-Anforderungen
|
|
Beim Ressourcenbedarf ist zwischen dem Big-Sister-Server und den Agenten zu unterscheiden. Der Agent wird in vielen Umgebungen auf allen überwachten Systemen installiert sein und auf die lokalen Zustandsdaten zugreifen. Er soll den eigentlichen Einsatzzweck des Systems nicht stören. Je nach Konfiguration ist damit zu rechnen, dass er zwischen fünf und 20 MByte virtuellen Speicher benötigt, aber kaum CPU-Zeit beansprucht.
Anders sieht es dagegen beim Server aus. Er muss die Statusmeldungen aller Agenten entgegennehmen, in Logdateien ablegen und gegebenenfalls Alarme auslösen sowie das Ausbleiben von Statusmeldungen erkennen, Daten für Graphen ablegen und die Benutzeroberfläche aufbauen. Besonders aufwändig ist das Generieren der Webseiten, aber auch das Aufbereiten der Grafiken kostet Ressourcen. Speicherbedarf und Anforderungen an die CPU-Leistung steigen hier mit der Anzahl überwachter Systeme, der generierten Webseiten und der auf Big Sister zugreifenden Administratoren.
Ein kleines Netz mit bis zu 15 überwachten Geräten wird problemlos auch auf älterer Hardware ohne nennenswerten Einfluss auf die Systemleistung laufen. Angehende Netzüberwacher müssen im Schnitt mit 20 bis 25 MByte Speicher und zehn Prozent CPU-Last auf einem 500-MHz-Pentium rechnen.
Hohe Ansprüche in großen Netzen
In größeren Umgebungen steigen meist die Ansprüche: Mehr Statusseiten mit verschiedenen Sichten auf die Umgebung gepaart mit mehr Imagemaps lassen die CPU-Last des Servers stark ansteigen. Für 100 überwachte Systeme, die auf zehn Statusseiten verteilt und mit fünf Diagrammen gepaart sind, sollte ein dediziertes System mit mindestens 600 MHz und 256 MByte RAM eingeplant werden.
Im normalen Betrieb scheint der Server dann zwar vor sich hin zu dümpeln, aber für Lastspitzen - wenn beispielsweise ganze Subnetze ausfallen - braucht er einige Reservern. Wer Big Sister noch weiter skalieren will, sollte beachten, dass Mehrprozessorsysteme hier kaum einen Vorteil bringen: Ein einzelnes Perl-Skript erledigt die meiste Arbeit. Die Windows-Version benötigt im Übrigen doppelt so viele Ressourcen wie die Linux-Variante.
|
Die Autoren
|
|
Thomas Aeby hat das Big-Sister-Projekt 1996 ins Leben gerufen. Er arbeitet als leitender Systemingenieur bei Phinex Informatik AG, Schweiz. Er befasst sich seit Jahren beruflich wie privat mit Systemadministration unter Unix und Linux.
Jörg Fritsch hat Chemie studiert und arbeitet seit mehreren Jahren als Systemspezialist für Internetdienste und Security. Er veröffentlicht gern zu interessanten Themen im Bereich Linux, TCP/IP und Security. Er ist einer der Autoren des kürzlich bei Addison-Wesley erschienen Buchs "Firewalls illustriert".
|
| Whitepaper |
|---|
|
Open Source Datenintegration in der Praxis: Fallstudien und Anwendungsbeispiele (Folge 2)
Der zweite Teil des Open Source Datenintegration in der Praxis: Fallstudien und Anwendungsbeispiele White Papers beleuchtet anhand weiterer ausgewählter Case Studies die Implementierung von Open Source Datenintegration in der Praxis und benennt die daraus resultierenden Vorteile.
Download PDF (Registrierung erforderlich)
|
|
Usage Landscape Enterprise Open Source Data Integration
Die Nachfrage nach Datenintegrationslösungen für Unternehmen ist zunehmend gestiegen und vor allem das Interesse an Open Source Technologien wird immer größer. Doch wie und von wem werden Open Source Datenintegrationslösungen genutzt und welches Nutzungsverhalten lässt sich daraus ableiten? Das vorliegende White Paper präsentiert die Erfahrungswerte von über 1000 Open Source Nutzern und liefert fundierte Antworten auf diese Fragen.
Download PDF (Registrierung erforderlich)
|
Dieser Online-Artikel kann Links enthalten, die auf nicht mehr vorhandene Seiten verweisen. Wir ändern solche "broken links"
nur in wenigen Ausnahmefällen. Der Online-Artikel soll möglichst unverändert der gedrucken Fassung entsprechen.
|
