Ein guter Alarm-Schwellenwert für Server schlägt an, wenn ein Mensch handeln muss, und bleibt sonst still. In der Praxis heißt das: bei anhaltenden Werten alarmieren statt bei einzelnen Spitzen, die Load pro CPU-Kern messen statt als nackte Zahl, verfügbaren Arbeitsspeicher und Swap beobachten statt „belegtem RAM“, beim Speicherplatz früh alarmieren und auch darauf achten, wie schnell er wächst, und jeden ungeplanten Neustart als meldenswert behandeln. Teilen Sie Alarme in eine Warnstufe für die Arbeitszeit und eine kritische Stufe, die jemanden wecken darf, und überprüfen Sie die Werte nach jedem Vorfall.
Dieser Leitfaden geht jede Metrik durch, erklärt, wie ein sinnvoller Schwellenwert aussieht, und endet mit einer Tabelle mit Startwerten. Es sind Ausgangspunkte, keine Regeln: Jeder Server hat seinen eigenen Normalzustand, und der richtige Schwellenwert ist der, der dazu passt.
Wofür ein Schwellenwert da ist
Jeder Alarm kostet Aufmerksamkeit. Ein Alarm, der anschlägt und keine Handlung erfordert, bringt Menschen bei, den nächsten zu ignorieren – und der nächste könnte echt sein. Beantworten Sie vor dem Festlegen eines Schwellenwerts drei Fragen:
Was geht kaputt, wenn sich dieser Wert so weiterentwickelt, und wie bald?
Was würde die Person, die den Alarm erhält, tatsächlich tun?
Kann es bis morgen früh warten?
Wenn nichts kaputtgeht und niemand handeln würde, ist es ein Diagramm, kein Alarm. Wenn es bis morgen früh warten kann, ist es eine Warnung. Nur was nicht warten kann, sollte nachts ein Smartphone erreichen.
Warnstufe und kritische Stufe
Zwei Stufen pro Metrik funktionieren für die meisten Teams gut:
Warnung: Etwas entwickelt sich in die falsche Richtung. Senden Sie sie per E-Mail oder in einen Team-Chat-Kanal und kümmern Sie sich während der Arbeitszeit darum.
Kritisch: Ein Ausfall steht bevor oder läuft bereits. Senden Sie ihn als Push-Benachrichtigung an die Person in Rufbereitschaft, Tag und Nacht.
Hat Ihr Monitoring-Tool nur einen Schwellenwert pro Metrik, erreichen Sie denselben Effekt über das Routing: Setzen Sie den Schwellenwert dort, wo Handlungsbedarf besteht, und wählen Sie den Kanal pro Server. Ein Festplatten-Alarm auf einem Staging-Server kann per E-Mail kommen; derselbe Alarm auf der Produktionsdatenbank kann in den Chat des Bereitschaftsteams gehen. Benachrichtigungen wählen Sie bei Uptimecheck pro Monitor, was diese Aufteilung einfach macht. Mit Bereitschaftsplänen erreichen Push-Alarme die Person, die gerade Bereitschaft hat, und die Eskalation kann einen Kanal 5 bis 60 Minuten zurückhalten und erst alarmieren, wenn das Problem noch besteht und niemand es bestätigt hat.
Dauer schlägt Spitzen
Die häufigste Quelle für Lärm ist ein Alarm auf einen einzelnen Messwert. CPU bei 100 Prozent für zehn Sekunden während eines Deployments, eines Backups oder eines Cache-Neuaufbaus ist normal. CPU bei 100 Prozent für zwanzig Minuten nicht. Wo Ihr Tool es zulässt, ergänzen Sie eine Dauer: „über 90 Prozent für 10 Minuten“ statt „über 90 Prozent“.
Wo nicht, nutzen Sie Metriken, die bereits über die Zeit glätten. Der 15-Minuten-Load-Average ist ein gutes Beispiel: Ein kurzer Ausschlag bewegt ihn kaum, eine anhaltende Überlastung treibt ihn nach oben und hält ihn dort.
CPU
Hohe CPU-Last allein ist selten ein Problem. Ein ausgelasteter Server ist ein Server, der seine Arbeit tut. Zum Problem wird die CPU, wenn sie so lange gesättigt bleibt, dass sich Anfragen stauen und die Antwortzeiten steigen. Alarmieren Sie bei anhaltender Auslastung und betrachten Sie sie zusammen mit den Antwortzeiten aus Ihren Uptime-Checks. Liegt die CPU bei 95 Prozent und die Antwortzeiten bleiben flach, ist der Server beschäftigt, nicht im Ausfall.
Load Average pro Kern
Unter Linux ist der Load Average grob die Zahl der Prozesse, die laufen oder auf die CPU warten – unter Linux auch die, die auf Festplatten-I/O warten –, gemittelt über 1, 5 und 15 Minuten. Eine Load von 4 sagt für sich genommen nichts: Auf einem Server mit 16 Kernen ist sie gering, auf einem mit 2 Kernen doppelt so viel, wie die Maschine bewältigen kann. Teilen Sie vor dem Vergleich durch die Zahl der Kerne, die Ihnen nproc verrät.
Der 1-Minuten-Wert reagiert schnell und ist unruhig. Nutzen Sie ihn zur Diagnose, nicht für Alarme.
Der 15-Minuten-Wert ist der richtige für Alarme. Über 1 pro Kern heißt, dass sich Arbeit staut; deutlich darüber und über lange Zeit heißt, dass Nutzer es spüren.
Hohe Load bei niedriger CPU bedeutet meist, dass Prozesse auf Festplatte oder Netzwerkspeicher warten. Schauen Sie auf I/O, nicht auf den Code.
RAM und Swap
„Belegter RAM“ ist unter Linux eine irreführende Metrik. Der Kernel nutzt freien Speicher für den Dateicache und gibt ihn zurück, sobald Anwendungen ihn brauchen. Ein gesunder Server zeigt deshalb oft fast vollen Speicher. Schauen Sie stattdessen auf den verfügbaren Speicher, die Spalte „available“ in free -m, die den freigebbaren Cache mitzählt.
Swap sagt mehr aus. Ein Server, der normalerweise nicht swappt und plötzlich damit anfängt, steht unter Speicherdruck, und die Leistung bricht stark ein, sobald aktiver Speicher auf die Festplatte ausgelagert wird. Zwei nützliche Signale:
Swap-Nutzung, die auf einem Server auftaucht oder wächst, der normalerweise keine hat.
Verfügbarer Speicher, der über Tage stetig sinkt, was oft auf ein Speicherleck in einem lange laufenden Prozess hindeutet.
Datenbankserver sind ein Sonderfall: Sie sind absichtlich so konfiguriert, dass sie den Großteil des Speichers nutzen. Legen Sie ihre Schwellenwerte anhand dessen fest, was Sie in einer normalen Woche sehen.
Speicherplatz und Wachstum
Eine volle Festplatte ist eine der häufigsten Ursachen für vermeidbare Ausfälle. Datenbanken schreiben nicht mehr, Logs werden nicht mehr rotiert, Sessions lassen sich nicht speichern und Backups schlagen fehl. Gleichzeitig ist die Festplatte die Metrik, die sich am leichtesten richtig einstellen lässt, weil sie sich selten schnell ändert – wer früh alarmiert, hat also Zeit zu handeln.
Nutzen Sie einen Prozent-Schwellenwert für Warnung und kritische Stufe, passen Sie ihn aber an die Größe an. Auf einem 2-TB-Volume sind 10 Prozent frei immer noch 200 GB; auf einem 20-GB-Volume sind es 2 GB, die ein einziges fehlerhaftes Log an einem Nachmittag auffressen kann.
Beobachten Sie neben dem Füllstand auch das Wachstum. Eine Festplatte bei 70 Prozent, die diese Woche um 10 Punkte gewachsen ist, ist dringender als eine, die seit einem Jahr bei 85 Prozent steht.
Wissen Sie, was sie füllt: Logs, lokal aufbewahrte Backups, Uploads, Docker-Images, Datenbankdateien. Für jedes gibt es eine andere Lösung.
Netzwerk
Für Netzwerkverkehr lässt sich schwer ein fester Schwellenwert setzen, weil das Normale je nach Tageszeit und Saison schwankt. Zwei Muster sind einen Alarm wert. Verkehr weit über dem üblichen Niveau, nahe an der Kapazität der Leitung, kann eine Lastspitze, einen Scraper oder einen Angriff bedeuten. Verkehr, der auf einem normalerweise ausgelasteten Server auf nahezu null fällt, kann bedeuten, dass er aus dem Load Balancer genommen wurde oder seine Netzwerkverbindung verloren hat – selbst wenn die Maschine selbst in Ordnung aussieht. Lernen Sie den normalen Bereich aus ein paar Wochen Verlauf, bevor Sie Zahlen festlegen.
Neustarts
Über einen ungeplanten Neustart sollten Sie immer Bescheid wissen. Dahinter kann ein Kernel-Update stecken, eine Wartung beim Hosting-Anbieter, ein Absturz oder ein Out-of-Memory-Ereignis. Selbst wenn alles wieder hochkommt, können Dienste, die nicht beim Booten starten, geplante Jobs, die während des Neustarts fällig waren, und eingebundene Volumes in einem schlechten Zustand zurückbleiben. Alarmieren Sie bei jedem Neustart außerhalb eines Wartungsfensters, auf Warnstufe, wenn sich der Server selbst wieder erholt hat.
Startwerte
Die folgenden Werte sind beispielhafte Ausgangspunkte für einen typischen Web- oder Anwendungsserver. Nutzen Sie sie für die ersten Wochen und passen Sie sie dann an das an, was Sie beobachten.
MetrikWarnung (Beispiel)Kritisch (Beispiel)CPUÜber 85 % für 15 MinutenÜber 95 % für 15 Minuten, bei steigenden AntwortzeitenLoad Average (15 Min.)Über 1 pro KernÜber 2 pro KernVerfügbarer SpeicherUnter 15 %Unter 5 %SwapJede Nutzung auf einem Server, der normalerweise keinen Swap nutztÜber 50 % des Swaps belegtFestplatteÜber 80 % oder beim aktuellen Tempo innerhalb einer Woche vollÜber 90 % oder innerhalb eines Tages vollNetzwerkDeutlich außerhalb des normalen Bereichs für die TageszeitNahe an der Leitungskapazität oder nahe null auf einem ausgelasteten ServerNeustartJeder Neustart außerhalb eines WartungsfenstersDienste sind nach einem Neustart nicht wieder gestartet
Das Server-Monitoring von Uptimecheck meldet CPU, Arbeitsspeicher, Festplatte und Netzwerk jede Minute unter Linux, macOS und Windows. Sie legen Schwellenwerte für CPU, Arbeitsspeicher und Festplatte pro Server fest, mit einer Dauer wie 5 oder 15 Minuten, und Sie werden auch bei Neustarts alarmiert und wenn ein Server verstummt – so wird eine Maschine, die keine Daten mehr meldet, nie für eine ruhige gehalten. Warum diese Zahlen wichtig sind, lesen Sie in Website am Laufen halten mit Server-Status-Monitoring.
Achten Sie auch auf die Symptome
Server-Metriken beschreiben Ursachen. Ihre Nutzer erleben Symptome: langsame Seiten, Fehler und fehlgeschlagene Jobs. Überwachen Sie beides. Ein Uptime-Check mit Antwortprüfung zeigt Ihnen, wann die Website ausfällt, und ein Heartbeat, wann das Backup nicht fertig wurde. Schlagen ein Symptom-Alarm und ein Ressourcen-Alarm gleichzeitig an, ist die Ursache meist offensichtlich. Schlägt nur der Ressourcen-Alarm an, haben Sie oft Zeit, das Problem zu beheben, bevor es jemand bemerkt.
So können Sie Server-Schwellenwerte auch guten Gewissens höher setzen. Wird die Website jede Minute geprüft, muss ein CPU-Alarm nicht derjenige sein, der einen Ausfall erkennt. Er lässt sich auf Frühwarnung statt auf letzte Instanz abstimmen. Dasselbe Prinzip gilt für Website-Checks; siehe Fehlalarme im Uptime-Monitoring reduzieren.
Schwellenwerte nach Vorfällen überprüfen
Schwellenwerte sind nie fertig. Fragen Sie nach jedem Vorfall und bei lauten Servern einmal im Monat:
Hat ein Alarm angeschlagen, bevor Nutzer etwas bemerkt haben? Wenn nicht: Welche Metrik hat sich zuerst bewegt, und hätte ein niedrigerer Schwellenwert es erkannt?
Welche Alarme haben angeschlagen, ohne dass jemand gehandelt hat? Setzen Sie sie höher, ergänzen Sie eine Dauer oder verlegen Sie sie in einen Kanal für tagsüber.
Hat der Alarm jemanden erreicht, der handeln konnte? Wenn nicht, ändern Sie das Routing.
Hat sich der Normalzustand des Servers nach einem Upgrade, einer Migration oder mehr Verkehr verändert?
Halten Sie die Antworten im Vorfallsbericht fest, damit jede Änderung eine Begründung hat. Die Vorlage für Incident-Postmortems hat genau dafür einen Abschnitt.
Zusammenfassung
Alarmieren Sie bei dem, was einen Menschen braucht, und zwar mit der Dringlichkeit, die es wirklich hat. Nutzen Sie anhaltende Werte, Load pro Kern, verfügbaren Speicher und Swap, Füllstand und Wachstum der Festplatte sowie jeden ungeplanten Neustart. Starten Sie mit Beispielwerten, lernen Sie den Normalzustand jedes Servers kennen und justieren Sie nach jedem Vorfall nach.
Uptimecheck bündelt Server-Monitoring, Uptime-Checks, Heartbeats und Statusseiten in einem Konto. Starten Sie Ihre 14-tägige kostenlose Testphase, keine Kreditkarte erforderlich.