observability-engineer
Concevoir des systèmes d'observabilité en production
Cette compétence vous aide à concevoir et mettre en œuvre des systèmes complets de surveillance, de journalisation et de traçage pour les applications d'entreprise. Elle fournit des conseils d'expert sur la gestion SLI/SLO, le traçage distribué et les workflows de réponse aux incidents.
Télécharger le ZIP du skill
Importer dans Claude
Allez dans Paramètres → Capacités → Skills → Importer un skill
Activez et commencez à utiliser
Tester
Utilisation de "observability-engineer". Concevoir une stratégie de surveillance pour notre service de paiement traitant 100K commandes quotidiennement
Résultat attendu:
- Collecte de métriques : Déployer Prometheus avec des règles d'enregistrement pour le débit de commandes, les percentiles de latence (p50, p95, p99) et les taux d'erreur par type
- Tableaux de bord clés : Créer des vues de synthèse exécutive, opérationnelles en temps réel et d'approfondissement de dépannage dans Grafana
- Alertes : Configurer des alertes pour latence p99 > 2s, taux d'erreur > 1% et taux de réussite des paiements < 99%
- Traçage : Implémenter l'auto-instrumentation OpenTelemetry avec échantillonnage de traces à 10% et traçage complet pour les erreurs
- Journalisation : Logs JSON structurés avec ID de commande, ID utilisateur et latence pour corrélation avec les traces
Utilisation de "observability-engineer". Définir les SLO pour notre API de paiement avec une cible de disponibilité de 99,9%
Résultat attendu:
- Définition SLI : Requêtes de paiement réussies / total des requêtes de paiement, mesuré sur des fenêtres de 5 minutes
- SLO : Taux de réussite de 99,9% sur une fenêtre glissante de 30 jours = 43,8 minutes de budget d'erreur autorisé
- Alertes de budget d'erreur : Alerte de taux de consommation aux seuils 2x (87,6 min/jour) et 10x (438 min/jour)
- Suivi de consommation : Tableau de bord montrant le budget d'erreur restant, le taux de consommation quotidien et la date de violation projetée
Audit de sécurité
SûrPrompt-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.
Score de qualité
Ce que vous pouvez construire
Concevoir une architecture de surveillance pour microservices
Créer une stratégie de surveillance complète pour un système de microservices avec 50+ services, incluant la collecte de métriques, le traçage distribué et les alertes.
Établir un cadre SLI/SLO
Définir les indicateurs de niveau de service, objectifs et budgets d'erreur pour des services API avec des cibles de disponibilité de 99,9% et une surveillance du taux de consommation.
Implémenter le traçage distribué
Configurer le traçage distribué pour une plateforme e-commerce afin d'identifier les goulots d'étranglement de latence et effectuer une analyse de cause racine au-delà des frontières de services.
Essayez ces prompts
Concevoir une stratégie de surveillance pour un [service type] qui gère [traffic volume] requêtes par jour. Inclure la collecte de métriques, l'approche de journalisation et des recommandations d'alertes.
Aidez-moi à définir les SLI et SLO pour notre API [service name] avec [availability target]% de disponibilité. Inclure le calcul du budget d'erreur et les alertes de taux de consommation.
Créer un workflow de réponse aux incidents pour [incident type] incluant le routage des alertes, les procédures d'escalade, les recommandations de runbook et le processus d'analyse post-incident.
Analysez notre configuration d'observabilité actuelle et recommandez des stratégies d'optimisation des coûts. Nous utilisons actuellement [tools] et générons [volume] de données de télémétrie quotidiennement.
Bonnes pratiques
- Commencez par les résultats métier - définissez ce qu'un service fiable signifie pour les utilisateurs avant de choisir les métriques
- Implémentez une instrumentation progressive : métriques d'abord pour la visibilité, puis traces pour le débogage, puis logs pour le détail
- Alertez sur les symptômes, pas les causes - notifiez quand les utilisateurs sont impactés, pas quand les composants internes échouent
Éviter
- Créer des alertes pour chaque échec possible - conduit à la fatigue d'alerte et aux notifications ignorées
- Surveiller tout sans objectif - augmente les coûts et réduit la qualité du signal
- Définir des SLO trop serrés - cause un stress inutile et l'épuisement du budget