Eine Festplatte mit 87 % Belegung ist ein einzelner Messwert. Er verrät dir nicht, ob die Auslastung schon seit Monaten auf diesem Niveau liegt oder gerade auf „voll“ zusteuert. Diese Situationen erfordern unterschiedliche Reaktionen: In der einen musst du vielleicht gar nichts tun, in der anderen brauchst du einen Plan.
Server-Metriken gut zu lesen heißt, einen einmaligen Sprung von einem anhaltenden Anstieg zu unterscheiden. Ein einzelner Wert liefert dir eine Momentaufnahme; eine Reihe von Messwerten gibt dir die Möglichkeit zu beurteilen, was sich verändert.
Monitoring-Systeme setzen für unterschiedliche Probleme unterschiedliche Techniken ein: Glättung, statistische Prüfungen oder die Bedingung, dass ein Zustand eine Weile anhält, bevor ein Alarm ausgelöst wird. InfraNest nutzt aktuelle Messwerte, um abzuschätzen, ob ausgewählte Server-Metriken auf eine relevante Grenze zusteigen – und, sofern die Daten es hergeben, wie viel Zeit ungefähr noch bleibt.
Warum ein einzelner Messwert wenig aussagt
Eine einzelne Messung zu einem bestimmten Zeitpunkt wird in dem in RFC 2330 beschriebenen Mess-Framework als Singleton bezeichnet. Sie zeigt dir, welchen Wert die Metrik in diesem Moment hatte, aber nicht, ob sie stabil ist oder sich verändert. Dafür brauchst du Messwerte über einen Zeitraum.
Das gilt auch für Counter. Ein Counter steigt in der Regel so lange an, bis er zurückgesetzt wird, daher ist sein Rohwert selten die aussagekräftige Größe. Prometheus verwendet Funktionen wie rate() oder increase(), um abzuschätzen, wie stark sich ein Counter innerhalb eines Zeitfensters verändert. Gauges, etwa der freie Festplattenspeicher, können steigen und fallen; für sie eignet sich eine Gauge-orientierte Funktion wie deriv() besser.
Unterschiedliche Tools beantworten unterschiedliche Fragen
Das Problem ist alt, aber es gibt keine einzelne Technik, die jeden Sprung von jedem Trend unterscheidet. Monitoring-Systeme verwenden je nachdem, was sie messen und was sie entscheiden müssen, unterschiedliche Methoden.
| Technik | Wobei sie hilft | Wie |
|---|---|---|
| Unix Load Average | Wie sich die Systemlast über die Zeit verändert | Gibt exponentiell gedämpfte Mittelwerte über 1, 5 und 15 Minuten aus. Diese messen lauffähige bzw. nicht unterbrechbare Tasks – nicht die CPU-Auslastung in Prozent – und der kürzere Mittelwert reagiert schneller auf aktuelle Veränderungen. |
| CloudWatch „Datapoints to Alarm“ | Ob eine Metrik wiederholt einen Schwellenwert überschritten hat | Verlangt eine konfigurierte Anzahl von Datenpunkten mit Überschreitung innerhalb einer festgelegten Zahl von Auswertungsperioden, etwa 3 von 5. |
Prometheus rate() und irate() |
Wie schnell ein Counter ansteigt | rate() schätzt den durchschnittlichen Anstieg pro Sekunde über ein Zeitfenster; irate() nutzt die letzten beiden Samples und reagiert schneller auf aktuelle Veränderungen. |
Prometheus for-Klausel |
Ob eine Alarmbedingung anhält | Verzögert das Auslösen, bis die Bedingung für die konfigurierte Dauer aktiv geblieben ist. |
| Regeln der statistischen Prozesslenkung | Ob sich ein Prozess verschoben hat oder driftet | Regeln für Kontrollkarten suchen nach ungewöhnlichen Punkten oder Mustern im Verhältnis zu einer Prozess-Baseline. Die Regeln hängen von der Methode ab; sie sind keine universelle Definition eines Trends. |
| SRE-Burn-Rate-Alarme mit mehreren Zeitfenstern | Ob ein Error Budget zu schnell aufgebraucht wird | Kombiniert kurze und lange Zeitfenster, um verschiedene Stufen von SLO-Risiko zu erkennen. Ausgelegt für Service-Zuverlässigkeit, nicht für allgemeine Kapazitätsprognosen von Servern. |
Diese Techniken sind verwandt, aber nicht austauschbar. Ein Alarm, der eine anhaltende Überschreitung voraussetzt, beantwortet eine andere Frage als eine Schätzung, wann ein steigender Wert eine Grenze erreichen könnte.
Prometheus-Beispiel: ein Gauge für freien Festplattenspeicher
node_filesystem_free_bytes ist ein Gauge, daher verwendest du deriv(), um abzuschätzen, wie schnell sich der freie Speicher verändert. Ein negatives Ergebnis bedeutet, dass der freie Speicher schrumpft:
deriv(node_filesystem_free_bytes{mountpoint="/"}[6h])
Mit predict_linear() kannst du abschätzen, ob der freie Speicher innerhalb des nächsten Tages null erreicht, und verlangen, dass diese Bedingung anhält, bevor ein Alarm ausgelöst wird:
- alert: DiskFillingFast
expr: predict_linear(node_filesystem_free_bytes{mountpoint="/"}[6h], 24 * 3600) < 0
for: 10m
predict_linear() nutzt lineare Regression. Dieses Beispiel sagt voraus, wann null freie Bytes erreicht werden – nicht einen vom Nutzer konfigurierten Festplatten-Schwellenwert –, und es ist nicht dieselbe Berechnung, die InfraNest verwendet.
Die ganze Serverflotte auf einen Blick lesen
Ein Server, der konstant bei etwa 60 % liegt, und einer, der eine kurze, hohe Spitze hatte, können über einen Berichtszeitraum einen ähnlichen Durchschnitt aufweisen. Wenn du neben dem Durchschnitt auch den Spitzenwert betrachtest, wird dieser Unterschied sichtbar.
Der Capacity & growth report von InfraNest zeigt Spitzen- und Durchschnittswerte des Zeitraums für CPU, Arbeitsspeicher und Festplatte sowie eine kleine CPU-Sparkline, die einen Eindruck vom Verlauf vermittelt. Eine Festplattenprognose erscheint nur, wenn die aktuellen Messwerte eine solche stützen. Es handelt sich um eine Live-Prognose, die für einen Berichtszeitraum angezeigt wird, der den heutigen Tag einschließt – nicht um eine Prognose für jede Festplatte oder für einen vergangenen Monat.
Prüfe vor dem Vergleich von Zahlen, an wie vielen Tagen gemessen wurde. Ein Server, für den nur ein Teil des Zeitraums erfasst wurde, ist nicht direkt mit einem vergleichbar, der durchgehend gemessen wurde. Und bei zyklischer oder unregelmäßiger Auslastung gibt es womöglich keinen verlässlichen Trend, den man fortschreiben könnte.
Wie InfraNest abschätzt, wann ein Trend relevant wird
Auf der Seite eines überwachten Servers kann InfraNest eine Zusammenfassung wie diese anzeigen:
Online seit 18d 4h, aber die CPU erreicht ihre 90-%-Alarmgrenze in etwa 6 Tagen
Der Button bringt dich zum entsprechenden Diagramm. Bei der Festplatte zählt die Schätzung bis zum vollständigen Füllstand herunter. Bei CPU, Arbeitsspeicher und Load zählt sie bis zu einer aktiven Alarmregel mit oberem Schwellenwert herunter. Die Festplatte wird anders behandelt: Eine volle Festplatte ist eine Kapazitätsgrenze, unabhängig davon, ob eine Festplatten-Alarmregel konfiguriert ist.
Die Schätzung ist bewusst vorsichtig:
- Sie verwendet stündliche Messwerte aus bis zu den letzten sieben Tagen; das heißt nicht, dass immer sieben volle Tage Verlauf erforderlich sind.
- Sie benötigt mindestens 12 verwertbare Messwerte und hält Schätzungen zurück, wenn die Messwerte keinen glaubwürdigen Aufwärtstrend stützen – etwa nach einem einmaligen Sprung oder wenn die Reihe zu stark schwankt.
- Schätzungen für CPU, Arbeitsspeicher und Load erfordern eine aktive Regel mit oberem Schwellenwert. Festplattenschätzungen nicht.
- Sie meldet den frühesten relevanten Trend, statt für jede Metrik eine eigene Frist aufzulisten.
- Vom Provider gemeldete CPU-Werte können eine Schätzung auch ohne den Agent ermöglichen. Arbeitsspeicher, Festplattenbelegung und Load Average erfordern Messwerte des Agents.
Die Zusammenfassung selbst löst keinen Schwellenwert-Alarm aus und eröffnet keinen Incident. Sie schätzt, wann ein steigender Wert seine Grenze erreichen könnte; das ist kein Versprechen, wann du benachrichtigt wirst. Numerische Alarme werten einen Durchschnitt über die konfigurierte Dauer aus. Unabhängig davon kann eine überwachte Festplatte, die laut Schätzung innerhalb von 14 Tagen voll ist, in der Aufmerksamkeitsliste und im Digest von InfraNest erscheinen.
Die Zusammenfassung ist nützlicher Kontext, aber kein Ersatz für Alarme. Alarme decken weiterhin die konfigurierten Schwellenwert-Bedingungen ab; die Schätzung kann dir früher einen Anlass geben, ein mögliches Kapazitätsproblem zu untersuchen.
Die flottenweite Übersicht findest du im Kapazitäts- und Wachstumsbericht. Wie Schwellenwerte konfiguriert und ausgewertet werden, erfährst du unter Alarmregeln pro Server.
Server-Monitoring in der Praxis einrichten
Richte server monitoring ein, um die für deine Server verfügbaren Messwerte zu erfassen. Vom Provider gemeldete Metriken können, sofern unterstützt, CPU-Werte liefern; installiere den Agent, um Arbeitsspeicher, Festplattenbelegung und Load Average zu erfassen.
Häufig gestellte Fragen
#Wie viel Verlauf braucht InfraNest, bevor eine Trendlinie angezeigt wird?
Ein Server braucht mehr als ein oder zwei Tage an Messwerten, bevor InfraNest eine Einschätzung anzeigt. Bei zu wenig Verlauf reichen die Daten nicht aus, um einen echten Trend von Rauschen zu unterscheiden – deshalb wird die Linie einfach weggelassen, statt zu raten.
#Funktioniert die Trendlinie auch auf Servern ohne Monitoring-Agent?
Ja. Server ohne Agent werden mit den Messwerten berücksichtigt, die ihr Cloud-Provider meldet; der Agent ergänzt zusätzliche Metriken wie Arbeitsspeicher, Festplattenspeicher und Load Average, ist für den Trendsatz selbst aber nicht erforderlich.
#Warum zeigt mein Server keine Trendlinie, obwohl eine Metrik hoch aussieht?
Ein hoher Wert, der flach verläuft, einmal gesprungen ist und sich dann eingependelt hat oder auf und ab schwankt, bekommt keine Trendlinie – nur eine Metrik, die tatsächlich stetig steigt. Ein hoher, aber stabiler Wert wird dir an anderer Stelle nicht vorenthalten; er bekommt nur keine falsche Frist.
#Ist die Trendprognose dasselbe wie ein Server-Alarm?
Nein. Die Trendlinie ist Kontext, keine Benachrichtigung – wenn sie erscheint, wird nichts ausgelöst und niemand benachrichtigt. Der eigentliche Alarm wird erst ausgelöst, wenn die Metrik deinen Schwellenwert überschreitet und für die von dir konfigurierte Dauer darüber bleibt.
Mit einem kostenlosen Tool ausprobieren
War dieser Artikel hilfreich?
