AI für Error Tracking & Debugging in Production

MetinC — Sat, 14 Mar 2026 11:11:00 +0000

AI für Error Tracking & Debugging in Production: Sentry, Logging und Monitoring mit ChatGPT & Claude. 10 Prompts für Production Debugging.

Einleitung

Bugs in Production sind unvermeidlich. Zudem entscheidend ist, wie schnell du sie findest und fixst. AI hilft bei Error Tracking Setup, Log-Analyse und Root Cause Analyse. Hier sind 10 Prompts für Error Tracking und Debugging in Production.

Zusätzlich gibt es einige bewährte Tipps für den Alltag.

Grundsätzlich empfiehlt es sich, schrittweise vorzugehen.

Prompt 1: Sentry Setup

Ebenso wichtig ist es, die Best Practices zu kennen.

Richte Sentry Error Tracking ein:

Stack: [z.B. "Next.js Frontend + Node.js Backend"]
Hosting: [z.B. "Vercel + Railway"]

Implementiere:
1. **Frontend SDK**: @sentry/nextjs mit DSN
2. **Backend SDK**: @sentry/node mit Performance Tracing
3. **Source Maps**: Upload für lesbare Stack Traces
4. **User Context**: User-ID und E-Mail an Errors anhängen
5. **Custom Tags**: Environment, Version, Feature Flags
6. **Breadcrumbs**: User-Aktionen vor dem Error tracken
7. **Sampling**: Performance 10%, Errors 100%
8. **Ignored Errors**: Bekannte 3rd-Party Errors filtern
9. **Release Tracking**: Errors pro Release Version
10. **Integrations**: Slack Alert, GitHub Issue erstellen

Sentry Best Practices:
- Environment: production, staging, development
- Release: Git SHA als Version
- Sourcemaps nur an Sentry senden (nicht öffentlich!)
- Alert Rules: Neue Issues, Regression, Spike

Folglich erhältst du mit diesem Ansatz deutlich bessere Resultate.

Natürlich kannst du den Ansatz an deine Bedürfnisse anpassen.

Prompt 2: Structured Logging

Deshalb lohnt es sich, dieses Thema genauer zu betrachten.

Implementiere Structured Logging:

Stack: [z.B. "Node.js + Pino / Winston"]
Log-Ziel: [z.B. "Axiom / Datadog / Loki / CloudWatch"]

Implementiere:
1. **Logger Setup**: Pino mit JSON Output
2. **Log Levels**: error, warn, info, debug, trace
3. **Request ID**: Eindeutige ID pro Request (Correlation)
4. **Context**: User-ID, Endpoint, Duration an jeden Log hängen
5. **Sensitive Data**: Passwörter, Tokens aus Logs filtern
6. **Error Logging**: Stack Trace + Context formatiert
7. **HTTP Request Log**: Method, URL, Status, Duration
8. **Log Rotation**: Lokale Logs mit Rotation
9. **Log Aggregation**: Zu Axiom/Datadog/Loki senden
10. **Dashboards**: Queries für Error-Trends, Slow Requests

Structured Log Format:
```json
{
  "level": "error",
  "timestamp": "2025-03-15T14:30:05Z",
  "requestId": "abc-123",
  "userId": "user-456",
  "message": "Payment failed",
  "error": { "code": "CARD_DECLINED", "provider": "stripe" },
  "duration": 1234
}
```

Weiterhin ist es ratsam, die Ergebnisse immer kritisch zu prüfen.

Tatsächlich zeigt die Praxis, dass dieser Ansatz sehr effektiv ist.

Prompt 3: Root Cause Analyse

Insbesondere für den Einstieg sind die folgenden Informationen hilfreich.

Hilf mir die Root Cause für diesen Production Bug zu finden:

Error:
```
[ERROR MESSAGE / STACK TRACE HIER]
```

Kontext:
- Wann aufgetreten: [z.B. "Seit 14:30, nach Deploy"]
- Wie oft: [z.B. "50 Errors in 10 Minuten"]
- Betroffene User: [z.B. "Nur Chrome, nur mobile"]
- Letzte Änderungen: [z.B. "Auth-Refactoring deployed"]

Analysiere:
1. Stack Trace lesen: Wo genau tritt der Fehler auf?
2. Breadcrumbs: Was hat der User vorher gemacht?
3. Request Details: Welche Inputs führen zum Error?
4. Zeitliche Korrelation: Zusammenhang mit Deploy/Event?
5. Pattern erkennen: Gleicher User? Gleicher Browser? Gleicher Endpoint?
6. Dependencies: Ist ein externer Service down?
7. Datenbank: Daten-Problem? Constraint Violation?
8. Race Condition: Timing-abhängig?
9. Memory/CPU: Resource-Problem?
10. Fix-Vorschlag: Hotfix + langfristiger Fix

Somit sparst du Zeit und erhältst qualitativ hochwertigeren Output.

Außerdem profitierst du von einem systematischen Vorgehen.

Prompt 4: Source Maps

Natürlich gibt es dabei verschiedene Herangehensweisen.

Konfiguriere Source Maps für Production Debugging:

Stack: [z.B. "Next.js + Sentry"]
Bundler: [Webpack / Vite / esbuild]

Implementiere:
1. **Source Map Generierung**: Build mit Source Maps
2. **Upload zu Sentry**: sentry-cli sourcemaps upload
3. **NICHT öffentlich**: Source Maps nicht an Client ausliefern
4. **Release Matching**: Source Maps mit Release Version verknüpfen
5. **CI Integration**: Automatischer Upload in Build Pipeline
6. **Validierung**: Prüfen ob Maps korrekt zugeordnet werden
7. **Hidden Source Maps**: devtool: 'hidden-source-map'
8. **Debug IDs**: Sentry Debug IDs für zuverlässiges Matching
9. **Monorepo**: Source Maps für mehrere Packages
10. **Cleanup**: Alte Source Maps nach 90 Tagen löschen

Warum Source Maps wichtig:
- Minified Code: "a is not a function" → Unlesbar
- Mit Source Map: "handlePayment() in checkout.ts:42" → Sofort klar
- Stack Traces zeigen Original-Code, nicht Bundle

Folglich verbessert sich die gesamte Codequalität deutlich.

Prompt 5: Alerting & On-Call

Dennoch solltest du einige Besonderheiten beachten.

Richte Alerting für meine Production-App ein:

Tools: [Sentry / PagerDuty / Grafana / Uptime Kuma]
Kanäle: [Slack / E-Mail / SMS / PagerDuty]

Richte ein:
1. **Error Spike Alert**: > 10 Errors/Minute → Slack
2. **New Issue Alert**: Erstmaliger Fehler → Slack
3. **Regression Alert**: Gelöster Bug tritt erneut auf → SMS
4. **Uptime Monitoring**: HTTP Check alle 60s → PagerDuty bei Down
5. **Performance Alert**: P95 Response Time > 3s → Slack
6. **Certificate Expiry**: SSL Cert läuft in 14 Tagen ab
7. **Error Budget**: SLO 99.9% unterschritten → Alarm
8. **Cron Monitoring**: Geplanter Job nicht ausgeführt
9. **Custom Metric**: Business Metric Anomalie (0 Bestellungen?)
10. **Escalation**: Slack → 15 Min keine Reaktion → SMS → PagerDuty

Alert Fatigue vermeiden:
- Nur actionable Alerts
- Deduplizieren (nicht 100x gleicher Alert)
- Severity Levels: Critical (Aktion nötig!), Warning, Info
- Quiet Hours für nicht-kritische Alerts

Außerdem kannst du den Prompt für verschiedene Programmiersprachen anpassen.

Weiterhin ist es sinnvoll, die Ergebnisse regelmäßig zu überprüfen.

Prompt 6: Bug reproduzieren

Tatsächlich ist dieser Bereich besonders wichtig für Entwickler.

Hilf mir diesen Production Bug zu reproduzieren:

Bug Report:
- Error: [z.B. "TypeError: Cannot read property 'email' of undefined"]
- URL: [z.B. "/dashboard/settings"]
- Browser: [z.B. "Chrome 120, macOS"]
- User: [z.B. "Tritt nur bei bestimmten Usern auf"]
- Frequenz: [z.B. "~5% der Settings-Aufrufe"]

Erstelle Reproduktions-Strategie:
1. **Sentry Breadcrumbs**: User-Journey nachvollziehen
2. **Request Replay**: Gleiche API Requests nachstellen
3. **User-Daten**: Welche Daten hat der betroffene User?
4. **Feature Flags**: Welche Flags sind für den User aktiv?
5. **A/B Test**: Ist der User in einem Experiment?
6. **Browser DevTools**: Gleiche Conditions herstellen
7. **Session Replay**: Sentry/LogRocket Session anschauen
8. **Local Reproduction**: Umgebung lokal nachbauen
9. **Edge Cases**: Leere Daten, Sonderzeichen, Timezone
10. **Flaky Test**: Automatisierten Test für den Bug schreiben

Wenn nicht reproduzierbar:
- Mehr Logging hinzufügen (Feature Flag)
- Sentry Session Replay aktivieren
- Canary Release mit Debug-Code

Vor allem die detaillierten Anweisungen sorgen für präzisere Ergebnisse.

Ebenfalls empfehlenswert ist eine regelmäßige Überprüfung der Ergebnisse.

Prompt 7: APM & Tracing

Folglich profitierst du von einem besseren Verständnis dieser Konzepte.

Implementiere Application Performance Monitoring:

Stack: [z.B. "Next.js + Node.js API"]
Tools: [Sentry Performance / Datadog APM / New Relic / Grafana Tempo]

Implementiere:
1. **Distributed Tracing**: Request über Frontend → Backend → DB verfolgen
2. **Transaction Tracking**: Jede Page Load / API Call messen
3. **Span Breakdown**: DB Query, External Call, Rendering einzeln
4. **Custom Spans**: Business-relevante Operationen messen
5. **Slow Transaction Alert**: P95 > Threshold
6. **Database Queries**: N+1 Detection, Slow Queries
7. **External Services**: API Call Duration zu Drittanbietern
8. **Web Vitals**: LCP, FID, CLS im echten User-Traffic
9. **Dashboards**: Service Map, Latenz-Heatmap
10. **Correlation**: Error → Trace → Logs verknüpfen

OpenTelemetry:
- Vendor-neutral Standard für Tracing
- @opentelemetry/sdk-node für Auto-Instrumentation
- Export zu Sentry, Datadog, Grafana Tempo, Jaeger

Dementsprechend ist eine manuelle Überprüfung empfehlenswert.

Dennoch sollte man die Limitierungen im Blick behalten.

Prompt 8: Post-Mortem schreiben

Allerdings gibt es einige wichtige Unterschiede zu beachten.

Hilf mir ein Post-Mortem / Incident Report zu schreiben:

Incident:
- Was: [z.B. "Payment Service 45 Minuten down"]
- Wann: [z.B. "2025-03-15 14:30 - 15:15 UTC"]
- Impact: [z.B. "~200 fehlgeschlagene Bestellungen, ~15.000€ Umsatzverlust"]
- Root Cause: [z.B. "DB Migration hat Index gelöscht"]

Erstelle Post-Mortem mit:
1. **Summary**: Was ist passiert? (1-2 Sätze)
2. **Timeline**: Minute-für-Minute was passiert ist
3. **Impact**: Betroffene User, Umsatzverlust, Dauer
4. **Root Cause**: Technische Ursache detailliert
5. **Detection**: Wie wurde das Problem bemerkt?
6. **Response**: Was wurde getan um es zu lösen?
7. **Resolution**: Was war der Fix?
8. **Lessons Learned**: Was haben wir gelernt?
9. **Action Items**: Konkrete Tasks (mit Owner und Deadline)
10. **Prevention**: Wie verhindern wir Wiederholung?

Tone: Blameless! Nicht "Person X hat Fehler gemacht" 
sondern "Unser Prozess hat nicht verhindert dass..."

Dabei ist der folgende Punkt besonders wichtig.

Prompt 9: Fehler verhindern

Ebenfalls relevant sind die praktischen Anwendungsbeispiele.

Hilf mir Production Errors proaktiv zu verhindern:

App: [z.B. "Next.js E-Commerce, 50k DAU"]
Häufigste Errors: [z.B. "TypeError, Unhandled Rejection, CORS, Timeout"]

Implementiere Prevention:
1. **Type Safety**: TypeScript strict mode, Zod Runtime Validation
2. **Error Boundaries**: React Error Boundaries pro Feature
3. **Null Checks**: Optional Chaining (?.), Nullish Coalescing (??)
4. **API Contracts**: OpenAPI / tRPC für typsichere APIs
5. **Feature Flags**: Schrittweise Rollouts, sofortiges Kill Switch
6. **Canary Deploys**: 5% Traffic auf neuen Code, Metriken prüfen
7. **Smoke Tests**: Automatische Tests nach Deploy
8. **Database Migrations**: Backward-compatible, staged Rollouts
9. **Dependency Updates**: Automatisiert, mit Test-Suite
10. **Chaos Engineering**: Absichtlich Fehler einbauen und testen

Prevention Pyramid:
- TypeScript → 60% der Bugs verhindert
- Unit/Integration Tests → 25% der Bugs
- E2E Tests → 10% der Bugs
- Monitoring → Schnelle Detection der restlichen 5%

Im Grunde funktioniert dieser Ansatz mit allen gängigen AI-Tools.

Insbesondere für fortgeschrittene Projekte ist das relevant.

Prompt 10: Runbooks & Playbooks

Zusammenfassend lässt sich sagen, dass dies ein zentraler Aspekt ist.

Erstelle Runbooks für häufige Production-Probleme:

Infrastruktur: [z.B. "Vercel + PlanetScale + Redis"]
Team: [z.B. "3 Entwickler, kein dediziertes Ops Team"]

Erstelle Runbooks für:
1. **App ist down**: Erste Schritte, Status Pages, Rollback
2. **Hohe Error Rate**: Sentry prüfen, Deploy Rollback
3. **Langsame Performance**: APM prüfen, DB Queries, External APIs
4. **Datenbank down**: Connection Issues, Failover, Recovery
5. **Speicher voll**: Disk Space, Logs, Caches clearen
6. **DDoS/Traffic Spike**: CDN, Rate Limiting, Scaling
7. **Security Incident**: Breach Response, Passwörter rotieren
8. **Deployment fehlgeschlagen**: Rollback-Procedure, Logs
9. **Certificate Expired**: SSL Renewal, DNS Check
10. **3rd Party Service down**: Fallback, Status Page, User Communication

Runbook Format:
- Symptom → Diagnose → Lösung → Eskalation
- Bullet Points (keine langen Texte!)
- Commands zum Copy-Paste
- Kontaktdaten und Zugänge

Deshalb empfiehlt es sich, den Prompt schrittweise zu verfeinern.

Zusammenfassend bietet dieser Abschnitt praktische Handlungsempfehlungen.

FAQ

Welches Error Tracking Tool soll ich nutzen?

Somit kannst du direkt mit der Umsetzung beginnen.

Sentry: Bestes DX, generous Free Tier (5K Events), Open Source möglich. Datadog: All-in-one (Logs + APM + Errors), teurer. Bugsnag: Einfacher als Sentry. Für die meisten: Sentry Free Tier reicht, und es integriert sich perfekt mit Next.js.

Wie viel Logging ist zu viel?

Dementsprechend solltest du die folgenden Aspekte kennen.

Log alles was du zum Debugging brauchst, aber nicht mehr. Grundsätzlich error + Warn: immer. Info: Business-relevante Events. Debug: nur in Development. Sensitive Daten NIE loggen. Kosten im Blick behalten – Log-Ingestion kann teuer werden.

Kann AI beim Production Debugging helfen?

Grundsätzlich gibt es dabei einige Punkte zu beachten.

Absolut: Stack Traces analysieren, Sentry Setup generieren, Logging-Code erstellen, Root Cause Analyse unterstützen, Post-Mortems strukturieren. Weiterhin paste Error + Code → AI erklärt die Ursache und schlägt einen Fix vor.

Darüber hinaus solltest du diesen Aspekt berücksichtigen.

Verwandte Artikel:

Im Grunde sparst du dadurch langfristig viel Zeit.

Zuletzt aktualisiert: März 2026

Der Beitrag AI für Error Tracking & Debugging in Production erschien zuerst auf MetinCelik.de.

Production Archive - MetinCelik.de