Log-Analysator

Das Problem

Anwendungsprotokolle wachsen schnell auf tausende Zeilen an. Durch rohe Log-Ausgaben zu scrollen und den einen relevanten Fehler zu suchen, verschwendet wertvolle Debugging-Zeit. Muster wie Kaskadenausfaelle, Memory Leaks und Rate-Limit-Treffer verstecken sich in hunderten Zeilen, die das menschliche Auge leicht uebersieht.

Der Prompt

Du bist ein erfahrener DevOps-Ingenieur mit Spezialisierung auf Log-Analyse. Analysiere folgende Protokolle:

LOGS:
[fuege deine Log-Ausgabe hier ein — mit Zeitstempeln, Levels und Nachrichten]

KONTEXT:
- Anwendung: [z.B. Node.js Express API, Django Backend, Kubernetes Pod]
- Gemeldetes Problem: [z.B. "API-Antworten langsam nach 2 Uhr", "intermittierende 502-Fehler"]

Liefere:
1. **Fehlerzusammenfassung**: Liste aller eindeutigen Fehler mit Anzahl und erstem/letztem Auftreten
2. **Zeitlinie**: Chronologische Abfolge der Ereignisse, die zum Problem fuehrten
3. **Muster**: Wiederkehrende Muster (periodische Ausfaelle, eskalierende Fehler, korrelierte Ereignisse)
4. **Ursachenanalyse**: Wahrscheinlichste Grundursache basierend auf den Belegen
5. **Anomalien**: Alles Ungewoehnliche, das nicht zum erwarteten Muster passt
6. **Empfohlene Loesung**: Konkrete Schritte zur Behebung des identifizierten Problems
7. **Monitoring-Vorschlag**: Welcher Alert oder welche Metrik haette dies frueher erkannt

Beispielausgabe

Fehlerzusammenfassung:
- ECONNREFUSED 127.0.0.1:6379 (Redis) — 47 Vorkommen, erstes um 02:14:03, letztes um 02:31:17
- TimeoutError: Response exceeded 30000ms — 12 Vorkommen, erstes um 02:15:01
- ENOMEM: JavaScript heap out of memory — 1 Vorkommen um 02:31:17

Zeitlinie:
02:14:03 — Redis-Verbindung bricht ab (wahrscheinlich Neustart oder OOM-Kill)
02:14:03-02:15:01 — Anwendung versucht Redis-Reconnect, faellt auf Datenbank zurueck
02:15:01 — Datenbank durch Cache-Miss-Traffic ueberlastet, Antworten laufen in Timeout
02:31:17 — Node.js-Prozess crasht mit OOM durch aufgestaute Retry-Buffer

Grundursache: Redis-Prozess wurde gekillt (wahrscheinlich durch OS OOM-Killer), was eine
Cache-Stampede ausloeste, die die Datenbank ueberflutete und schliesslich die App zum Absturz brachte.

Wann verwenden

Verwenden Sie diesen Skill beim Debugging von Produktionsvorfaellen, bei der Untersuchung von Performance-Verschlechterungen oder beim Ueberpruefen von Logs nach einem Deployment. Er funktioniert am besten mit einem zusammenhaengenden Log-Block rund um den Zeitpunkt des Vorfalls.

Profi-Tipps

• Fuegen Sie mindestens 5 Minuten vor dem Vorfall ein — die Grundursache erscheint in den Logs haeufig deutlich vor den sichtbaren Symptomen.
• Behalten Sie Zeitstempel und Log-Levels bei — das Entfernen von Metadaten erschwert die Mustererkennung fuer die KI erheblich.
• Anonymisieren Sie sensible Daten — ersetzen Sie API-Keys, Benutzer-E-Mails und Passwoerter durch Platzhalter wie [ZENSIERT], bevor Sie Logs in ein KI-Tool einfuegen.