Alarmmeldungen mit Befund und Reaktionsweg ausfüllen
Ein ausgearbeitetes Portalbeispiel verbindet Fehlerquote, Zuständigkeit und erste Prüfung. Ein Alarm allein beweist weder Ursache noch erfolgreiche Behebung.
Eine hilfreiche Alarmmeldung zeigt, was an einer Anwendung auffällt und welcher erste Reaktionsweg vorgesehen ist. Die Meldung muss für die empfangende Person verständlich sein, ohne dass sie den Dienst erst aus einem unbekannten Servernamen erraten muss.
Von der Nutzeraufgabe zum Signal
Beginnen Sie mit einer wichtigen Aufgabe, etwa dem Laden einer Projektliste im Kundenportal. Prometheus empfiehlt für interaktive Dienste unter anderem nutzerseitig sichtbare Fehler und passende Übersichten für die Ursachenprüfung. Ein Auslastungswert kann dabei Kontext liefern; er erklärt nicht automatisch, ob die Projektliste funktioniert.
Legen Sie fest, welche Anfragen und Antworten in die Messung eingehen. Wiederholte Aufrufe sind weitere Anfragen, nicht automatisch weitere betroffene Personen. Eine Fehlerquote braucht deshalb einen klaren Nenner.
Ein ausgearbeitetes Alarmbeispiel
Das folgende Softwareteam, seine Messwerte und Regeln sind frei erfunden. Es handelt sich weder um einen ASES-Vorfall noch um allgemeine Grenzwerte oder ein Supportversprechen. Alle erfassten Anfragen der genannten Operation bilden hier den Nenner. Die gewählte Regel bewertet ein 5-Minuten-Fenster; sie verlangt keine zusätzliche Haltezeit.
Feld | Ausgefülltes Beispiel |
|---|---|
Meldung | Projektliste im Kundenportal liefert Serverfehler. |
Umfang |
|
Zeitfenster | 09:10–09:15, Europe/Berlin |
Befund | 100 Anfragen, davon 20 mit Serverfehlerantworten |
Eigene Regel | Mehr als 10 % Serverfehler im 5-Minuten-Fenster bei mindestens 50 Anfragen. |
Zuständig | Bereitschaft von |
Einstieg | Übersicht für genau diesen Dienst, diese Operation und diesen Zeitraum; Runbook „Projektliste“. |
Hier sind sowohl die Mindestmenge als auch die Fehlergrenze überschritten. Die 20 % beschreiben Anfragen in diesem Fenster. Sie belegen keine entsprechende Quote betroffener Nutzer und keine bestimmte Ursache.
Die erste Reaktion vorbereiten
Das Runbook ist eine kurze Anleitung für den vorgesehenen Diagnoseweg. Zuerst bestätigt die zuständige Person die Übernahme und prüft, ob das Problem noch besteht. Eine Bestätigung bedeutet nicht, dass der Fehler behoben ist. Die Vorauswahl in der Übersicht muss dieselben Dienst-, Operations- und Zeitangaben übernehmen.
Danach werden betroffene Instanzen, Versionen und Abhängigkeiten eingegrenzt. Ein Release um 09:08 wäre im Beispiel ein zu prüfendes Ereignis, kein Ursachenbeweis. Eine Rücknahme braucht einen passenden, vorab geprüften Weg; die Alarmmeldung ist keine Freigabe für beliebige Neustarts oder Änderungen.
Den Meldeweg mitprüfen
Alertmanager kann ähnliche Meldungen gruppieren und an konfigurierte Empfänger leiten. Die betroffenen Instanzen müssen dabei weiter erkennbar bleiben. Unabhängige Probleme dürfen nicht allein wegen ähnlicher Namen zusammenfallen.
Prüfen Sie mit einer klar markierten Testmeldung auch Empfang, Übernahme und den vorgesehenen Ersatzweg. Prometheus nennt die Überwachung der eigenen Überwachung ausdrücklich. Später unauffällige Messwerte beenden möglicherweise die Alarmsituation; sie ersetzen weder die Prüfung der Nutzeraufgabe noch die weitere Ursachenanalyse. Fachlich falsche Erfolgsantworten oder langsame Antworten werden von dieser einfachen Serverfehlerregel allein nicht erfasst.
Quellen
Weiterlesen
Alle Beiträge
Cloud & Betrieb mit ASES
Hosting, Deployment, Wartung und Betreuung