Seminar Flask Fehlerbehandlung, Monitoring und Observability

Stabile Anwendungen zeichnen sich nicht dadurch aus, dass keine Fehler auftreten, sondern dadurch, dass Fehler sauber begrenzt, sichtbar und diagnostizierbar bleiben. Dafür müssen Fehlerklassen, Logs, Metriken, Traces und Alarmwege aufeinander abgestimmt sein.

Das Seminar entwickelt aus konkreten Betriebsfragen eine durchgängige Beobachtbarkeit. Fehler werden in stabile Außenantworten übersetzt, intern korreliert und bis zu Datenbank, Queue oder Partnerdienst verfolgt.

Inhaltsübersicht

1. Fehlertaxonomie und zentrale Handler
2. Hooks, Fehlerbehandlung und Request-Abschluss
3. Strukturiertes Logging und Korrelationskennungen
4. Metriken, Tracing und Anwendungsdiagnose
5. Verteilte Nachvollziehbarkeit und Betrieb
6. Alarmierung und Störungsbearbeitung
7. Sicherheitstests und Härtungsprüfung
8. Praxisprojekt und Wissenssicherung

Lernziele

• Fachliche und technische Fehler in stabile Antwortmodelle überführen.
• Strukturierte Logs ohne Preisgabe sensibler Daten erzeugen.
• Aussagekräftige Metriken und Trace-Kontexte integrieren.
• Dashboards aus konkreten Diagnosefragen ableiten.
• Nutzerwirksame Alarme und nachvollziehbare Runbooks entwickeln.

Zielgruppe

Flask-Entwickler, SRE-, DevOps- und Betriebsteams sowie technische Verantwortliche für Verfügbarkeit und Diagnose.

Voraussetzungen

Gute Flask-Grundkenntnisse und ein grundlegendes Verständnis von Produktionsbetrieb, Logs und HTTP.

Seminarinhalte

1. Fehlertaxonomie und zentrale Handler

Fehler werden nach Ursache, Verantwortlichkeit und gewünschter Außenwirkung kategorisiert.

1. Schritt 1: Fachliche, Validierungs-, Infrastruktur- und Programmierfehler unterscheiden.
2. Schritt 2: Domänenfehler in HTTP- beziehungsweise CLI-Antworten übersetzen.
3. Schritt 3: Interne Details nur protokollieren und nach außen stabile Meldungen liefern.
4. Schritt 4: Fehlerhandler für Browser, API und Hintergrundprozess konsistent testen.

2. Hooks, Fehlerbehandlung und Request-Abschluss

Querschnittsaufgaben werden an definierten Stellen des Anfragezyklus ausgeführt und zuverlässig aufgeräumt.

1. Schritt 1: before_request, after_request und teardown-Funktionen nach ihrem Ausführungszeitpunkt auswählen.
2. Schritt 2: Fachliche, technische und HTTP-Fehler in getrennte Klassen und Handler überführen.
3. Schritt 3: Fehlerseiten beziehungsweise JSON-Fehler ohne Preisgabe interner Details erzeugen.
4. Schritt 4: Aufräumlogik auch bei abgebrochenen Requests und ausgelösten Ausnahmen testen.

3. Strukturiertes Logging und Korrelationskennungen

Protokolle werden so gestaltet, dass technische Abläufe und einzelne Requests zuverlässig nachvollziehbar bleiben.

1. Schritt 1: Logger-Hierarchie, Level und Handler zentral konfigurieren.
2. Schritt 2: Request-, Benutzer- und Korrelationskennung als strukturierte Felder ergänzen.
3. Schritt 3: Sensible Daten, Tokens und vollständige Request-Körper konsequent filtern.
4. Schritt 4: Logausgabe für Entwicklung und zentrale Sammlung getrennt testen.

4. Metriken, Tracing und Anwendungsdiagnose

Latenz, Durchsatz, Fehler und Abhängigkeiten werden messbar gemacht, ohne unnötige Kardinalität zu erzeugen.

1. Schritt 1: Golden Signals und fachliche Kennzahlen für die Anwendung festlegen.
2. Schritt 2: Metriken an Request-Grenzen und kritischen Services erfassen.
3. Schritt 3: Trace-Kontext über HTTP-, Datenbank- und Queue-Grenzen weitergeben.
4. Schritt 4: Dashboards anhand realer Betriebsfragen statt dekorativer Diagramme strukturieren.

5. Verteilte Nachvollziehbarkeit und Betrieb

Logs, Metriken und Traces werden über Prozess- und Dienstgrenzen hinweg korreliert.

1. Schritt 1: Korrelations- und Trace-Kontext bei eingehenden und ausgehenden Aufrufen übernehmen.
2. Schritt 2: Dienstname, Version und Deploymentkennung als Telemetrieattribute ergänzen.
3. Schritt 3: Service-Level-Indikatoren pro Vertrag und Nutzerpfad definieren.
4. Schritt 4: Fehlerkette in einer simulierten Störung vom Gateway bis zur Datenbank nachvollziehen.

6. Alarmierung und Störungsbearbeitung

Alarme werden aus Nutzerwirkung abgeleitet und mit klaren Diagnose- und Eskalationsschritten verbunden.

1. Schritt 1: Schwellwerte und SLO-Verletzungen statt einzelner Logzeilen als Signal definieren.
2. Schritt 2: Warnung, dringenden Alarm und Informationsereignis voneinander trennen.
3. Schritt 3: Runbooks mit Prüfpfad, Verantwortlichkeit und sicheren Sofortmaßnahmen erstellen.
4. Schritt 4: Störung simulieren, Alarmweg prüfen und Erkenntnisse in Tests sowie Monitoring zurückführen.

7. Sicherheitstests und Härtungsprüfung

Die wichtigsten Schutzannahmen werden als wiederholbare Tests und Betriebschecks festgehalten.

1. Schritt 1: Negativtests für Authentifizierung, Autorisierung, CSRF und Eingabegrenzen erstellen.
2. Schritt 2: Sicherheitsheader, Cookie-Attribute und Fehlerausgaben automatisiert prüfen.
3. Schritt 3: Abhängigkeits- und statische Analyse in die CI integrieren.
4. Schritt 4: Härtungscheckliste vor Veröffentlichung und nach Infrastrukturänderungen ausführen.

Praxisprojekt

Eine Anwendung erhält eine Fehlertaxonomie, korrelierte Logs, Metriken und Trace-Weitergabe. Anschließend wird ein Ausfall eines abhängigen Dienstes simuliert und über Alarm, Dashboard und Runbook diagnostiziert.

Methodik

Kurze fachliche Einordnungen wechseln mit Demonstrationen, geführten Umsetzungen, Fehleranalysen und eigenständigen Übungen. Jede größere Änderung wird durch einen Test, eine Diagnose oder eine betriebliche Prüfroutine abgesichert. Die Arbeitsstände werden schrittweise zu einem durchgängigen Beispielprojekt zusammengeführt.