System Monitoring ist ja an sich eine Kunst. Ich sehe das mittlerweile mit ziemlich gespaltenen Gefühlen und auch wenn ich von der Notwendigkeit sinnvollen Monitorings absolut überzeugt bin, habe ich mittlerweile genug Erfahrungen sammeln dürfen, dass ich gerne “Die Heisenbergsche Unschärferelation für das Monitoring von IT-Systemen” postuliere – Ich verändere durch Beobachtung schon mein Ergebnis, je genauer ich hin sehe um so stärker werden die tatsächlich relevanten Werte beeinflusst. Je nach verwendetem Werkzeug und Anzahl meiner Proben und abgefragten Parameter ist der Aufwand für Monitoring signifikant und beeinträchtigt meine Systemleistung.

Daher lohnt es sich einmal einen Schritt zurück zu treten und einmal zu betrachten welche Informationen ohnehin vor liegen und nicht verwertet werden. Typischerweise sind das die System- Logs. Jetzt sagt der geneigte Leser “Moment- ich suche darin immer nach Ursachen und stichprobenartig kontrolliere ich diese sogar!”. Sehr lobenswert, aber aus verschiedenen Gründen bleibt man damit unter seinen Möglichkeiten.

Zum einen sind Logs tatsächlich ein Forensisches Werkzeug und sie helfen dann, wenn schlimme Dinge bereits eingetreten sind. Sind schlimme Dinge der Verlust von Datenspeichern stehen diese Logs gegebenenfalls nicht einmal mehr zur Analyse zur Verfügung.

Daher pflegt die Netzgemeinde schon seit nahezu Anbeginn der Zeit den Mechanismus des LogServers. Syslog ist im *ix*- Lager und bei aktiven Komponenten schon lange nicht weg zu denken und die Logs werden zu entsprechend zentralen und vielleicht sogar redundanten Systemen exportiert. Ein Mechanismus, der so in der Welt der Windows- Server auch erst langsam Einzug hält.

Unterhält man eine respektabel große Umgebung bemerkt man hier relativ bald einige Pferdefüße. Zum einen müssen die Uhrzeiten im Netz recht synchron gehalten werden und die zunehmend populäre Verwendung von Internet Zeit Servern lässt hier die Systemzeiten schon einmal so weit auseinander laufen, dass man sich die Suche nach Zusammenhängen erschwert. Diesen Effekt kann man sich mit DCF 77 Funkuhren ein wenig eindämmen.

Zweitens muss man, sollte ein komplexes Fehlerbild eintreten die miteinander korrelierenden Meldungen auch miteinander in Verbindung bringen. Eine intellektuell durchaus anspruchsvolle Tätigkeit, die mit den vielleicht mit Systemausfällen einher gehenden Adrenalin- Niveaus schon mal nicht vereinbar ist oder vielleicht auch heute aus der schieren Masse heraus gar nicht mehr manuell bewerkstelligt werden kann.

Möchte man die korrelierenden Ereignisse und ihre Muster auch noch präventiv beobachten um sie gegebenenfalls in eine automatisierte Alarmierung ein zu binden, verbietet sich der manuelle Ansatz von selbst.

Daher bin ich auf der ständigen suche nach dem sinnvollsten Loging Werkzeug. Manche der großen Monitore binden in ihre Umgebungen Logfile Analyse ein, aber das soll erst der nächste Schritt sein und ist aus den oben genannten Gründen auch zunächst nicht der zu forcierende Ansatz.

Loging Werkzeuge als solche gibt es durchaus im openSource Lager mit syslog-ng oder der Einbindung in Nagios und seine Derivate. Diese haben allerdings durch die Bank den Nachteil, dass die Einbindung verschiedener Systeme und die Entwicklung entsprechender Alarmierungen und Meldeketten bzw. insbesondere die Event- Korrelation doch mit erheblichem Pflegeaufwand und manueller Konfiguration verbunden sind.

Auf der kommerziellen Seite fällt mir sofort Solarwinds ein mit dem auf den Kiwi-Syslog Dienst auf setzenden Log & Event Manager. Eine kurze Recherche zeigt hier an, dass die Kosten jenseits des für uns vertretbaren landen werden und sich im Rahmen eine vollwertigen Monitoring Lösung bewegen. Wenn ich auch an Kosten- Effizienz denke, verbietet sich das also von selbst.

In der Großwetterlage bin ich auf VMWare vrealize LogInsigt gestoßen. Hier erhält man schon mit vCenter 25 Sensor Lizenzen frei Haus und kann in Ruhe die Leistung testen. Die Installation erfolgt als OVA Vorlage mit einem vollständigen Dialog ohne Vorbedingungen und ist in Minuten erledigt. In einem Portal innerhalb der Anwendung kann man Content- Pakete für verschiedene Hersteller herunter laden, zum Beispiel auch für die für uns wichtigen PaloAlto Firewalls. Ebenso aber auch für Windows, Exchange, Active Directory, MS-SQL und vieles mehr.

Auf der Basis vordefinierter Log Analysen und Gruppierungen kann man sich dann eigene Filter definieren und in individuellen Dashboards – siehe obige Screenshots – zusammen fassen.

Die forensischen Qualitäten sind durch das zentrale Logging und die search- Engine innerhalb der Lösung durchaus konsolidiert gegeben. Allerdings erlaubt die grafische Aufbereitung eben auch die strukturierte Darstellung von Schwachpunkten, Trends, Hot-Spots in der Systemlandschaften und vielem mehr.

An Manueller Arbeit bei der Einrichtung führt auch hier kein weg vorbei. Jedoch lassen die Vielzahl der vordefinierten Filter eben die Investition lohnend erscheinen und erlauben es auch zeitnah einen pflegbaren Zustand der Log-Analyse zu erhalten.

Das klassische System- Monitoring kann man dann ggfs. etwas schmaler dimensionieren und die Ressourcen schönen.

Kyp. F.

p.s. Danke Carsten für den tip.