Alles zu überwachen erzeugt Alarme, die niemand liest, und das ist dasselbe, als überwachte man nichts. Fünf Signale decken fast jeden Ausfall ab, und jedes hat einen Wert, der Zeit zum Handeln lässt, statt Ihnen zu sagen, dass es schon passiert ist.

Die fünf

  • Platte, bei 80 %. Nicht 95. Eine Platte, die über Nacht volläuft, legt die Website lahm, bis jemand aufwacht; 80 % ist eine Aufgabe für den Vormittag.
  • Speicher, sobald Swap benutzt wird. Swap in Gebrauch heißt, die Maschine kämpft, und alles ist längst langsam.
  • Last, gemessen an Ihrer Kernzahl. Alarm bei doppelter Kernzahl über fünf Minuten hinweg - eine Spitze ist normal, ein Plateau nicht.
  • Zertifikatsablauf, bei 21 Tagen. Die Erneuerung läuft bei 30; ist sie bei 21 nicht passiert, blockiert sie etwas.
  • Die Website selbst, von außen. Jeder Dienst kann grün sein, während die Seite 500 liefert.

Von außen, nicht vom Server

Eine Prüfung, die auf der Maschine läuft, die sie prüft, kann Ihnen nicht sagen, dass die Maschine unerreichbar ist. Die wichtigste Prüfung ist eine HTTP-Anfrage von woanders, auf eine bestimmte Zeichenkette auf der Seite - nicht bloß auf eine 200.

curl -fsS --max-time 10 https://yourdomain.com/ | grep -q 'Sign in' || alert

Alarme lesenswert halten

Ein Alarm, der jeden Tag auslöst und jeden Tag ignoriert wird, ist schlimmer als kein Alarm: Er bringt allen bei, den Kanal zu ignorieren, auch an dem Tag, an dem es zählt. Löst etwas aus und Sie tun nichts, dann beheben Sie entweder die Ursache oder löschen den Alarm.

Den Trend beobachten, nicht nur die Schwelle

Eine Platte bei 60 % ist in Ordnung. Eine Platte, die letzte Woche bei 40 % war, ist es nicht - sie ist in vierzehn Tagen voll. Ein Graph beantwortet das "wann", was eine Schwelle nie tut.

EGPNL zeigt CPU, Speicher, Platte und Verkehr je Server samt Verlauf. Managed-Tarife ergänzen die Prüfung von außen und die Rufbereitschaft - der Teil, der sich nicht automatisieren lässt.