Die gefährlichste Alert-Konfiguration ist nicht diejenige, die Ereignisse verpasst. Es ist diejenige, die so oft bei Nicht-Ereignissen auslöst, dass ihr niemand mehr vertraut. Wenn das Betriebsteam gelernt hat, den Monitoring-Posteingang zu ignorieren, weil drei Viertel der dort eingehenden Meldungen nur Rauschen sind, kommt das kritische Ereignis über denselben Kanal und erhält dieselbe Reaktion. Keine.
Alert Fatigue ist der Fehlermodus, der Monitoring schlimmer als nutzlos macht. Ein Team ohne Monitoring weiß, dass es kein Monitoring hat. Ein Team mit falsch konfiguriertem Monitoring glaubt, dass es Monitoring hat, während seine Alert-Reaktion durch Gewöhnung faktisch deaktiviert wurde. Die zweite Situation ist schwerer zu erkennen und schwerer zu beheben.
Dieser Artikel erklärt, wie Alert Fatigue entsteht, wodurch sie auf Konfigurationsebene verursacht wird und welche konkreten Praktiken das Rauschen reduzieren, ohne die Abdeckung zu verringern. Der Fokus liegt speziell auf SAP-Umgebungen, in denen die Kombination aus generischen Schwellenwerten, komplexen Batch-Zeitplänen und unterschiedlichen Komponententypen besondere Herausforderungen für das Alert-Design schafft.
Wie Alert Fatigue tatsächlich entsteht und warum sie schwer umzukehren ist
Das Muster der Gewöhnung
Alert Fatigue folgt einer konsistenten Abfolge, die sich über Wochen oder Monate entwickelt. Eine Monitoring-Plattform wird eingeführt, häufig mit Standardwerten oder nur leicht angepassten Schwellenwerten. In den ersten Tagen entsteht ein Alert-Volumen, das beherrschbar wirkt. Einige Alerts zeigen reale Bedingungen an. Viele nicht. Das Team untersucht die erste Welle, stellt fest, dass die meisten Alerts erwartetes Verhalten widerspiegeln, und entwickelt ein mentales Modell dafür, welche Alert-Typen ignoriert werden können.
Dieses mentale Modell ist das Problem. Sobald das Team einen bestimmten Alert-Typ als wahrscheinlich störend eingestuft hat, liest es ihn nicht mehr sorgfältig. Der Alert löst 40 Mal in einem Monat aus, und keine dieser 40 Auslösungen ist ein Incident. Beim 41. Mal handelt es sich um einen echten Incident. Das Team wirft einen kurzen Blick darauf, ordnet ihn dem Muster der vorherigen 40 Alerts zu und geht weiter. Der echte Incident bleibt unbeachtet in der Alert-Warteschlange.
Dieses Muster rückgängig zu machen, nachdem es sich etabliert hat, ist deutlich schwieriger, als es zu verhindern. Das Team hat ein Verhalten gelernt. Dieses Verhalten zu ändern, erfordert eine Verbesserung der zugrunde liegenden Signalqualität. Dafür müssen Schwellenwerte neu konfiguriert werden, was Baseline-Daten erfordert und Zeit kostet. Während dieser Übergangsphase weiß das Team nicht, welche Alerts jetzt zuverlässig sind und welche weiterhin Rauschen erzeugen. Vertrauen in das Monitoring-System muss von null wieder aufgebaut werden, Alert-Kategorie für Alert-Kategorie.
Warum stummgeschaltete Alerts schlimmer sind als weniger Alerts
Die Reaktion, die die meisten Teams wählen, wenn das Alert-Volumen nicht mehr beherrschbar ist, ist das Stummschalten. Einzelne Alerts, ganze Alert-Kategorien oder bestimmte Systeme werden stummgeschaltet, weil sie immer wieder auslösen, ohne eine Aktion zu erfordern. Der falsch konfigurierte Schwellenwert bleibt falsch konfiguriert. Das Rauschen verschwindet aus dem Posteingang. Die zugrunde liegende Bedingung, die der Alert erkennen sollte, tritt weiterhin auf, still und ohne jemanden zu erreichen.
Ein stummgeschalteter Alert ist nicht einfach still. Er ist eine aktive Entscheidung, eine bestimmte Bedingung auf einem bestimmten System nicht mehr zu überwachen. Diese Entscheidung wird implizit getroffen, unter Druck, während einer Phase, in der das Alert-Volumen das Team frustriert. Sie wird fast nie dokumentiert. Wenn die stummgeschaltete Bedingung später zu einem kritischen Incident wird, zeigt die Post-Mortem-Frage, warum das Monitoring ihn nicht erkannt hat, dass der relevante Alert acht Monate zuvor stummgeschaltet wurde, weil er damals Rauschen erzeugte.
Daraus folgt ein unbequemer, aber zutreffender Grundsatz: Weniger, gut konfigurierte Alerts sind sicherer als mehr Alerts, die Rauschen erzeugen. Eine Monitoring-Konfiguration, die zehn Bedingungen zuverlässig abdeckt, ist operativ wertvoller als eine Konfiguration, die dreißig Bedingungen unzuverlässig abdeckt. Das Ziel der Alert-Konfiguration ist nicht maximale Abdeckung. Es ist maximale zuverlässige Abdeckung.
Das Problem mit Standard-Schwellenwerten
Wofür Standard-Schwellenwerte tatsächlich kalibriert sind
Standard-Schwellenwerte in SAP-Monitoring-Tools sind für eine generische SAP-Umgebung kalibriert. Sie sind als sichere Startpunkte gedacht: konservativ genug, damit ein wirklich gesundes System sie nicht ständig auslöst, und aggressiv genug, damit ein wirklich beeinträchtigtes System sie auslöst. Sie sind nicht für Ihr System kalibriert.
Ihr System hat ein bestimmtes HANA-Allokationslimit, einen bestimmten Background-Job-Zeitplan, eine bestimmte Spitzenlast durch Nutzer zu einer bestimmten Tageszeit und eine bestimmte Gruppe von Schnittstellen mit eigenen Traffic-Mustern. Der generische Schwellenwert wird auf dieses spezifische System gelegt, ohne davon etwas zu wissen. Ein CPU-Schwellenwert von 80 % löst während Ihres MRP-Laufs jeden Montagmorgen aus, weil der MRP-Lauf am Montagmorgen die CPU schon immer auf 82 % gebracht hat. Das ist erwartetes Verhalten. Der Schwellenwert weiß das nicht. Er löst trotzdem aus.
Das mathematische Ergebnis ist vorhersehbar. Ein Schwellenwert, der auf einen Wert gesetzt ist, den der Normalbetrieb in 5 % der Zeit berührt, erzeugt über alle überwachten Metriken und Systeme hinweg eine Alert-Rate, die die Reaktionskapazität des Teams übersteigt. Das Team beginnt, die Alerts zu ignorieren. Die Konfiguration driftet in den oben beschriebenen stummgeschalteten Zustand.
Das 80-Prozent-Problem: Wie eine sinnvolle Zahl nutzlos wird
Achtzig Prozent sind der häufigste Startpunkt für auslastungsbasierte Alert-Schwellenwerte. Dialog-Work-Process-Auslastung über 80 %, CPU über 80 %, Speicher über 80 %. Das ist keine willkürliche Zahl. Sie spiegelt die vernünftige Intuition wider, dass ein System, das mehr als 80 % einer Ressource nutzt, unter nennenswerter Last steht und nur begrenzten Spielraum hat.
Das Problem ist, dass 80 % keinen Bezug dazu haben, was für ein bestimmtes System zu einer bestimmten Zeit normal ist. Ein System, dessen Dialog-Work-Process-Auslastung jeden Tag um 09:15 während der morgendlichen Transaktionsspitze 85 % erreicht, bis 10:00 wieder auf 55 % zurückgeht und sich seit zwei Jahren so verhält, hat einen normalen Peak oberhalb von 80 %. Bei 80 % auf diesem System zu alarmieren bedeutet, täglich auf erwartetes Verhalten zu alarmieren. Nach drei Wochen hat das Betriebsteam gelernt, dass der WP-Auslastungsalert um 09:15 ignoriert werden kann. Sechs Monate später, wenn der WP-Pool wegen eines fehlerhaften Prozesses tatsächlich bei 95 % saturiert, löst der Alert um 09:13 aus und das Team schaut erst um 09:45 darauf.
Die Lösung besteht nicht darin, den Schwellenwert auf 90 % anzuheben. Das verschiebt das Problem der Fehlalarme nur nach oben. Die Lösung ist ein Schwellenwert, der auf das tatsächliche Verhalten dieses Systems zu dieser konkreten Tageszeit kalibriert ist und auf einem Niveau liegt, das wirklich ungewöhnlich ist, statt regelmäßig erwartet zu werden.
Baseline-basierte Schwellenwertkonfiguration
Wie eine echte Baseline aussieht: Verteilung, nicht Durchschnitt
Eine Baseline, die auf Durchschnittswerten basiert, ist für die Schwellenwertkonfiguration nicht hilfreich. Die durchschnittliche Dialog-Work-Process-Auslastung über einen Geschäftstag hinweg liegt bei einem System, das die meiste Zeit bei 40 % läuft und jeden Morgen 15 Minuten lang 88 % erreicht, ungefähr bei 48 %. Ein Schwellenwert bei 70 % des Durchschnitts läge bei 34 % und würde ständig auslösen. Ein Schwellenwert bei 150 % des Durchschnitts läge bei 72 % und würde während des Morgen-Peaks auslösen, sonst aber nicht. Keiner von beiden bildet die tatsächliche Struktur der Metrik ab.
Eine nützliche Baseline ist eine Perzentilverteilung der Metrikwerte, die über einen repräsentativen Zeitraum beobachtet und nach Zeitfenstern segmentiert wurden. Welcher Wert entspricht dem 95. Perzentil der Dialog-WP-Auslastung zwischen 09:00 und 10:00 an Wochentagen? Welcher Wert entspricht dem 95. Perzentil zwischen 02:00 und 05:00 während der nächtlichen Batch-Verarbeitung? Diese beiden Fragen haben unterschiedliche Antworten, und ein Schwellenwert, der beide abdecken soll, muss zeitbewusst und nicht statisch sein.
Der praktische Prozess: Erfassen Sie Metrikdaten in Ein-Minuten-Intervallen über vier bis sechs Wochen, einschließlich mindestens eines Monatsabschlusszyklus. Berechnen Sie für jede Metrik, für die Sie alerten möchten, die Perzentilverteilung nach Tagesstunde und Wochentag. Setzen Sie die Alert-Schwellenwerte auf das 98. oder 99. Perzentil der normalen Werte in jedem Zeitfenster. Ein Schwellenwert beim 99. Perzentil des normalen Verhaltens löst nur aus, wenn die Metrik die Normalität mit deutlichem Abstand überschreitet. Die Fehlalarmrate sinkt nahezu auf null. Die True-Positive-Rate bleibt hoch, weil wirklich abnormale Bedingungen das 99. Perzentil des Normalverhaltens per Definition überschreiten.
Zeitbewusste Schwellenwerte: Die Einstellung, die die meisten Konfigurationen überspringen
Die meisten SAP-Monitoring-Tools unterstützen zeitbasierte Schwellenwertvariationen. Die meisten SAP-Monitoring-Konfigurationen nutzen sie nicht. Das Ergebnis ist ein einzelner Schwellenwert, der gleichmäßig auf 24 Stunden Systemverhalten angewendet wird, obwohl dieses Verhalten je nach Tageszeit stark variiert.
Die konkreten Bereiche, in denen zeitbewusste Schwellenwerte in einer SAP-Umgebung wichtig sind, sind: Background-Work-Process-Auslastung, höher während nächtlicher Batch-Läufe und niedriger während der Geschäftszeiten; Dialog-Work-Process-Auslastung, höher während der Geschäftszeiten und nachts nahezu null; HANA-Speicher während des Monatsabschluss-Batchs, vorhersehbar höher als im Tagesbetrieb; und Schnittstellen-Nachrichtenvolumen, das zwischen Geschäftszeiten und außerhalb dieser Zeiten erheblich variiert.
Die Implementierung zeitbewusster Schwellenwerte setzt voraus, die Muster im Voraus zu kennen, was Baseline-Daten erfordert. Sie erfordert auch mehr Konfigurationsarbeit als ein einzelner globaler Schwellenwert. Der Nutzen ist eine drastische Reduzierung von Fehlalarmen während vorhersehbarer Hochlastfenster. Genau in diesen Zeitfenstern muss das Team darauf vertrauen können, dass ein auslösender Alert bedeutet, dass sich wirklich etwas verändert hat, und nicht, dass etwas Erwartetes erneut eingetreten ist.
Der minimale Baseline-Zeitraum, bevor Schwellenwerte sinnvoll sind
Zwei Wochen Baseline-Daten reichen nicht aus. Das Problem ist, dass zwei Wochen möglicherweise nur eine oder zwei Vorkommen eines bestimmten Workload-Musters enthalten. Ein Monatsabschlusszyklus tritt in einem Zwei-Wochen-Fenster nur einmal auf. Ein Batch-Lauf zum Quartalsende tritt möglicherweise gar nicht auf. Ein Wartungsfenster am Samstag kann in diesen zwei Wochen enthalten sein oder nicht.
Vier bis sechs Wochen erfassen die meisten wiederkehrenden Muster: den wöchentlichen Batch-Zyklus, mindestens einen Monatsabschluss, die Variation der Nutzerlast je nach Wochentag und die Unterschiede zwischen den ersten und letzten Wochen eines Geschäftsmonats. Sechs Wochen sind das praktische Minimum für ein Produktivsystem, bei dem Baseline-Genauigkeit wichtig ist.
Während der Baseline-Erfassungsphase sollten Alerts entweder noch nicht konfiguriert sein oder nur bei eindeutig schweren Bedingungen auslösen: HANA-Log-Volume über 90 %, null aktive Dialog-Work-Processes, ausgefallener Update-Service. Der Zweck dieser Phase ist Datenerfassung, nicht Alert-Abdeckung. Der Versuch, am dritten Tag des Monitorings eines neuen Systems sinnvolle Alert-Schwellenwerte zu konfigurieren, führt zum gleichen Ergebnis wie Standardwerte: Schwellenwerte, die das Verhalten dieses Systems nicht widerspiegeln.
In der Praxis: Die Baseline-Erfassungsphase ist auch die Zeit, in der das Betriebsteam ein Gefühl für das System entwickelt. Vier Wochen ohne konfigurierte Alerts zu arbeiten und stattdessen täglich die Metrikdaten zu lesen, schafft ein qualitatives Verständnis des Systemverhaltens, das genauso wertvoll ist wie die quantitative Baseline. Teams, die die Baseline-Phase überspringen, weil sie sofort Alerts konfigurieren möchten, überspringen auch diese Lernphase.
Alert-Schweregrade und Routing: Das richtige Signal an die richtige Person bringen
Das binäre Warning/Critical-Design und sein Fehlermodus
Die meisten Monitoring-Konfigurationen verwenden zwei Schweregrade: Warning und Critical. Warning bedeutet, dass etwas geprüft werden sollte. Critical bedeutet, dass etwas dringend ist. In der Praxis werden beide häufig an denselben Posteingang geroutet, wo die Unterscheidung zwischen ihnen eher zu einem Priorisierungssignal als zu einem Routing-Signal wird. Wenn am selben Dienstagnachmittag 40 Warning-Alerts und 3 Critical-Alerts eingehen, arbeitet das Team sie ungefähr der Reihe nach ab. Die Critical-Alerts erhalten Aufmerksamkeit. Die Warnings werden verschoben. Einige der verschobenen Warnings stehen für Bedingungen, die kurz davor waren, kritisch zu werden.
Ein Drei-Stufen-Modell ist dafür effektiver. Die erste Stufe ist informativ: Bedingungen werden für Trendanalysen protokolliert, erfordern aber keine Aktion. Ein Beispiel ist eine tägliche Performance-Zusammenfassung, die zeigt, dass die durchschnittliche Dialog-Antwortzeit im Normalbereich liegt. Keine Aktion erforderlich. Die zweite Stufe ist handlungsrelevant: Bedingungen, die während der Geschäftszeiten geprüft werden müssen, aber keine sofortige Reaktion erfordern. Eine Schnittstellenfehlerrate oberhalb ihrer normalen Baseline, ein Background-Job, der 40 % länger läuft als üblich, ein HANA-Speichertrend, der diese Woche gestiegen ist. Diese Punkte benötigen Aufmerksamkeit, aber nicht unbedingt heute Nacht. Die dritte Stufe ist dringend: Bedingungen, die unabhängig von der Uhrzeit sofortige Reaktion erfordern. HANA-Log-Volume über 85 %, keine Background-Work-Processes verfügbar, Produktivsystem nicht erreichbar, Update-Service deaktiviert.
Der Wert des Drei-Stufen-Modells liegt darin, die Routing-Logik von der Schwellenwertlogik zu trennen. Dieselbe Metrik kann zwei unterschiedliche Schwellenwerte haben, die auf zwei verschiedene Stufen zeigen. Dialog-WP-Auslastung über 80 % für mehr als 5 Minuten wird an die handlungsrelevante Stufe geroutet: Prüfung innerhalb einer Stunde. Dialog-WP-Auslastung über 95 % für mehr als 2 Minuten wird an die dringende Stufe geroutet: sofort reagieren.
Routing-Design: Wer bekommt welche Stufe und wann
Die Routing-Frage ist genauso wichtig wie die Schwellenwertfrage, erhält aber weniger Aufmerksamkeit. Ein dringender Alert, der an einen allgemeinen Posteingang geroutet wird, der einmal pro Stunde geprüft wird, ist in der Praxis kein dringender Alert. Ein handlungsrelevanter Alert, der um 03:00 an Bereitschaftstechniker geschickt wird, obwohl die Bedingung bis zum Morgen warten kann, erzeugt unnötige Störungen und führt mit der Zeit zur gleichen Gewöhnungsreaktion wie Alert-Rauschen.
Routing-Design erfordert explizite Entscheidungen zu drei Dingen: Wer ist der richtige Empfänger für jeden Alert-Typ, welche Reaktionszeit wird für jede Stufe erwartet, und was passiert, wenn der primäre Empfänger nicht innerhalb des erwarteten Zeitfensters reagiert. Für dringende Alerts sollte die Antwort eine Eskalationskette mit definierten Zeiten sein: primärer Kontakt, Eskalation zum sekundären Kontakt nach 10 Minuten, Eskalation an den Manager nach 25 Minuten. Für handlungsrelevante Alerts sollte die Antwort eine Team-Queue mit einem definierten Review-SLA sein.
Der am häufigsten übersehene Teil des Routing-Designs ist die Unterscheidung zwischen der Person, die einen Alert erhalten sollte, und der Person, die darauf reagieren sollte. Ein kritischer HANA-Log-Volume-Alert sollte den Basis-Ingenieur in Bereitschaft erreichen. Er sollte auch den Business Process Owner erreichen, dessen Monatsabschluss unterbrochen würde, wenn das System stehen bleibt. Das sind unterschiedliche Personen mit unterschiedlichen Rollen in der Reaktion. Denselben Alert an beide zu routen, mit unterschiedlichem Kontext in jeder Benachrichtigung, erfüllt beide Anforderungen.
Der Bereitschafts-Eskalationspfad, der nie getestet wurde
Die meisten Organisationen haben eine Bereitschaftsrotation und einen dokumentierten Eskalationspfad. Weniger haben getestet, ob dieser Eskalationspfad tatsächlich Ende zu Ende funktioniert. Die Telefonnummern im Runbook können veraltet sein. Die Pager-Integration kann bei einem Update des Monitoring-Tools beschädigt worden sein. Die Eskalationslogik kann in der Tool-Konfiguration korrekt routen, aber keine Benachrichtigung erzeugen, weil sich das SMTP-Relay geändert hat.
Ein Eskalationspfad, der unter realistischen Bedingungen nie Ende zu Ende getestet wurde, ist eine Annahme, keine Fähigkeit. Ihn zu testen bedeutet, einen echten Alert absichtlich und kontrolliert auszulösen und zu bestätigen, dass die Benachrichtigung die richtige Person über den richtigen Kanal im erwarteten Zeitfenster erreicht. Dieser Test sollte stattfinden, wenn der Eskalationspfad erstmals konfiguriert wird, und anschließend vierteljährlich wiederholt werden. Er dauert 15 Minuten und deckt defekte Konfigurationen auf, bevor sie während eines echten Incidents entdeckt werden.
Unterdrückung, Korrelation und Steuerung des Alert-Volumens ohne Abdeckungsverlust
Wartungsfenster und Alerts, die währenddessen nicht auslösen sollten
Geplante Wartungsaktivitäten in SAP-Produktionsumgebungen erzeugen Monitoring-Bedingungen, die wie Incidents aussehen: Services werden gestoppt und neu gestartet, HANA wechselt während eines Patching-Zyklus vom primären auf den sekundären Knoten, Batch-Jobs laufen nicht, weil das System kurzzeitig nicht verfügbar ist. Ohne Unterdrückung erzeugen diese Aktivitäten während des Wartungsfensters Dutzende Alerts, von denen die meisten an Bereitschaftstechniker geroutet werden, die bereits den Wartungsplan ausführen.
Die Unterdrückung während Wartungsfenstern eliminiert dieses Rauschen. Die Monitoring-Plattform weiß, dass sich das System in einem geplanten Zustand befindet. Alerts werden entweder vollständig unterdrückt oder zur Prüfung nach Abschluss des Fensters erfasst, statt in Echtzeit an die Bereitschaft geroutet zu werden. Der Bereitschaftstechniker kann sich auf die Wartungsaufgabe konzentrieren, statt Alerts zu triagieren, die erwartete Folgen der Wartung selbst sind.
Die Unterdrückung muss eine Endzeit haben. Eine offene Unterdrückung, die über das geplante Wartungsfenster hinausläuft, bedeutet, dass das System ohne Monitoring-Abdeckung in den Produktivbetrieb zurückkehrt, bis jemand die Alerts manuell wieder aktiviert. Das richtige Verhalten ist eine automatische Reaktivierung am Ende des Wartungsfensters, mit einer kurzen Restabilisierungsphase, bevor Alerts wieder aktiv werden. Eine Unterdrückung, die manuell deaktiviert werden muss, wird irgendwann vergessen und erzeugt ein Produktivsystem, das überwacht erscheint, es aber nicht ist.
Flapping-Erkennung: Der Schwellenwert, der überschritten und wieder unterschritten wird
Flapping ist die Bedingung, bei der eine Metrik einen Schwellenwert überschreitet, sich kurz erholt, ihn erneut überschreitet und sich wieder erholt. Jede Überschreitung erzeugt einen Alert. Jede Erholung erzeugt eine Auflösung. Der Posteingang erhält abwechselnd Alert- und Auflösungsbenachrichtigungen, während die zugrunde liegende Bedingung um den Schwellenwert oszilliert. Das Team lernt, dass dieses Muster aus Alert, Auflösung und erneutem Alert bedeutet: Die Metrik liegt nahe am Schwellenwert und ist instabil. Das hat eine andere operative Bedeutung als: Die Metrik hat den Schwellenwert überschritten und die Bedingung benötigt Aufmerksamkeit.
Flapping-Erkennung verhindert dieses Muster, indem sie verlangt, dass eine Metrik für eine anhaltende Zeit oberhalb des Schwellenwerts bleibt, bevor ein Alert auslöst, und für eine anhaltende Zeit unterhalb des Schwellenwerts bleibt, bevor der Alert aufgelöst wird. Diese Dauer sollte auf die normale Beruhigungszeit der Metrik kalibriert sein. Die Dialog-Work-Process-Auslastung kann während einer normalen Transaktionsspitze in 30 Sekunden ansteigen und wieder zurückgehen. Ein Alert, der 3 Minuten anhaltende Auslastung oberhalb des Schwellenwerts verlangt, erzeugt keine Flapping-Alerts bei kurzen Peaks, erkennt aber echte Sättigung, die anhält.
Die Konfiguration einer anhaltenden Dauer reduziert Fehlalarme bei schnell beweglichen Metriken, ohne die Abdeckung bei langsam beweglichen Metriken zu verringern. Eine Metrik, die 4 Minuten lang auf 95 % steigt, ist eine andere Situation als eine Metrik, die 20 Sekunden lang auf 95 % steigt. Die Alert-Konfiguration sollte diesen Unterschied widerspiegeln.
Unterdrückung abhängiger Alerts: Eine Ursache, ein Incident
Wenn der HANA-Speicher kritischen Druck erreicht, kann eine Kaskade sekundärer Bedingungen folgen: Delta Merges werden abgebrochen, um Speicher freizugeben, Work Processes mit speicherintensiven Operationen terminieren, Background-Jobs, die auf diese Prozesse gewartet haben, verpassen ihre Startfenster, und Schnittstellen-Queues bauen sich auf, weil die Verarbeitungskapazität, die sie normalerweise bedient, ausgelastet ist. Jede dieser sekundären Bedingungen kann unabhängig einen Alert auslösen.
Ohne Unterdrückung abhängiger Alerts erzeugt eine einzige Ursache fünf Alerts, die gleichzeitig an das Betriebsteam geroutet werden. Das Team öffnet fünf Tickets, beginnt mit der Triage jedes einzelnen, stellt fest, dass alle durch dasselbe HANA-Speicherereignis verursacht wurden, und verbringt die nächste Stunde damit, etwas zu konsolidieren, das ein einzelner Incident hätte sein sollen. Die Ursache hatte ein klares Signal: den HANA-Speicher-Alert. Die sekundären Signale haben Arbeit hinzugefügt, nicht Information.
Die Unterdrückung abhängiger Alerts erfordert die Definition von Abhängigkeitsbeziehungen: Wenn Metrik A auslöst, werden Metriken B, C und D für einen definierten Zeitraum unterdrückt. Das ist mehr Konfigurationsarbeit als unabhängige Alert-Regeln und erfordert ein Verständnis dafür, welche Bedingungen in der konkreten SAP-Landschaft welche nachgelagerten Effekte verursachen. Der Nutzen ist, dass das Betriebsteam ein handlungsrelevantes Signal statt fünf korrelierter Signale erhält, was die Triage-Zeit reduziert und die Reaktionsqualität verbessert.
SAP-spezifische Alert-Bedingungen, die sorgfältig gestaltet werden sollten
Die Schwellenwerte, die in SAP-Umgebungen am häufigsten falsch konfiguriert sind
Das HANA-Log-Volume ist in den meisten SAP-Umgebungen der gefährlichste falsch konfigurierte Schwellenwert. Standard- oder generische Schwellenwerte werden häufig bei 80 % oder 85 % gesetzt. Der richtige Schwellenwert liegt bei 70 %. Die Begründung ist nicht, dass 70 % grundsätzlich richtig wären, sondern dass der Abstand zwischen 70 % und 100 % groß genug sein muss, damit zwei Dinge passieren können: Der Alert löst aus, der Bereitschaftstechniker untersucht und identifiziert die Ursache, etwa nicht laufende Log-Backups, ein volles Backup-Medium oder ein Log-Backup-Intervall, das für das aktuelle Schreibvolumen zu groß ist, und die Behebung erfolgt, bevor das Log-Volume 100 % erreicht. Bei 85 % ist dieser Abstand klein. Bei 70 % ist er toleranter.
Schwellenwerte für die Dialog-Work-Process-Auslastung benötigen mehr Zeitbewusstsein als jede andere SAP-Metrik. Ein statischer Schwellenwert für Dialog-WP-Auslastung löst entweder während Spitzenzeiten zu häufig aus oder verpasst Sättigungsereignisse außerhalb der Spitzenzeiten. Der korrekt konfigurierte Schwellenwert für diese Metrik ist während erwarteter Spitzenfenster höher und während Zeiten, in denen jede erhöhte Auslastung ungewöhnlich ist, niedriger.
Alerts für Background-Job-Fehler sollten keinen einzigen Schwellenwert für alle Jobs verwenden. Ein Tier-1-Job, definiert als Job mit harter geschäftlicher Frist und hohem Ausfallimpact, sollte bei jedem Fehler einen dringenden Alert erzeugen. Ein Tier-3-Housekeeping-Job, der täglich läuft und dessen Fehler keinen unmittelbaren geschäftlichen Impact hat, sollte einen informativen Log-Eintrag erzeugen, keinen Bereitschaftsalert. Die meisten Monitoring-Konfigurationen alarmieren entweder bei allen Job-Fehlern mit derselben Schwere oder bei keinem. Das richtige Design erfordert eine Klassifizierung des Job-Portfolios nach Kritikalität. Diese Arbeit zahlt sich spätestens dann aus, wenn ein Tier-3-Job-Fehler um 02:00 niemanden aufweckt.
Schnittstellenfehlerraten erfordern eine Unterscheidung zwischen absoluter Anzahl und Rate. Fünf IDoc-Fehler pro Tag sind eine andere Situation, je nachdem, ob die Schnittstelle normalerweise 50 IDocs pro Tag oder 5.000 verarbeitet. Als absolute Anzahl sehen fünf Fehler in beiden Fällen gleich aus. Als Rate sind es im ersten Fall 10 % und im zweiten 0,1 %. Die relevante Alert-Konfiguration ist ratenbasiert, mit einer Baseline-Fehlerrate für jede Schnittstelle, die während der Baseline-Erfassungsphase festgelegt wird, und einem Schwellenwert, der als relative Steigerung gegenüber dieser Baseline definiert ist.
Achtung: Short-Dump-Rate-Alerts, die als absolute Zahlen konfiguriert sind, liefern während Periodenabschlussaktivitäten, System-Upgrades oder neuen Programm-Rollouts irreführende Ergebnisse. Alle diese Ereignisse können die Short-Dump-Häufigkeit vorübergehend erhöhen, ohne auf eine monitoringwürdige Bedingung hinzuweisen. Alerting auf Short Dumps ist am nützlichsten als Trendmetrik: Eine Rate, die über drei aufeinanderfolgende Wochen Woche für Woche steigt, sollte untersucht werden, selbst wenn die absolute Anzahl nie einen hohen Schwellenwert überschreitet. Die Konfiguration des Alerts auf den Trend statt auf die absolute Anzahl erkennt die schrittweise Stabilitätsverschlechterung, die absolute Zahlen übersehen.
Alerts testen und Konfigurationsqualität im Zeitverlauf erhalten
Prüfen, bevor man sich darauf verlässt: Der Test, den fast niemand macht
Eine Alert-Konfiguration, die unter realen Bedingungen noch nie einen echten Alert erzeugt hat, hat eine unbekannte Zuverlässigkeit. Der Schwellenwert kann korrekt gesetzt sein. Das Routing kann korrekt konfiguriert sein. Die ITSM-Integration kann korrekt gemappt sein. Nichts davon ist bestätigt, bis ein Alert auslöst und der gesamte Weg von der Erkennung über die Benachrichtigung bis zum Incident-Ticket Ende zu Ende beobachtet wurde.
Einen bestimmten Alert bewusst zu testen, ist bei den meisten Bedingungen einfach. Senken Sie den Schwellenwert vorübergehend unter den aktuellen Metrikwert. Bestätigen Sie, dass der Alert auslöst. Bestätigen Sie, dass die Benachrichtigung den richtigen Empfänger erreicht. Bestätigen Sie, dass das Incident-Ticket mit der richtigen Klassifizierung und dem richtigen Inhalt erstellt wird. Setzen Sie den Schwellenwert wieder auf den vorgesehenen Wert. Der gesamte Prozess dauert 10 Minuten pro Alert-Kategorie. Für die fünf oder sechs kritischsten Alert-Kategorien sollte dieser Test bei der Erstkonfiguration und immer dann stattfinden, wenn sich die Monitoring-Plattform oder die ITSM-Integration ändert.
Der nützlichere Test ist eine Ende-zu-Ende-Übung: Simulieren Sie ein realistisches Incident-Szenario, zum Beispiel HANA-Speicher, der sich dem Limit nähert, was in einem Nicht-Produktionssystem oder durch einen kontrollierten Test in Produktion simuliert werden kann. Beobachten Sie die gesamte Sequenz von Erkennung bis Reaktion, messen Sie die Zeit vom Auftreten der Bedingung bis zur Alert-Bestätigung und identifizieren Sie Lücken im Routing oder in der Eskalation. Das ist eine 30-minütige Übung, die wertvoller ist als jede theoretische Validierung. Die meisten Organisationen führen solche Übungen für Disaster Recovery durch. Nur wenige wenden dieselbe Praxis auf Monitoring-Alerting an.
Die monatliche Review-Gewohnheit, die Alert-Qualität langfristig erhält
Alert-Konfigurationen verschlechtern sich ohne aktive Wartung mit der Zeit. Das System verändert sich. Die Workload entwickelt sich weiter. Schwellenwerte, die vor sechs Monaten genau waren, spiegeln das aktuelle Normalverhalten nicht mehr wider. Alerts, die relevant waren, als eine bestimmte Integration aktiv war, werden nach der Außerbetriebnahme dieser Integration zu Rauschen. Neue Fehlermodi entstehen, die durch bestehende Alerts nicht abgedeckt werden.
Ein monatliches Review muss nicht lange dauern. Es muss folgende Fragen beantworten: Welche Alert-Kategorien haben im letzten Monat mehr als 20 Mal ausgelöst und eine Bestätigungsrate unter 50 % gehabt, welche Metrik-Baselines sind mehr als 15 % von den Werten abgewichen, die zur Festlegung der aktuellen Schwellenwerte verwendet wurden, und gab es Bedingungen, die im letzten Monat Incidents verursacht haben, aber von keinem Alert erkannt wurden. Die erste Frage identifiziert Rauschen. Die zweite identifiziert Schwellenwertdrift. Die dritte identifiziert Abdeckungslücken.
Das Review muss auch stummgeschaltete Alerts prüfen. Jeder Alert, der seit mehr als 30 Tagen stummgeschaltet ist, sollte überprüft werden: Entweder wurde die zugrunde liegende Bedingung behoben und der Alert wird nicht mehr benötigt, der Schwellenwert war falsch konfiguriert und muss angepasst werden, oder die Unterdrückung ist nicht mehr gerechtfertigt und der Alert sollte wieder aktiviert werden. Stummgeschaltete Alerts, die nie überprüft werden, sammeln sich zu einer Monitoring-Konfiguration an, die umfassend aussieht, aber erhebliche undokumentierte Lücken enthält.
Das Ergebnis jedes Reviews sollte eine kurze Aufzeichnung dessen sein, was geändert wurde und warum: welche Schwellenwerte angepasst wurden, welche Alerts aktiviert oder deaktiviert wurden, welche neuen Alert-Kategorien hinzugefügt wurden. Diese Aufzeichnung wird zur Dokumentation, die der nächsten Person, die das System übernimmt, die aktuelle Konfiguration erklärt. So wird der Zyklus undokumentierter Verschlechterung vermieden, der die meisten Monitoring-Konfigurationen nach zwei Jahren Produktivbetrieb kennzeichnet.
Alert-Konfiguration ist eine kontinuierliche Aktivität, keine Setup-Aufgabe
Die Betrachtung der Alert-Konfiguration als etwas, das einmal bei der Einführung erledigt wird, ist die Ursache der meisten Monitoring-Fatigue-Probleme. Die Erstkonfiguration ist eine bestmögliche Annäherung auf Basis begrenzter Informationen. Sie wird besser, wenn Baseline-Daten entstehen, wenn das Team das System unter unterschiedlichen Lastbedingungen beobachtet und wenn Incidents Abdeckungslücken offenlegen, die nicht vorhergesehen wurden.
Eine aktiv gepflegte Monitoring-Konfiguration, bei der Schwellenwerte anhand aktueller Baselines angepasst, Routing-Regeln bei Veränderungen der Teamstruktur aktualisiert und stummgeschaltete Alerts regelmäßig überprüft werden, funktioniert deutlich besser als eine Konfiguration, die bei der Einführung sorgfältig eingerichtet und danach als abgeschlossen betrachtet wurde. Der Unterschied ist nicht technisch. Es ist die Praxis, Alert-Qualität als Metrik zu behandeln, die verfolgt werden sollte, genauso wie Verfügbarkeit oder Antwortzeit verfolgt werden.
Betriebsteams, die ihrem Monitoring genug vertrauen, um auf Alerts ohne gewöhnungsbedingte Skepsis zu reagieren, sind diejenigen, deren Alert-Konfiguration die aktuelle Realität widerspiegelt. Jeder Alert, der auslöst, hat ausgelöst, weil sich wirklich etwas verändert hat. Das Team weiß das, weil es die Konfiguration so gepflegt hat, dass es wahr bleibt. Dieses Vertrauen ist das Ergebnis, das alle Praktiken in diesem Artikel erzeugen sollen. Es ist nicht der Ausgangszustand. Es wird aufgebaut, Alert für Alert und Review für Review, aus einer Konfiguration, die es verdient.
Die Alert-Konfiguration von Redpeaks nutzt systembezogene Baselines, zeitbewusste Schwellenwerte und schwergradbasiertes Routing mit nativer ITSM-Integration. Alert-Qualitätsmetriken sind in der Plattform sichtbar, sodass Teams Fehlalarmraten und Abdeckungslücken im Zeitverlauf verfolgen können. Erfahren Sie, wie Redpeaks SAP-Alerting verwaltet.
