Überlasteter Monitoring-Betrieb: Von tausenden Alerts zu wenigen Situationen

Um zwei Uhr morgens fällt ein Switch in einem Datenraum aus. Innerhalb von Minuten treffen Hunderte von Alarmen ein: nicht erreichbare Server, nicht erreichbare Datenbanken, fehlschlagende Anwendungen, Antwortzeiten außerhalb der Grenzen. Der Bereitschaftsingenieur erhält Benachrichtigung nach Benachrichtigung und muss herausfinden, was wichtig ist. Was ist die Ursache und was ist lediglich ein Symptom? Welche Dienste sind tatsächlich betroffen? Und ist dies vielleicht mit einem Change verbunden, der gerade zu diesem Zeitpunkt läuft?

Monitoring-Lärm ist nicht nur ein technisches Ärgernis. Bereitschaftsingenieure lernen allmählich, dass die meisten Alarme nichts bedeuten und beginnen, sie zu ignorieren. Dann trifft der eine Alarm ein, der wichtig ist, und geht verloren. Alert-Müdigkeit ist eines der ruhigsten Risiken in den Betriebsabläufen.

Warum das Hinzufügen von mehr Regeln nicht hilft

Die übliche Reaktion ist, Schwellenwerte zu optimieren und Ausnahmen im Monitoring-Tool selbst hinzuzufügen. Das hilft für eine Weile, aber Monitoring sieht nur seinen eigenen Ausschnitt der Welt. Es weiß nicht, dass die Datenbank auf einem Server läuft, der mit dem Switch verbunden ist, der gerade ausgefallen ist. Es weiß auch nicht, dass ein genehmigter Change gerade auf diesem Server läuft.

Wir sehen oft dieselben Muster:

• mehrere Monitoring-Tools melden dasselbe Problem gleichzeitig,
• ein Dienst „flattert“ zwischen Zuständen, und jede Zustandsänderung wird zu einem neuen Alarm,
• geplante Wartungen generieren Dutzende von Alarmen, die niemand benötigt,
• jeder Alarm wird zu einem Incident, und die Queue füllt sich mit Duplikaten.

Wie man es angeht

Lärm kann nicht an einer Stelle entfernt werden. Er muss schrittweise komprimiert werden, wie ein Trichter. Zuerst werden Duplikate und Flattern entfernt. Dann werden erwartete Alarme unterdrückt, wie Alarme während eines genehmigten Changes. Schließlich werden die verbleibenden Alarme nach ihrer Beziehung zueinander in der Infrastruktur gruppiert.

Die Topologie ist für diesen letzten Schritt unerlässlich. Wenn wir wissen, was von was abhängt, können wir abschätzen, welcher Alarm in einer Gruppe wahrscheinlich die Ursache ist. Wir wissen auch, welche Dienste betroffen sind.

Wie Eywo Stratum es handhabt

Eywo Stratum verarbeitet Ereignisse von Ihrem Monitoring, egal ob es Zabbix, Prometheus/Alertmanager, Checkmk, Grafana oder eine andere Quelle über eine generische API ist. Jedes Ereignis wird einem CMDB-Element zugeordnet.

Mehrere Schichten wirken auf den eingehenden Strom:

• Deduplikation – wiederholte Berichte über dasselbe Problem werden zu einem einzigen Alarm zusammengefasst,
• Flattern-Erkennung – ein Zustand, der ständig zwischen Zuständen wechselt, wird erkannt und nicht bei jeder Änderung gemeldet,
• Filter- und Unterdrückungsregeln – was bekannt und harmlos ist, muss nicht an Personen weitergeleitet werden,
• Unterdrückung während Changes – Alarme von Elementen mit einem genehmigten Change in Bearbeitung werden unterdrückt.

Die verbleibenden Alarme werden in Situationen gruppiert, basierend auf CMDB-Topologie, Diensten und Zeit. Jede Situation zeigt eine wahrscheinliche Ursache, d.h. das Element, von dem die anderen abhängen, zusammen mit verwandten Changes. Anstatt hundert Alarme zu sehen, sieht der Bereitschaftsingenieur eine Situation mit einer klaren Auswirkung.

Ein Incident kann in einem einzigen Schritt aus einer Situation erstellt werden, oder automatisch. Er enthält den betroffenen Dienst und das Resolver-Team, das aus der CMDB vorgeschlagen wird. Wenn das Problem nach der Lösung erneut auftritt, wird der Incident erneut geöffnet, anstatt ein neuer erstellt zu werden. Der gesamte Lärm-Reduzierungs-Trichter, von Ereignissen bis hin zu Alarmen, Situationen und Incidents, ist an einer Stelle sichtbar, sodass klar ist, woher der Lärm kommt und wo er gefiltert wird.

Weniger Lärm, mehr Aufmerksamkeit

Das Ziel ist nicht, dass Monitoring weniger meldet. Das Ziel ist, dass Personen nur das erhalten, was ihre Aufmerksamkeit benötigt, mit dem Kontext, den sie benötigen, um zu entscheiden. Ein Bereitschaftsteam, das seinen Alarmen vertraut, reagiert schneller und ruhiger. Und nach einer Nachtschicht können sie nach Hause gehen, wissend, dass sie ihre Zeit auf das gerichtet haben, was wichtig war.

Event-Management mit CMDB-basierter Korrelation und Lärmreduzierung ist in der Business-Edition enthalten.