Support & Automatisierung

Monitoring-Alert

Overview

Ein Monitoring-Alert ist die automatische Benachrichtigung, die ein Überwachungssystem auslöst, wenn eine Regel greift: CPU, Speicher oder Plattenplatz über Schwellwert, Dienst nicht erreichbar, Backup-Job fehlgeschlagen, Zertifikat läuft ab. Zugestellt wird per E-Mail, SMS, Push, Teams-Nachricht, Webhook oder direkt als Ticket.

Typische Implementierungen sind Alertregeln mit Aktionsgruppen in Azure Monitor, Benachrichtigungen in PRTG, Trigger in Zabbix, Checkmk-Regeln und Alarme in RMM-Tools. Azure Monitor kennt Metrik-, Logsuche-, Aktivitätsprotokoll-, Smart-Detection- und Prometheus-Alerts und unterscheidet zustandsbehaftete Alerts (lösen erst nach Auflösung erneut aus) von zustandslosen.

Abgrenzung: IT-Monitoring ist die laufende Überwachung insgesamt, der Monitoring-Alert ist das einzelne Ereignis, das daraus eine Handlung auslöst.

How it works

Ein Alert entsteht aus drei Bausteinen:

  1. Signal: Metrik, Logabfrage oder Ereignis, z. B. freier Speicher auf Laufwerk C.
  2. Regel: Bedingung, Schwellwert, Auswertungszeitraum und Schweregrad, z. B. unter 10 Prozent für 15 Minuten.
  3. Aktion: Benachrichtigung oder Automatisierung, in Azure Monitor über Aktionsgruppen (E-Mail, SMS, Push, Webhook, Logic App, Azure Function, Runbook, ITSM-Ticket).

In Azure Monitor wechselt ein ausgelöster Alert in den Zustand fired und nach Wegfall der Bedingung in resolved, ein zustandsbehafteter Metrik-Alert gilt nach drei unauffälligen Prüfungen als aufgelöst. Alert-Verarbeitungsregeln unterdrücken Benachrichtigungen während geplanter Wartungsfenster, ohne die Regeln selbst abzuschalten.

Benefits

  • Störungen werden erkannt, bevor Anwender sie melden, das verkürzt Ausfallzeiten
  • Schwellwerte für Kapazität geben Vorlauf, bevor ein Laufwerk vollläuft oder ein Zertifikat abläuft
  • Automatische Tickets aus Alerts sorgen dafür, dass jede Meldung bearbeitet und dokumentiert wird
  • Automatisierte Reaktionen wie Dienstneustart per Runbook beheben einfache Fehler ohne Eingriff

Practical example

Ein Lebensmittelhersteller mit Schichtbetrieb bemerkte Ausfälle des Etikettendruckservers oft erst durch Anrufe aus der Produktion. Die IT richtete in PRTG Alerts für Dienststatus und Druckwarteschlange ein, kritische Alarme erzeugen per E-Mail-Eingang ein Ticket der Priorität 1 und eine Push-Nachricht an den Bereitschaftsdienst. Ausfälle werden seitdem meist behoben, bevor die Linie steht.

Things to keep in mind

  • Nur Alerts einrichten, auf die jemand konkret reagieren muss, Alarmflut führt dazu, dass wichtige Meldungen übersehen werden
  • Schweregrade festlegen und an Benachrichtigungsweg und Bereitschaft koppeln
  • Während Wartungsfenstern Benachrichtigungen gezielt unterdrücken statt Regeln zu deaktivieren, sonst wird das Wiedereinschalten vergessen
  • Alarmweg regelmäßig testen, ein Monitoring mit defektem Mailversand meldet nichts

Licensing & availability

Azure-Monitor-Alerts werden nutzungsbasiert abgerechnet, Metrik-Alertregeln nach Anzahl überwachter Zeitreihen, SMS und Sprachanrufe in Aktionsgruppen gesondert. PRTG wird nach Sensoranzahl lizenziert, Zabbix ist Open Source, Checkmk gibt es als Raw Edition (Open Source) und kommerzielle Editionen. RMM-Tools rechnen meist pro Endpunkt ab. Stand: Oktober 2026.

Conclusion

Monitoring-Alerts sind nur so gut wie die Reaktion darauf. Halte die Anzahl klein, verknüpfe sie mit dem Ticketsystem und teste den Alarmweg regelmäßig.

Further reading

Related articles