aiMOOC

Server Cloud und zuverlässiger IT-Betrieb – Monitoring mit sinnvollen Alarmen aufbauen

QR-Code

Einleitung

Server Cloud und zuverlässiger IT-Betrieb – Monitoring mit sinnvollen Alarmen aufbauen

Zielgruppe: Fachinformatik-Ausbildung. Dauer: 75–100 Minuten. Ziel: Du misst Systemzustände, testest Schwellen und vermeidest Fehlalarme – in einem vollständig lokalen Labor mit fiktiven Daten.

Datei:Server-monitoring.svg

Sicherheit: Ausschließlich lokale, ausdrücklich autorisierte Übungsumgebungen verwenden. Keine fremden Netze, Produktionsanlagen, Zugangsdaten oder Kundendaten untersuchen oder übertragen.

Lerneinheit 1: Ausbildungsfall KursShop

Datei:Server Rack (54126210834).jpg

Du arbeitest im fiktiven Betrieb CloudWerk. Die erfundene Anwendung KursShop läuft auf einem virtuellen Server. Um 09:10 Uhr erreicht die CPU 91 %, aber der Dienst arbeitet normal. Um 09:30 Uhr steigt die Fehlerquote auf 7 % und das 95. Perzentil der Antwortzeit auf 820 ms: Der Dienst ist beeinträchtigt. Auftrag: Entwickle einen Alarm, der diese Störung meldet, ohne jede CPU-Spitze zu eskalieren.

Lerneinheit 2: Geeignete Messwerte

Das Service-Monitoring betrachtet Metriken, Logs und Traces. Die vier Golden Signals des Site Reliability Engineering heißen Latenz, Traffic, Errors und Saturation. CPU-Auslastung ist ein Ressourcensignal; Fehlerrate und Antwortzeiten zeigen Nutzerprobleme direkter. Die Metriktypen Gauge, Counter und Histogramm erfüllen unterschiedliche Aufgaben. Fachquelle: Google SRE und OpenTelemetry Metrics.

Datei:Grafana screenshot (2018).png

Signal	Beispiel	Bedeutung
Latenz	p95 = 900 ms	Antwortzeiten
Traffic	100 Anfragen/Minute	Nachfrage
Errors	8 %	Fehlgeschlagene Anfragen
Saturation	CPU 88 %	Ressourcenauslastung

Lerneinheit 3: Daten visualisieren

Fiktive Messreihe mit Fünf-Minuten-Abständen: Die Grenzwerte 80 % CPU und 5 % Fehler sind nur Beispiele und keine allgemeinen Normwerte.

Uhrzeit	CPU %	Fehler %	p95 ms	Dienststörung
09:00	40	0	120	Nein
09:05	45	1	130	Nein
09:10	91	0	135	Nein
09:15	42	0	125	Nein
09:20	83	0	150	Nein
09:25	85	0	160	Nein
09:30	90	7	820	Ja
09:35	88	8	900	Ja
09:40	45	1	200	Nein
09:45	44	0	140	Nein
09:50	87	0	180	Nein
09:55	86	0	175	Nein

Eine statistische Kontrollgrenze ist nicht automatisch ein sinnvoller IT-Alarmgrenzwert. Basisaufgabe: Welche Zeitpunkte hätten bei sofortiger CPU-Alarmierung unnötige Meldungen erzeugt? Feedback: Die CPU-Regel erkennt auch Situationen ohne Dienstbeeinträchtigung.

Lerneinheit 4: Sinnvolle Alarmregeln

Regel A: CPU mindestens 80 %, sofort alarmieren. Regel B: CPU mindestens 80 %, zwei Messpunkte in Folge. Regel C: Fehlerquote mindestens 5 %, zwei Messpunkte in Folge. Entwarnung erst nach zwei guten Messpunkten. Ergebnis: A meldet um 09:10, 09:20 und 09:50, B um 09:25 und 09:55, C um 09:35. Nur bei C fällt der Alarmbeginn in die Dienststörung. Die Mindestdauer verzögert die Erkennung um fünf Minuten. Prometheus ermöglicht zeitliche Bedingungen mittels for und keep_firing_for. Dokumentation der Alarmregeln. Gruppierung, geeignete Empfänger und Runbooks machen Alarme handlungsfähig.

Datei:Prometheus software logo.svg

Grafana Labs: Einstieg in Alarmierung – prüfe die gezeigten Bestandteile Datenquelle, Regel und Benachrichtigung.

Lerneinheit 5: Isoliertes Python-Labor

Lokal ausführen: Kopiere den folgenden vollständigen Python-3-Code in monitoring_labor.py. Er benötigt ausschließlich die Python-Standardbibliothek und verbindet sich mit keinem Netzwerk.

from pathlib import Path
DATEN = [
 ("09:00",40,0,120,False), ("09:05",45,1,130,False),
 ("09:10",91,0,135,False), ("09:15",42,0,125,False),
 ("09:20",83,0,150,False), ("09:25",85,0,160,False),
 ("09:30",90,7,820,True), ("09:35",88,8,900,True),
 ("09:40",45,1,200,False), ("09:45",44,0,140,False),
 ("09:50",87,0,180,False), ("09:55",86,0,175,False)
]
def pruefe(metrik, schwelle, dauer, erholung):
    aktiv = False
    schlecht = gut = 0
    ergebnisse = []
    for zeit, cpu, fehler, p95, stoerung in DATEN:
        wert = cpu if metrik == "cpu" else fehler
        if wert >= schwelle:
            schlecht += 1
            gut = 0
        else:
            gut += 1
            schlecht = 0
        if not aktiv and schlecht >= dauer:
            aktiv = True
            ergebnisse.append((zeit, "ALARM", stoerung))
        elif aktiv and gut >= erholung:
            aktiv = False
            ergebnisse.append((zeit, "OK", stoerung))
    return ergebnisse

def zeichne():
    teile = ['<svg xmlns="http://www.w3.org/2000/svg" width="950" height="300">',
             '<rect width="950" height="300" fill="white"/>',
             '<text x="25" y="25" font-size="19">Fiktive CPU- und Fehlerwerte</text>']
    for i,(zeit,cpu,fehler,p95,stoerung) in enumerate(DATEN):
        x = 25+i*75
        teile.append(f'<rect x="{x}" y="{140-cpu}" width="22" height="{cpu}" fill="#2878ae"/>')
        teile.append(f'<rect x="{x+25}" y="{260-fehler*12}" width="22" height="{fehler*12}" fill="#bb3b3b"/>')
        teile.append(f'<text x="{x}" y="286" font-size="10">{zeit}</text>')
    teile.append('</svg>')
    Path('monitoring_fiktiv.svg').write_text('\n'.join(teile), encoding='utf-8')

if __name__ == '__main__':
    zeichne()
    print('Offline-Labor: Grafik monitoring_fiktiv.svg erstellt')
    profile = {"1":("cpu",80,1,1), "2":("cpu",80,2,2),
               "3":("fehler",5,2,2)}
    while True:
        try:
            wahl = input('1 CPU sofort, 2 CPU stabil, 3 Fehler stabil, 4 eigene Regel, 0 Ende: ')
            if wahl == '0':
                break
            if wahl == '4':
                metrik = input('cpu oder fehler: ').strip().lower()
                grenze = float(input('Schwelle in Prozent: '))
                dauer = int(input('Messpunkte bis Alarm (1-5): '))
                ruhe = int(input('Messpunkte bis Entwarnung (1-5): '))
                if metrik not in ('cpu','fehler') or not 0<=grenze<=100 or not 1<=dauer<=5 or not 1<=ruhe<=5:
                    raise ValueError('Unzulässige Eingabe')
                regel = (metrik, grenze, dauer, ruhe)
            else:
                regel = profile[wahl]
            ergebnisse = pruefe(*regel)
            for zeit, zustand, stoerung in ergebnisse:
                print(zeit, zustand, 'Störung' if stoerung else 'keine Störung')
            falsch = sum(1 for _,zustand,stoerung in ergebnisse if zustand=='ALARM' and not stoerung)
            print('Alarmierungen ohne Dienststörung:', falsch)
            print('Feedback: Alarmverzögerung und Fehlalarme gemeinsam beurteilen.')
        except (KeyError,ValueError):
            print('Ungültige Eingabe')
        except EOFError:
            break

Start: python3 monitoring_labor.py. Öffne danach lokal monitoring_fiktiv.svg.

Lokaler automatischer Test: Speichere diesen zweiten Code in test_monitoring.py und starte python3 test_monitoring.py.

from monitoring_labor import pruefe
assert [z for z,s,_ in pruefe('cpu',80,1,1) if s=='ALARM'] == ['09:10','09:20','09:50']
assert ('09:35','ALARM',True) in pruefe('fehler',5,2,2)
assert ('09:45','OK',False) in pruefe('fehler',5,2,2)
print('Alle drei Offline-Tests bestanden.')

Gestufte Hilfen: Hilfe 1: Welche Kennzahl betrifft Nutzer? Hilfe 2: Vergleiche 09:10 mit 09:30. Hilfe 3: Teste Fehlerquote ab 5 % mit zwei Messpunkten Mindestdauer. Begründetes Feedback: Weniger Fehlalarme sind wertvoll, aber längere Mindestdauern erhöhen den Erkennungsverzug.

Lerneinheit 6: Handeln und dokumentieren

Ein Runbook legt konkrete Schritte fest: Alarm prüfen, Antwortzeiten und Fehlerquote vergleichen, Ursache anhand fiktiver Daten eingrenzen, passende Zuständigkeit benennen, Ergebnis dokumentieren und nach stabiler Erholung entwarnen. Prometheus Alertmanager bündelt Meldungen; eine geplante Wartung kann eine befristete Stummschaltung rechtfertigen.

Grafana Labs: Gruppierung von Alarmmeldungen.

Grafana Labs: Alarme mit Visualisierungen verknüpfen.

Grafana Labs: Benachrichtigungen zielgerichtet weiterleiten.

Interaktive Aufgaben

Quiz: Teste Dein Wissen

Was ist eine Metrik? (Ein messbarer Wert mit zeitlichem Bezug) (!Ein ausschließlich manueller Wartungsplan) (!Ein verschlüsseltes Passwort) (!Ein Verzeichnis der Mitarbeitenden)

Welche Signale gehören zum Golden-Signals-Modell? (Latenz Traffic Fehler und Sättigung) (!CPU Bildschirmgröße Tastatur und Drucker) (!Passwort Benutzername Monitor und Standort) (!Temperatur Lizenzdauer Uhrzeit und Dateiname)

Was belegt die CPU-Spitze um 09:10 Uhr? (Hohe Auslastung ohne Dienststörung) (!Einen vollständigen Dienstausfall) (!Eine Fehlerquote von acht Prozent) (!Eine zwingende Eskalation)

Wann alarmiert die stabile Fehlerquotenregel erstmals? (Um 09:35 Uhr) (!Um 09:00 Uhr) (!Um 09:10 Uhr) (!Um 09:50 Uhr)

Was bedeutet p95 bei Antwortzeiten? (Etwa 95 Prozent der Werte liegen höchstens dort) (!Genau 95 Anfragen schlagen fehl) (!Die CPU ist immer bei 95 Prozent) (!Der Dienst war 95 Minuten offline)

Was reduziert kurze Messspitzen als Auslöser? (Eine geeignete Mindestdauer) (!Ein grundsätzlich niedriger Grenzwert) (!Eine Meldung pro Messung) (!Das Abschalten aller Messungen)

Was bewirkt die Prometheus-Option for? (Eine Alarmbedingung muss zeitlich anhalten) (!Alle Alarme werden gelöscht) (!Der Server startet automatisch neu) (!Metriken werden verschlüsselt)

Was reduziert häufige Wechsel zwischen Alarm und OK? (Eine stabile Entwarnungsbedingung) (!Benachrichtigungen im Sekundentakt) (!Zufällige Messwerte) (!Dauerhaft abgeschaltetes Monitoring)

Warum werden Alarme gruppiert? (Zusammengehörige Meldungen werden gebündelt) (!Alle Störungen werden ignoriert) (!Die CPU-Auslastung wird null) (!Die Festplatte wird erweitert)

Wie sind fehlende Messwerte sinnvoll zu behandeln? (Als gesonderten Zustand mit eigener Bewertung) (!Immer als fehlerfreier Zustand) (!Immer als Null Prozent CPU) (!Immer als bestätigte Entwarnung)

Memory

Gauge	Aktueller Messwert
Counter	Fortlaufender Ereigniszähler
Latenz	Antwortzeit
Fehlerrate	Anteil fehlgeschlagener Anfragen
Saturation	Ressourcensättigung
Runbook	Handlungsanleitung

Drag and Drop

Ordne die richtigen Begriffe zu.	Funktion
Schwellwert	Numerische Grenze
Mindestdauer	Stabilisierung vor dem Alarm
Erholungsbedingung	Stabile Werte vor Entwarnung
Gruppierung	Zusammengehörige Meldungen bündeln
Runbook	Schritte zur Störungsbearbeitung

Kreuzworträtsel

Latenz	Wie heißt die Antwortzeit einer Anwendung?
Fehlerquote	Wie heißt der Anteil fehlgeschlagener Anfragen?
Histogramm	Wie heißt die grafische Häufigkeitsverteilung?
Prometheus	Welches Open-Source-System wertet Alarmregeln aus?
Dashboard	Wie heißt eine grafische Kennzahlenübersicht?
Schwellwert	Wie heißt die numerische Bewertungsgrenze?

LearningApps

Lückentext

Eine quantitative zeitbezogene Messgröße heißt

.

Die aktuelle CPU-Auslastung gehört zum Typ

.

Ein fortlaufender Zähler heißt

.

Die Antwortzeit nennt man

.

Der Anteil fehlgeschlagener Anfragen ist die

.

Eine numerische Grenze heißt

.

Eine zeitliche Alarmbedingung unterdrückt kurze

.

Eine unberechtigte Meldung ist ein

.

Häufiges Umschalten nennt sich

.

Eine grafische Übersicht ist ein

.

Eine Handlungsanleitung bei Störungen heißt

.

Messdaten unterstützen die

.

Offene Aufgaben

Leicht

Monitoring: Skizziere einen virtuellen Server und drei Metriken.
Metrik: Zeichne die fiktiven CPU-Werte als Balkendiagramm.
Fehlerquote: Erkläre den Unterschied zwischen 09:10 und 09:30.
Alarmierung: Entwirf eine Warn- und eine Alarmmeldung mit Reaktion.

Standard

Python: Starte das lokale Labor und dokumentiere die Alarmzeitpunkte.
Schwellwert: Verändere offline die CPU-Schwelle und vergleiche die Ergebnisse.
Datenvisualisierung: Gestalte das lokale SVG-Diagramm mit einer Legende.
Runbook: Formuliere eine einseitige Reaktionsanleitung zum fiktiven KursShop.

Schwer

Site Reliability Engineering: Entwirf ein Alarmkonzept für einen fiktiven Dienst mit zwei Komponenten.
Fehlalarm: Ergänze eine fiktive Messspitze und untersuche den Zielkonflikt zwischen Fehlalarm und Verzögerung.
Observability: Erstelle ein Erklärvideo mit selbst erzeugten Metriken, Logs und Traces.
IT-Service-Management: Simuliere und bewerte ein Störungsgespräch mit Rollen und Zuständigkeiten.

Gestuftes Feedback

Basis: Du unterscheidest Messwert und Nutzerwirkung. Anwendung: Du kannst die drei Alarmvarianten reproduzieren und begründen. Transfer: Du entwirfst einen Alarm mit Zuständigkeit, Reaktion und ausgewiesenen Grenzen. Wichtig: Eine längere Mindestdauer verhindert manche Fehlmeldungen, verschiebt aber den Alarmzeitpunkt.

Lernkontrolle

Fehleranalyse: Entscheide begründet, ob 95 % CPU bei normalem Dienstbetrieb eine sofortige Eskalation benötigen.
Alarmdesign: Vergleiche eine sofortige Regel mit einer Mindestdauer anhand einer kurzen Messspitze.
Servicequalität: Entwickle zwei Hypothesen für langsame Antworten bei niedriger CPU-Last.
Monitoring-Strategie: Konzipiere Nutzer- und Infrastrukturmetriken für eine fiktive Anwendung mit Datenbank.
Fehlalarmvermeidung: Entwirf eine Entwarnungsstrategie gegen Flapping und erkläre deren Nachteile.
Störungsmanagement: Bewerte eine zeitlich begrenzte Wartungsstummschaltung.