IT-Monitoring Teil 1: die Grundlagen
Monitoring ist eine mehr oder weniger große Sammlung von Messwerten, sog. Checks. CPU‑, RAM- oder Festplattenauslastung sind Standard, ebenso Dienste, Host up/down und Netzwerktraffic. Bessere Lösungen bieten noch eine Vielzahl weiterer Messwerte an, wie Temperaturen, Lüfterdrehzahlen, Spannungen etc. und so kommen bei manchen Servern nach einem ersten Inventory Sammlungen mehr als 100 Checks zusammen.
Ist die Sammlung auf die Basiswerte beschränkt, ist die Aussagekraft oft gering, aber man bewahrt noch einen gewissen Überblick. Ist die Sammlung zu groß, gehen die wichtigen Meldungen im Rauschen der vielen Fehlalarme unter, die sich fast zwangsläufig ergeben. Denn das Einpflegen der zu überwachenden Systeme und Anlegen der Checks ist bei einem guten Monitoring leider nur die halbe Miete.
Nur hören viele hier schon auf, nutzen das Monitoring doch nur für Analysen nach dem Fehler oder lassen es einfach so laufen.
Der größte Aufwand bei einem guten Monitoring geht aber jetzt erst los. Es gilt zu planen, welche Checks wichtig sind, um Fehler zu erkennen. Und welche nur für spätere Auswertungen benötigt werden. Welche Abhängigkeiten muss ich abbilden, damit ein Alarm auch eine Aussagekraft haben kann?
So ist ein niedriger Tonerstand sicher kein kritischer Alarm, aber ein Exchange-Server auf dem store.exe nicht läuft schon. Nur leider sind per Default im Monitoring beide Situationen gleichwertig.
Wie kann ich sicherstellen, dass auch jemand den Fehler sieht, der das System nicht so gut kennt? Und welche Ansicht hätte gerne der IT-Leiter, der einfach nur schnell sehen will, ob das Gesamtsystem im grünen Bereich ist?
Fehler und Alarme gibt es immer, aber laufen alle wichtigen Dienste und Anwendungen?
Die Arbeit fängt erst nach dem Anlegen an
Schwellwerte – ein erster Schlüssel zu sinnvollen Alarmen
Und nicht zuletzt müssen Schwellwerte definiert werden. So ist es für einen SQL-Server völlig normal auch mal längere Zeit mit 100% CPU-Last zu laufen, er soll ja auch mal arbeiten.
Auf einem Terminalserver sind 100% CPU-Last schon nach wenigen Minuten ein kritischer Zustand, denn hier können vermutlich einige Anwender jetzt nicht mehr vernünftig arbeiten.
Für all diese Fragen ist eine sorgfältige Planung notwendig, dazu ein meist längerer Prozess der Optimierung. An dessen Ende wichtige Alarme sofort gesehen werden und trotzdem die ganze Tiefe an Messwerten erfasst wird.
