Fähigkeiten observability-monitoring-monitor-setup
📦

observability-monitoring-monitor-setup

Sicher

Umfassende Monitoring- und Observability-Einrichtung

Die Implementierung von Monitoring von Grund auf ist komplex und fehleranfällig. Diese Skill bietet bewährte Muster für Metriken, Tracing und Logging, die die MTTR reduzieren und volle Systemtransparenz bieten.

Unterstützt: Claude Codex Code(CC)
📊 71 Angemessen
1

Die Skill-ZIP herunterladen

2

In Claude hochladen

Gehe zu Einstellungen → Fähigkeiten → Skills → Skill hochladen

3

Einschalten und loslegen

Teste es

Verwendung von "observability-monitoring-monitor-setup". Set up Prometheus scraping for a Kubernetes cluster with automatic pod discovery

Erwartetes Ergebnis:

  • Prometheus-Konfiguration mit kubernetes_sd_configs für Auto-Discovery
  • Pod-Annotationen erforderlich für Scrape-Targeting
  • Relabel-Regeln zum Filtern und Taggen entdeckter Targets
  • Verifizierungsschritte zur Bestätigung des Scrapings

Verwendung von "observability-monitoring-monitor-setup". Create an alert for memory usage exceeding 90%

Erwartetes Ergebnis:

  • PromQL-Ausdruck mit container_memory_working_set_bytes
  • Alert-Regel mit geeigneten Schwellenwerten und Dauer
  • Runbook-Schritte zur Untersuchung von Speicherdruck
  • Grafana-Panel-Abfrage zur Visualisierung von Speichertrends

Sicherheitsaudit

Sicher
v1 • 2/24/2026

This skill contains documentation and code samples for monitoring setup. All static analysis findings are false positives - backticks are markdown code block delimiters, not shell execution. URLs are internal service endpoints. Environment variable usage follows standard configuration patterns. No malicious patterns detected.

2
Gescannte Dateien
557
Analysierte Zeilen
0
befunde
1
Gesamtzahl Audits
Keine Sicherheitsprobleme gefunden
Auditiert von: claude

Qualitätsbewertung

38
Architektur
100
Wartbarkeit
87
Inhalt
31
Community
100
Sicherheit
91
Spezifikationskonformität

Was du bauen kannst

Greenfield-Service-Monitoring

Richten Sie einen vollständigen Observability-Stack für einen neuen Microservice von Anfang an mit Metriken, Tracing und Logging ein.

Produktions-Incident-Response

Erstellen Sie umsetzbare Dashboards und Alerts, um die MTTR zu reduzieren und proaktive Problemerkennung zu ermöglichen.

SLO-Definition und -Tracking

Definieren Sie Service Level Objectives mit Fehlerbudgets und implementieren Sie Burn-Rate-Monitoring für Reliability Engineering.

Probiere diese Prompts

Grundlegende Metrics-Einrichtung
Helfen Sie mir, Prometheus-Metriken zu meiner Node.js-API hinzuzufügen. Ich benötige Request-Zählung, Fehlerrate und Latenz-Tracking. Zeigen Sie mir die prom-client-Einrichtung und wie ich einen /metrics-Endpoint bereitstelle.
Grafana-Dashboard-Erstellung
Erstellen Sie ein Grafana-Dashboard-JSON für meinen Payment-Service, das die vier Golden Signals zeigt. Beziehen Sie Panels für Request-Rate, Fehlerrate, p95/p99-Latenz und Sättigungsmetriken ein.
Alert-Konfiguration
Ich brauche Alert-Regeln für hohe Fehlerrate (>5% für 5 Minuten) und langsame Antwortzeit (p95 >1s für 10 Minuten). Konfigurieren Sie Alertmanager, um kritische Alerts an PagerDuty und Warnungen an Slack zu routen.
SLO-Implementierung
Definieren Sie SLOs für meine API mit einem Verfügbarkeitsziel von 99,9% über 30 Tage. Zeigen Sie mir, wie ich das Fehlerbudget berechne, Multi-Window-Burn-Rate-Alerts einstelle und Grafana-Panels für SLO-Tracking erstelle.

Bewährte Verfahren

  • Verwenden Sie Histogramm-Buckets, die an Ihre SLO-Ziele angeglichen sind, für genaue Perzentilberechnung
  • Fügen Sie konsistente Labels (Service, Umgebung, Version) zu allen Metriken für effektives Filtern hinzu
  • Testen Sie Alerts gegen historische Daten, um Fehlalarme zu minimieren, bevor Sie Benachrichtigungen aktivieren

Vermeiden

  • Alles ohne klare Zuständigkeit zu überwachen führt zu Alert-Fatigue und ignorierten Seiten
  • Die Verwendung von durchschnittlicher Latenz anstatt Perzentilen verbirgt Tail-Latenz-Probleme, die Benutzer betreffen
  • Dashboards einzurichten, bevor definiert wird, welche Fragen sie beantworten sollen, verschwendet Aufwand

Häufig gestellte Fragen

Wie wähle ich das richtige Scrape-Intervall für meine Metriken?
Beginnen Sie mit 15s für die meisten Services. Verwenden Sie 5s für latenzsensitive Systeme oder beim Debugging. Vermeiden Sie Intervalle unter 5s, da sie die Prometheus-Last erhöhen ohne proportionalen Nutzen.
Sollte ich jeden Request tracen oder stichproben?
Stichproben in Produktion. Verwenden Sie head-basiertes Sampling (z.B. 10% der Requests) für Services mit hohem Traffic. Trace 100% in Staging. Trace immer Fehler unabhängig von der Sampling-Rate.
Was ist der Unterschied zwischen RED und USE Monitoring?
RED (Rate, Errors, Duration) ist für benutzerorientierte Services. USE (Utilization, Saturation, Errors) ist für Infrastrukturressourcen. Verwenden Sie RED für Application-Monitoring, USE für Nodes und Datenbanken.
Wie setze ich aussagekräftige SLO-Ziele?
Setzen Sie Ziele basierend auf Benutzererwartungen und Geschäftsanforderungen, nicht auf aktueller Leistung. Beginnen Sie konservativ (99%) und verschärfen Sie, wenn sich die Zuverlässigkeit verbessert. Messen Sie über 28-30-Tage-Fenster.
Brauche ich von Anfang an alle drei Säulen (Metriken, Logs, Traces)?
Beginnen Sie mit Metriken - sie sind am günstigsten und beantworten 'was kaputt ist'. Fügen Sie Logging hinzu für 'warum es kaputt ging'. Fügen Sie Tracing für verteilte Systeme hinzu, wenn das Debuggen von Service-übergreifenden Problemen schwierig wird.
Wie lange sollte ich Monitoring-Daten aufbewahren?
Bewahren Sie hochauflösende Metriken (rohe Samples) für 15-30 Tage zum Debugging auf. Verwenden Sie Downsampling oder Recording-Regeln für langfristige Trends. Speichern Sie Logs basierend auf Compliance-Anforderungen, typischerweise mindestens 90 Tage.