Blog - gnuheidix

Indikatoren

Bei meinem Monitoring-Setup sind bei der Überwachung einer jeden Maschine bis zu vier unterschiedliche Indikatortypen vorzufinden.

Systemwerte

Dies umfasst alles, was direkte Rückschlüsse auf den Status vom Betriebssystem mittels Prozessorlast, Hauptspeicherbelegung, Prozesse, Interrupts uvm. zulässt. Subsysteme wie Dateisysteme und Netzwerkkommunikation sind da auch dabei.

Angebotene Dienste

Jeder bereitgestellte Dienst hat potentiell unterschiedliche Eckpunkte, welche Überwachung erfordern. Bei Webservern bieten sich z.B. Logfiles, Workerinformationen, Requestraten, Request-RTTs, Netzlast usw. an. Bei Mailservern sind hingegen die unterschiedlichen Queues, Greylisting-Treffer, Eingeloggte Nutzer usw. interessant.

Applikationen

Dies ist die höchste Flughöhe. Es werden immer wieder Interaktionen aus Nutzersicht nachgestellt und geprüft. Dies umfasst z.B. den HTTP-Responsecode [Munin-Plugin] aller Website-Homepages, deren Ladezeit und deren Google PageSpeed-Werte.

Besonders interessant ist dabei die Auswertung von Google PageSpeed [Munin-Plugin]. Einen besseren Test gibt es in der Tat fast nicht. Die Sites werden periodisch von einem externen System abgefragt und analysiert. Selbstanalysen, wie es die bisherigen Indikatoren waren, sind zwar gut, helfen aber bei der Erkennung von externen Problemen, wie Routingfehlern, nicht. Wenn es ein externes System schafft, die eigene Applikation zu verwenden, dann ist die Chance sehr sehr hoch, dass es die Nutzer auch können.

Externe Dienste

Da ohne essentielle Dienste, wie DNS und NTP nichts sauber arbeitet, ist auch an dieser Stelle ein wenig Überwachung notwendig. So ist man in der Lage, extern verursachte Applikationsausfälle schneller eingrenzen zu können.

Benutzung

Wenn das Monitoring erst einmal ein paar Wochen gelaufen ist, erkennt man im Muster der Graphen, wie sich Nutzerzahlen zu unterschiedlichen Tageszeiten und andere Ereignisse auf die einzelnen Teilbereiche auswirken. Beispielsweise erkennt man, was z.B. das tägliche Backup, eine Konfigurationsänderung oder ein neuer Blogbeitrag für das System bedeutet.

Wenn man z.B. einen Blogbeitrag schreibt, vertwittert und dann auf einmal das Monitoring meldet, dass der Webserver sporadisch 500er rausgibt, der PageSpeed-Score sinkt und Datenbanken am Limit sind, weiß man, wo man als nächstes mit dem Hammer nacharbeiten muss, um ein optimal laufendes System für den zu erfüllenden Zweck zu haben.

Ausblick

Als nächstes habe ich vor, das Alerting auszubauen und für jeden Indikator Limits festzulegen. Munin hebt dann bei einer Limitüberschreitung den jeweiligen Graph hervor und erklärt in der Detailansicht, was wie weit überschritten wurde. Beispielsweise triggert die Verfügbarkeit von Updates bereits jetzt eine Warnung, welche mich darauf hinweist, dass ich reagieren muss.

Es gibt viele Leute, die sich für sowas E-Mails senden lassen, aber - ganz ehrlich - E-Mail ist nicht das passende Werkzeug für sowas. Was, wenn ein DNS ausfällt, alle Limits auf einmal überschritten werden und das System tausende Problemmails rauspumpt. Nicht nur fängt man sich bei sowas die Pole-Position in Spamblacklists ein, man hat auch keinen Überblick drüber, was alles wann kaputt ging.

Eine Alert-Historie hat Munin noch nicht so richtig, aber die Erweiterung ist, soweit ich weiß, in der Pipeline. Ich setze übrigens noch die Version 1.4.x ein, obwohl es bereits 2.x gibt. Ein Upgrade wird bei nächsten Betriebssystemupgrade fällig.

Infrastruktur-Graphen

Angefangen habe ich nun auch, Graphen erzeugen zu lassen, die Indikatoren mehrerer unterschiedlicher Maschinen zusammen anzeigt. Wenn man weiß, wie es geht, ist es einfach. In der Anleitung gibt es einen hervorragenden Eintrag hierfür.

Fazit

Es gibt immer etwas, was noch kein Monitoring hat. Sobald man ein Problem gelöst hat, sollte man überlegen, ob man es mit etwas mehr Monitoring schneller hätte eingrenzen können. Es ist meines Erachtens besser, erst einmal alles aufzuzeichnen. Verwerfen kann man unwichtige Daten durch umfassende Health-Report-Graphen immernoch.

Wenn man es auf die Spitze treibt, hat man nur noch eine Art Lampe, die sagt, ob alles i.O. ist. Besonders beim Treffen wichtiger Entscheidungen, ist das hilfreich.

Nachtrag

17.02.2014: Nach erneutem Lesen der Dokumentation von Munin, habe ich herausgefunden, dass es nicht geplant ist, eine Alerthistorie zu implementieren. Die Designentscheidung hingegen ist, dass Alerts an externe Programme, wie Nagios, weitergereicht werden, weil diese dafür spezialisiert sind. Gute Entscheidung!