Fähigkeiten observability-engineer
📊

observability-engineer

Sicher

Produktions-Observability-Systeme entwerfen

Dieses Skill hilft Ihnen dabei, umfassende Monitoring-, Logging- und Tracing-Systeme für Unternehmensanwendungen zu entwerfen und zu implementieren. Es bietet Expertenleitung zu SLI/SLO-Management, Distributed Tracing und Incident-Response-Workflows.

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-engineer". Entwerfen Sie eine Monitoring-Strategie für unseren Checkout-Service, der täglich 100K Bestellungen abwickelt

Erwartetes Ergebnis:

  • Metriksammlung: Deployen Sie Prometheus mit Recording-Rules für Order-Durchsatz, Latenz-Perzentile (p50, p95, p99) und Fehlerraten nach Typ
  • Key Dashboards: Erstellen Sie Executive-Overview, operative Echtzeit- und Troubleshooting-Drill-Down-Ansichten in Grafana
  • Alerting: Konfigurieren Sie Alerts für p99-Latenz > 2s, Fehlerrate > 1% und Checkout-Erfolgsrate < 99%
  • Tracing: Implementieren Sie OpenTelemetry-Auto-Instrumentierung mit Trace-Sampling bei 10% und vollem Tracing für Fehler
  • Logging: Strukturierte JSON-Logs mit Order-ID, User-ID und Latenz für Korrelation mit Traces

Verwendung von "observability-engineer". Definieren Sie SLOs für unsere Zahlungs-API mit 99,9% Verfügbarkeitsziel

Erwartetes Ergebnis:

  • SLI-Definition: Erfolgreiche Zahlungsanfragen / Gesamtzahl Zahlungsanfragen, gemessen über 5-Minuten-Fenster
  • SLO: 99,9% Erfolgsrate über 30-Tage-Rolling-Fenster = 43,8 Minuten erlaubtes Error Budget
  • Error-Budget-Alerts: Burn-Rate-Alert bei 2x (87,6 Min/Tag) und 10x (438 Min/Tag) Schwellenwerten
  • Verbrauchs-Tracking: Dashboard mit verbleibendem Error Budget, täglicher Burn-Rate und projiziertem Breach-Datum

Sicherheitsaudit

Sicher
v1 • 2/24/2026

Prompt-only skill with no executable code. Static analysis scanned 0 files (0 lines) and detected 0 security issues. The skill provides observability engineering guidance through text prompts only. No dangerous patterns, no network requests, no file system access, and no external commands detected. Content describes legitimate monitoring, logging, and tracing system design.

0
Gescannte Dateien
0
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

Microservices-Monitoring-Architektur entwerfen

Erstellen Sie eine umfassende Monitoring-Strategie für ein Microservices-System mit 50+ Services, einschließlich Metriksammlung, Distributed Tracing und Alerting.

SLI/SLO-Framework etablieren

Definieren Sie Service-Level-Indikatoren, -Ziele und Error Budgets für API-Services mit 99,9% Verfügbarkeitszielen und Burn-Rate-Monitoring.

Distributed Tracing implementieren

Richten Sie Distributed Tracing für eine E-Commerce-Plattform ein, um Latenz-Engpässe zu identifizieren und Root-Cause-Analysen über Service-Grenzen hinweg durchzuführen.

Probiere diese Prompts

Basic Monitoring Design 
Entwerfen Sie eine Monitoring-Strategie für einen [Service-Typ], der [Traffic-Volumen] Anfragen pro Tag verarbeitet. Include Metriksammlung, Logging-Ansatz und Alerting-Empfehlungen.
SLI/SLO-Definition 
Helfen Sie mir, SLIs und SLOs für unsere [Service-Name] API mit [Verfügbarkeitsziel]% Verfügbarkeit zu definieren. Include Error-Budget-Berechnung und Burn-Rate-Alerts.
Incident-Response-Setup 
Erstellen Sie einen Incident-Response-Workflow für [Incident-Typ] einschließlich Alert-Routing, Eskalationsverfahren, Runbook-Empfehlungen und Post-Incident-Analyseprozess.
Cost Optimization 
Analysieren Sie unser aktuelles Observability-Setup und empfehlen Sie Kostensenkungsstrategien. Wir verwenden derzeit [Tools] und generieren [Volumen] Telemetriedaten täglich.

Bewährte Verfahren

  • Beginnen Sie mit Business-Outcomes - definieren Sie, was zuverlässiger Service für Benutzer bedeutet, bevor Sie Metriken wählen
  • Implementieren Sie progressive Instrumentierung: zuerst Metriken für Sichtbarkeit, dann Traces für Debugging, dann Logs für Details
  • Alerten Sie auf Symptome, nicht Ursachen - benachrichtigen Sie, wenn Benutzer betroffen sind, nicht wenn interne Komponenten ausfallen

Vermeiden

  • Alerts für jeden möglichen Fehler erstellen - führt zu Alert-Fatigue und ignorierten Benachrichtigungen
  • Alles ohne Zweck überwachen - erhöht Kosten und reduziert Signalqualität
  • SLOs zu eng festlegen - verursacht unnötigen Stress und Budget-Burnout

Häufig gestellte Fragen

Welche Tools unterstützt dieses Skill?
Das Skill deckt wichtige Observability-Tools ab, einschließlich Prometheus, Grafana, Jaeger, Zipkin, ELK Stack, Loki, DataDog, New Relic, CloudWatch, OpenTelemetry, PagerDuty und Cloud-Native-Monitoring über AWS, Azure und GCP.
Kann dieses Skill Monitoring-Infrastruktur bereitstellen?
Nein. Dieses Skill bietet Design-Anleitung, Konfigurationsempfehlungen und Implementierungspläne. Die tatsächliche Bereitstellung erfordert separate Infrastruktur-Tools wie Terraform oder Kubernetes.
Wie fange ich mit Observability an?
Beginnen Sie mit der Identifizierung Ihrer kritischen User Journeys und der Definition dessen, was zuverlässiger Service bedeutet. Instrumentieren Sie dann für die Golden Signals: Latenz, Traffic, Errors und Saturation. Fügen Sie Traces und Logs inkrementell hinzu.
Was ist der Unterschied zwischen Monitoring und Observability?
Monitoring sagt Ihnen, wann etwas falsch ist. Observability hilft Ihnen zu verstehen, warum. Verwenden Sie Metriken und Dashboards für Monitoring, Traces für Debugging und Logs für tiefe Untersuchungen.
Wie reduziere ich Alert-Rauschen?
Verwenden Sie Alert-Gruppierung, Deduplizierung und Unterdrückungsregeln. Alerten Sie auf benutzerbeeinträchtigende Symptome plutôt als interne Komponentenausfälle. Implementieren Sie Runbooks für jeden Alert, um schnelles Triage zu ermöglichen.
Was sind SLIs, SLOs und Error Budgets?
SLIs messen Ihr Service-Verhalten (z. B. Anfrageerfolgsrate). SLOs sind Ihre Ziel-SLI-Werte (z. B. 99,9% Erfolg). Error Budgets sind die verbleibende erlaubte Ausfallzeit. Zusammen ermöglichen sie datengesteuerte Zuverlässigkeitsentscheidungen.

Entwicklerdetails

Autor

sickn33

Lizenz

MIT

Repository

https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/observability-engineer

Ref

main

Dateistruktur

📄 SKILL.md