13. Oktober 2026

IT-Monitoring-Konzept: Ziele, Messpunkte, Schwellen und Alarmwege

Grafik mit Monitoring-Symbol und dem Titel IT-Monitoring-Konzept

IT-Monitoring-Konzept: Ziele, Messpunkte, Schwellen und Alarmwege

13. Oktober 2026

Eine Monitoring-Software ist schnell installiert. Ob sie hilft, entscheidet sich an anderer Stelle: Was soll überwacht werden, ab wann ist ein Wert ein Problem, und wer reagiert um drei Uhr nachts? Diese Festlegungen gehören in ein IT-Monitoring-Konzept. Dieser Beitrag zeigt, wie ein solches Dokument aufgebaut ist und wie Sie die vier Kernfragen beantworten: Ziele, Messpunkte, Schwellen und Alarmwege.

Welche Systeme grundsätzlich überwacht werden sollten, beschreibt unser Beitrag zum IT-Infrastruktur-Monitoring. Wie Sie das passende Werkzeug auswählen, steht im Beitrag zur IT-Monitoring-Software. Hier geht es um das Dokument, das beides verbindet.

Warum ein schriftliches Konzept?

Das BSI empfiehlt im IT-Grundschutz, Server in ein Systemüberwachungs- oder Monitoringkonzept einzubinden. Systemzustand und Dienste sollen laufend überwacht und Fehlerzustände sowie die Überschreitung definierter Grenzwerte an das Betriebspersonal gemeldet werden (BSI IT-Grundschutz-Kompendium, Baustein SYS.1.1 Allgemeiner Server, Anforderung A23). Für Netze nennt das BSI als Inhalte eines Netzmanagement-Konzepts unter anderem den Umfang des Monitorings und der Alarmierung je Netzkomponente sowie Meldeketten bei Störungen und Sicherheitsvorfällen (Baustein NET.1.2 Netzmanagement, Anforderung A13).

Ein schriftliches Konzept hat außerdem einen praktischen Nutzen: Es macht Entscheidungen nachvollziehbar. Wer später fragt, warum ein Alarm um Mitternacht niemanden geweckt hat, findet die Antwort im Dokument und nicht im Gedächtnis einzelner Personen.

Aufbau des Dokuments

Abschnitt Inhalt Beispiel
Ziele und Geltungsbereich Welche Dienste sind wichtig, zu welchen Zeiten? E-Mail, Warenwirtschaft und Internetzugang an Werktagen von 7 bis 18 Uhr
Messpunkte Was wird an welchem System gemessen? Erreichbarkeit der Warenwirtschaft, freier Speicher auf dem Datenbankserver
Schwellen Ab wann ist ein Wert eine Warnung, ab wann kritisch? Warnung bei 80 Prozent Belegung, kritisch bei 90 Prozent
Alarmwege Wer wird wie benachrichtigt, und wann wird eskaliert? Ticket im Servicedesk, bei „kritisch“ zusätzlich Anruf an die Bereitschaft
Pflege Wer prüft das Konzept, wie oft, und nach welchen Ereignissen? halbjährliche Durchsicht und nach jeder größeren Störung

Die Zahlen in der Tabelle sind Beispiele. Die passenden Werte ergeben sich aus Ihrer Umgebung.

1. Ziele und Geltungsbereich

Beginnen Sie mit den Diensten, nicht mit den Geräten. Fragen Sie: Welche Anwendungen und Abläufe brauchen die Beschäftigten, und wie lange darf ein Ausfall dauern, bevor es teuer wird? Daraus ergibt sich eine Rangfolge. Halten Sie außerdem fest, zu welchen Zeiten überwacht und reagiert wird. Ein Betrieb mit Schichtarbeit braucht andere Festlegungen als ein Büro mit festen Öffnungszeiten.

Grenzen Sie den Geltungsbereich klar ab. Ein Konzept für den Betrieb beantwortet die Frage, ob Systeme laufen. Die Erkennung von Angriffen ist eine eigene Aufgabe mit anderen Daten und anderen Abläufen. Sie ist Thema unseres Beitrags zum IT-Security-Monitoring.

2. Messpunkte festlegen

Für jeden wichtigen Dienst legen Sie fest, woran Sie erkennen, dass er funktioniert. Zwei Blickwinkel ergänzen sich:

  • Sicht der Nutzer: Ist der Dienst erreichbar, und antwortet er in angemessener Zeit? Beispiel: Die Anmeldeseite der Warenwirtschaft lädt.
  • Sicht der Technik: Wie geht es den Systemen dahinter? Beispiel: Prozessorlast, Arbeitsspeicher, freier Plattenplatz, Zustand der Datensicherung.

Eine Orientierung bietet Googles Buch zum Site Reliability Engineering. Darin werden vier „goldene Signale“ genannt: Latenz (wie lange eine Anfrage dauert), Datenverkehr (wie viel angefragt wird), Fehler (wie viele Anfragen scheitern) und Sättigung (wie nah ein System an seiner Kapazitätsgrenze ist). Für Netzkomponenten nennt das BSI als Mindestinhalte für Alarmierung und Protokollierung den Ausfall oder die Nichterreichbarkeit von Komponenten, Hardware-Fehlfunktionen, fehlerhafte Anmeldeversuche sowie kritische Zustände oder Überlastung (NET.1.2, Anforderung A26).

Halten Sie im Konzept je Messpunkt fest: System, Messwert, Messintervall und wer für den Messpunkt zuständig ist.

3. Schwellen bestimmen

Eine Schwelle legt fest, ab welchem Wert das Monitoring meldet. Das BSI empfiehlt, die Schwellwerte für zentrale Netzkomponenten vorab zu ermitteln, indem man das normale Verhalten misst. Dieses Vorgehen heißt Baselining (NET.1.2, Anforderung A25). Praktisch heißt das: Messen Sie einige Wochen, bevor Sie Schwellen festlegen.

Man unterscheidet statische und dynamische Schwellen. Statische Schwellen sind feste Werte, etwa „Datenträger zu 90 Prozent belegt“. Dynamische Schwellen leiten den Normalbereich aus dem bisherigen Verlauf ab. Ein Beispiel ist Azure Monitor: Dynamische Schwellenwerte lernen dort aus Verlaufsdaten und erkennen stündliche, tägliche oder wöchentliche Muster. Sie lösen erst aus, wenn mindestens drei Tage und 30 Messwerte vorliegen, und wöchentliche Muster erkennen sie erst nach drei Wochen. Langsam wachsende Probleme lösen dabei laut Microsoft wahrscheinlich keine Warnung aus (Microsoft Learn: Dynamische Schwellenwerte). Für schleichende Entwicklungen wie volllaufende Datenträger bleiben feste Schwellen daher sinnvoll.

Arbeiten Sie mit zwei Stufen: „Warnung“ für Werte, die Aufmerksamkeit brauchen, und „kritisch“ für Werte, die sofortiges Handeln erfordern. Legen Sie zusätzlich fest, wie lange ein Wert überschritten sein muss, bevor gemeldet wird. Kurze Spitzen erzeugen sonst Meldungen, auf die niemand reagieren muss.

4. Alarmwege beschreiben

Ein Alarm, den niemand liest, ist wertlos. Das Konzept beantwortet deshalb für jede Stufe:

  • Wer wird benachrichtigt: interne IT, Dienstleister, Bereitschaft?
  • Wie: E-Mail, Ticket, SMS, Anruf?
  • Wann wird eskaliert, wenn niemand reagiert, und an wen?
  • Was außerhalb der Geschäftszeiten passiert: Wird gemeldet, und wer ist erreichbar? Welche Formen von Betreuung außerhalb der Geschäftszeiten es gibt, erklärt unser Beitrag IT-Support 24/7.

Das BSI empfiehlt für Netzkomponenten, Alarmmeldungen sofort zu übermitteln, wenn sie auftreten (NET.1.2, Anforderung A26). Googles Buch zum Site Reliability Engineering formuliert einen hilfreichen Grundsatz: Jede Benachrichtigung, die jemanden aktiv alarmiert, sollte eine Handlung erfordern. Meldungen, die nur zur Information dienen, gehören in einen Bericht, nicht aufs Telefon der Bereitschaft.

Halten Sie auch fest, was nach dem Alarm geschieht. Für wiederkehrende Meldungen lohnt sich eine kurze Handlungsanweisung: Was wird geprüft, was darf die Bereitschaft selbst tun, wann wird der Hersteller eingeschaltet? Bei Sicherheitsvorfällen greift zusätzlich Ihr Incident-Response-Plan. Wie Warnungen von Endgeräten bewertet und beantwortet werden, beschreibt unser Beitrag Managed Endpoint Security.

5. Das Konzept pflegen

Ein Monitoring-Konzept braucht Pflege. Neue Systeme kommen hinzu, alte fallen weg, Schwellen erweisen sich als zu streng oder zu großzügig. Planen Sie feste Durchsichten ein und prüfen Sie das Konzept nach jeder größeren Störung: Hat das Monitoring das Problem gemeldet? Kam die Meldung bei der richtigen Person an? Für das Netzmanagement empfiehlt das BSI einen regelmäßigen, nachvollziehbaren Soll-Ist-Vergleich (NET.1.2, Anforderung A17). Dieser Gedanke lässt sich auf das gesamte Monitoring übertragen.

Regeln Sie auch geplante Wartungen. Wer ein System für ein Update neu startet, sollte die Meldungen dafür vorher unterdrücken. Sonst entstehen Meldungen, auf die niemand reagieren muss, und echte Alarme gehen leichter unter.

Unterstützung durch GSL

Die GSL Groß GmbH betreut Unternehmen in Rheinland-Pfalz und Hessen von Idar-Oberstein aus; im Raum Darmstadt arbeiten wir mit einem Partnersystemhaus zusammen. Wenn Sie den laufenden Betrieb Ihrer IT abgeben möchten, finden Sie unser Angebot auf der Seite zu Managed Services zum monatlichen Festpreis. Für die Erkennung von Angriffen gibt es unsere Seite zu Managed Detection and Response (MDR). Wie wir den Stand Ihrer IT-Sicherheit prüfen, lesen Sie auf der Seite zur IT-Sicherheit.

Sie möchten ein Monitoring-Konzept für Ihr Unternehmen aufsetzen oder Ihr bestehendes prüfen? Sprechen Sie uns an. Wir besprechen Ihre Ausgangslage und die nächsten Schritte.