Monitoring- und Alerting-Einrichtung

Das Problem

Sie erfahren, dass Ihre App ausgefallen ist, wenn ein Kunde eine E-Mail schreibt — oder schlimmer, darueber twittert. Ohne Monitoring sind Sie blind fuer Leistungsverschlechterungen, schleichende Memory-Leaks, Datenbankverbindungs-Erschoepfung und Error-Rate-Spitzen, die vollstaendigen Ausfaellen vorausgehen. Wenn Nutzer es bemerken, ist der Schaden bereits angerichtet. Sie brauchen ein System, das Sie Minuten vor Nutzer-Auswirkungen alarmiert, nicht Stunden danach.

Der Prompt

Du bist ein Monitoring- und Observability-Architekt. Entwirf eine Monitoring-Strategie fuer meine Anwendung.

ANWENDUNGSDETAILS:
- Stack: [z.B. Node.js/Express, Python/FastAPI, Go/Gin]
- Infrastruktur: [z.B. AWS ECS, Kubernetes, Vercel, Bare Metal]
- Datenbank: [z.B. PostgreSQL, MongoDB, Redis]
- Aktuelles Monitoring: [z.B. keines, einfacher Uptime-Check, Datadog, Prometheus]
- Teamgroesse: [z.B. allein, 3-5, 10+]
- Budget: [z.B. nur Free-Tier, 50 EUR/Monat, Enterprise]

Entwirf ein Monitoring-System das abdeckt:
1. **Die vier goldenen Signale**: Wie Latenz, Traffic, Fehler und Saettigung fuer meinen spezifischen Stack gemessen werden.
2. **Dashboard-Design**: Welche Panels auf dem primaeren Dashboard angezeigt werden, nach Prioritaet geordnet.
3. **Alert-Regeln**: Definiere Alerts mit spezifischen Schwellenwerten, Schweregrad-Stufen und Eskalationspfaden.
4. **Alert-Hygiene**: Wie Alert-Muedigkeit verhindert wird — welche Alerts pagen vs. Tickets erstellen vs. informativ sind.
5. **Tool-Auswahl**: Empfehle spezifische Tools fuer mein Budget und meine Teamgroesse.
6. **SLI/SLO-Definition**: Definiere Service Level Indicators und Objectives fuer meine kritischsten Endpunkte.
7. **Einrichtungsanleitung**: Schritt-fuer-Schritt-Implementierung fuer meinen empfohlenen Tool-Stack.

Beispielausgabe

Goldene Signale (Node.js/Express + PostgreSQL):
- Latenz: p50, p95, p99 der Antwortzeit pro Endpunkt (Ziel: p99 < 500ms)
- Traffic: Requests/Sekunde nach Endpunkt und Statuscode
- Fehler: 5xx-Rate als Prozentsatz der Gesamtanfragen (Ziel: < 0,1%)
- Saettigung: CPU %, Memory %, DB-Connection-Pool-Auslastung %, Event-Loop-Lag

Alert-Regeln:
- KRITISCH (Page): Error-Rate > 1% fuer 5 Min, p99-Latenz > 2s fuer 5 Min
- WARNUNG (Ticket): Error-Rate > 0,5% fuer 15 Min, Memory > 85% fuer 10 Min
- INFO (Dashboard): Deploy abgeschlossen, Dependency-Update verfuegbar

Wann einsetzen

Verwenden Sie diesen Skill beim Launch eines neuen Services in Produktion, nach einem Ausfall ohne Sichtbarkeit, oder wenn Alert-Muedigkeit Ihr Team dazu gebracht hat Benachrichtigungen zu ignorieren. Ueberarbeiten Sie quartalmaessig um Schwellenwerte basierend auf realen Traffic-Mustern anzupassen.

Profi-Tipps

• Alarmieren Sie auf Symptome, nicht Ursachen — alarmieren Sie bei Error-Rate-Spitzen (Symptom), nicht bei CPU ueber 80% (Ursache). Hohe CPU-Auslastung die Nutzer nicht beeintraechtigt, rechtfertigt keinen naechtlichen Alarm.
• Jeder Alert braucht ein Runbook — wenn jemand um 3 Uhr nachts geweckt wird, braucht er einen Link zu einem Dokument, das genau beschreibt was zu pruefen und wie zu beheben ist.
• Nutzen Sie Error-Budgets statt Null-Toleranz — ein SLO von 99,9% bedeutet 43 Minuten akzeptable Ausfallzeit pro Monat. Das verhindert Ueberalarmierung bei kurzen, sich selbst behebenden Aussetzern.
• Dashboard-Hierarchie zaehlt — das Top-Level-Dashboard sollte “ist alles in Ordnung?” in 3 Sekunden beantworten. Drill-Down-Dashboards beantworten “was genau ist kaputt?”