← Zurück zu Desktop-Anwendungsstarter · Projektplanungspaket
Entdecke, wie der Skill hilft
Monitoring und handlungsfähige Alarme
Verbindet Diensttelemetrie mit Nutzerfolgen für Diagnose und handlungsfähige Alarme mit klarer Verantwortung.
monitoring-logging-alerting
Agenten mit diesem Skill
Wann ist der Skill hilfreich?
Nutze ihn bei unverbundenen Logs oder häufigen Alarmen ohne erkennbare Maßnahme.
Wobei hilft er dir?
- Verknüpft Latenz, Verkehr, Fehler und Sättigung mit Dienstverhalten.
- Verbindet strukturierte Logs über Korrelationskennungen ohne Geheimnisse.
- Alarmiert bei Nutzerfolgen mit Verantwortlichen, Anleitungen und sinnvollen Schwellen.
Das könntest du fragen
Ersetze laute CPU-Alarme durch einen handlungsfähigen Warteschlangenstillstands-Alarm. Pausiere einen Worker im kontrollierten Test und beobachte steigendes Auftragsalter. Alarmiere Verantwortliche mit Queue-Kennung, Nutzerwirkung und Wiederherstellungsanleitung.
Ausführliche Dokumentation
Hier findest du die ursprüngliche Anleitung, Beispiele und Prüfschritte des Skills in ihrer Originalsprache.
Weniger anzeigen
Monitoring, Logging & Alerting
Observability exists to answer two questions quickly during normal operations and incidents: Are users experiencing a problem right now? and Where in the system is the bottleneck or failure?
The Four Golden Signals & USE/RED Metrics
Measure both user-facing service health (RED) and underlying resource health (USE):
| Signal | What to Measure | Why Averages Lie |
|---|---|---|
| Latency | Request & job duration histograms (p50, p95, p99), separated for successful (2xx) vs. failed (5xx) requests |
A fast 500 error (2ms) drags down average latency and hides 30s timeouts on 200 responses! |
| Traffic / Rate | Requests/sec, jobs enqueued/sec, active connections | Establishes baseline load and distinguishes traffic spikes from zero-traffic outages. |
| Errors | HTTP 5xx rate, unhandled exceptions, failed background jobs, dead-letter queue growth, synthetic check failures |
Direct indicator of broken user flows. |
| Saturation | DB connection pool utilization, queue depth / consumer lag, CPU throttling, memory working set vs. limit, disk Space/IOPS | Predicts impending failure before hard errors begin (often degrades steeply above 80–85% utilization). |
Structured, Correlated & Redacted Logging
- Single-line JSON structured logs in production:
- Include standard fields on every log entry:
timestamp(ISO-8601 UTC),level,service,version(git_sha),env,request_id/trace_id,job_id,duration_ms, anderror.code/error.stack.
- Include standard fields on every log entry:
- Propagate correlation IDs across boundaries:
- Accept or generate an incoming
x-request-id/ W3Ctraceparentheader at the edge, attach it to all logs, pass it to outbound HTTP calls and enqueued background jobs, and echo it in error responses so users and engineers can locate the exact trace.
- Accept or generate an incoming
- Never log secrets or high-cardinality PII:
- Redact
Authorizationheaders, cookies, session tokens, API keys, passwords, and raw payment/personal data at the logger serializer layer.
- Redact
Actionable Alerting Discipline
Every page/notification must require human action and point to a clear next step:
- Page on user-visible symptoms (SLO burn rate, high error rate, queue stall, disk near full) rather than noisy transient CPU spikes that self-heal.
- Mandatory alert metadata: Every alert rule must define:
- Impact: What user or system capability is degraded?
- Owner / Routing: Which role or channel is responsible?
- Runbook / First Triage Steps: Exact dashboard link, log query, and safe mitigation options (e.g., rollback, scale worker, drain node).
- Never silence a recurring alert permanently without fixing the underlying cause or recalibrating the threshold with measured evidence.
Enthaltene Dateien 1
SKILL.md