Skip to content
NeuralSkills
Bereitstellung

Log-Aggregation-Architekt

Zentralisierte Logging-Systeme entwerfen, die das Finden der Nadel im Log-Heuhaufen tatsaechlich ermoelichen.

Experte Kostenlos Veroeffentlicht: 15. April 2026
Kompatible Tools claude-codechatgptgeminicopilotcursorwindsurfuniversal

Das Problem

Ihre Logs sind ueber 15 Server verstreut, jeder mit unterschiedlichen Formaten, unterschiedlichen Aufbewahrungsfristen und ohne Moeglichkeit Events serviceuebergreifend zu korrelieren. Bei einem Incident verbinden Sie sich per SSH einzeln auf Maschinen, durchsuchen Gigabytes unstrukturierten Texts und versuchen zusammenzusetzen, was passiert ist. Ein Request, der 5 Services beruehrt, erzeugt 5 separate Log-Eintraege ohne gemeinsame Kennung.

Der Prompt

Du bist ein Logging- und Observability-Architekt. Entwirf ein zentralisiertes Logging-System fuer meine Infrastruktur.

INFRASTRUKTUR:
- Services: [z.B. 3 Node.js APIs, 1 Python Worker, 2 Go Microservices]
- Deployment: [z.B. Kubernetes, Docker Compose, EC2, Serverless]
- Aktuelles Log-Volumen: [z.B. ~10 GB/Tag, unbekannt]
- Aktueller Ansatz: [z.B. console.log nach stdout, Dateien auf Disk, CloudWatch]
- Budget: [z.B. selbst gehostet, Managed Service bis X EUR/Monat]

Entwirf die Logging-Architektur:
1. **Log-Format-Standard**: Definiere ein strukturiertes Log-Format (JSON) mit Pflichtfeldern — Timestamp, Level, Service, TraceId, Message, Context.
2. **Collection-Pipeline**: Wie Logs von Anwendung → Collector → Storage fliessen.
3. **Speicher und Aufbewahrung**: Wo Logs gespeichert werden, wie lange, gestufte Speicherstrategie.
4. **Korrelation**: Wie ein einzelner Request ueber mehrere Services mit Correlation-IDs verfolgt wird.
5. **Suche und Abfrage**: Wie effektiv gesucht wird — Indizes, Filter, gespeicherte Abfragen fuer gaengige Untersuchungen.
6. **Log-basierte Alerts**: Musterbasierte Alerts — Error-Spitzen, spezifische Fehlermeldungen, Sicherheitsereignisse erkennen.
7. **Tool-Empfehlung**: ELK vs. Loki+Grafana vs. CloudWatch vs. Datadog fuer meine Groesse und mein Budget.

Beispielausgabe

Log-Format (alle Services):
{"timestamp":"2026-04-15T10:30:00Z","level":"error","service":"user-api","traceId":"abc-123","message":"Datenbank-Verbindungs-Timeout","context":{"query":"SELECT * FROM users","duration_ms":5000,"pool_size":10,"active_connections":10}}

Pipeline: App (stdout JSON) → Fluentd DaemonSet → Loki → Grafana
Aufbewahrung: 30 Tage Hot (Loki), 90 Tage Cold (S3), Loeschung nach 1 Jahr
Korrelation: X-Request-ID Header durch alle Services propagiert, als traceId geloggt
Alert: Loki Alert-Regel wenn count_over_time({level="error"}[5m]) > 50

Wann einsetzen

Verwenden Sie diesen Skill wenn Sie mehr als 2 Services verwalten, Debugging SSH auf Server erfordert, oder nach einem Incident bei dem Sie die relevanten Logs nicht finden konnten. Unverzichtbar vor der Skalierung auf Microservices, wo Distributed Tracing zur Notwendigkeit wird.

Profi-Tipps

  • Strukturierte JSON-Logs von Tag eins — strukturiertes Logging nachtraeglich in eine bestehende Anwendung einzubauen ist muehsam. Starten Sie jeden neuen Service mit JSON-strukturierten Logs.
  • Immer eine Trace/Correlation-ID mitfuehren — generieren Sie eine UUID am Edge (API-Gateway, erster Service) und propagieren Sie diese durch jeden nachgelagerten Aufruf. Ohne sie ist verteiltes Debugging unmoeglich.
  • Auf dem richtigen Level loggen — DEBUG nur fuer Entwicklung, INFO fuer normalen Betrieb, WARN fuer behebbare Probleme, ERROR fuer Fehler die Aufmerksamkeit erfordern. Ueber-Logging auf INFO-Level ist teuer.
  • Aufbewahrungsrichtlinien vorab festlegen — Logs wachsen schnell. Ohne Richtlinien werden Ihre Speicherkosten Sie ueberraschen. 30 Tage fuer Sofortsuche, 90 Tage komprimiert, nach einem Jahr loeschen ist ein vernuenftiger Standard.