9. Dezember 2019 
Marc Wilhelmi 

IT-Moni­to­ring Teil 1: die Grundlagen

Moni­to­ring ist eine mehr oder weniger große Samm­lung von Mess­werten, sog. Checks. CPU‑, RAM- oder Fest­plat­ten­aus­las­tung sind Stan­dard, ebenso Dienste, Host up/down und Netz­werktraffic. Bessere Lösungen bieten noch eine Viel­zahl weiterer Mess­werte an, wie Tempe­ra­turen, Lüfter­dreh­zahlen, Span­nungen etc. und so kommen bei manchen Servern nach einem ersten Inven­tory Samm­lungen mehr als 100 Checks zusammen.

Ist die Samm­lung auf die Basis­werte beschränkt, ist die Aussa­ge­kraft oft gering, aber man bewahrt noch einen gewissen Über­blick. Ist die Samm­lung zu groß, gehen die wich­tigen Meldungen im Rauschen der vielen Fehl­alarme unter, die sich fast zwangs­läufig ergeben. Denn das Einpflegen der zu über­wa­chenden Systeme und Anlegen der Checks ist bei einem guten Moni­to­ring leider nur die halbe Miete.

Nur hören viele hier schon auf, nutzen das Moni­to­ring doch nur für Analysen nach dem Fehler oder lassen es einfach so laufen.

Der größte Aufwand bei einem guten Moni­to­ring geht aber jetzt erst los. Es gilt zu planen, welche Checks wichtig sind, um Fehler zu erkennen. Und welche nur für spätere Auswer­tungen benö­tigt werden. Welche Abhän­gig­keiten muss ich abbilden, damit ein Alarm auch eine Aussa­ge­kraft haben kann?
So ist ein nied­riger Toner­stand sicher kein kriti­scher Alarm, aber ein Exch­ange-Server auf dem store.exe nicht läuft schon. Nur leider sind per Default im Moni­to­ring beide Situa­tionen gleichwertig.

Wie kann ich sicher­stellen, 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 Gesamt­system im grünen Bereich ist?
Fehler und Alarme gibt es immer, aber laufen alle wich­tigen Dienste und Anwendungen?

Die Arbeit fängt erst nach dem Anlegen an

Schwell­werte – ein erster Schlüssel zu sinn­vollen Alarmen

Und nicht zuletzt müssen Schwell­werte defi­niert 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 Termi­nal­server sind 100% CPU-Last schon nach wenigen Minuten ein kriti­scher Zustand, denn hier können vermut­lich einige Anwender jetzt nicht mehr vernünftig arbeiten.

Für all diese Fragen ist eine sorg­fäl­tige Planung notwendig, dazu ein meist längerer Prozess der Opti­mie­rung. An dessen Ende wich­tige Alarme sofort gesehen werden und trotzdem die ganze Tiefe an Mess­werten erfasst wird.

IT-Moni­to­ring kann mehr
Weitere Beiträge aus unserer Artikelserie