Diagnostiquez une alarme CloudWatch en corrélant logs, métriques et déploiements récents
Quand l'utiliser : Une alarme vient de se déclencher et vous voulez aller de 'quel service, quel déploiement, quelle ligne de log' sans basculer à travers la console.
Prérequis
- Credentials AWS avec CloudWatch + CloudFormation en lecture —
aws sso loginavec un rôle ayant la politique gérée ReadOnlyAccess - Serveur aws-cloudwatch-mcp en cours d'exécution —
uvx awslabs.cloudwatch-mcp-server— ou installez le bundle
Déroulement
-
Tirez les détails de l'alarme et les ressources affectéesDécrivez l'alarme CloudWatch 'prod-api-5xx-high'. Quelle ressource surveille-t-elle, quel seuil, quel est l'état actuel ?✓ Copié→ Config d'alarme plus historique d'état (quand elle a basculé)
-
Interrogez les logs autour de la violationExécutez une requête Logs Insights sur le groupe de logs /aws/ecs/prod-api de 10 minutes avant le déclenchement de l'alarme jusqu'à maintenant. Trouvez les lignes de log au niveau ERROR regroupées par modèle de message.✓ Copié→ Modèles d'erreur principaux avec comptages
-
Corrélation avec déploiements récentsListez les déploiements CodeDeploy vers le service prod-api au cours des 6 dernières heures. Un déploiement correspond-il à la pointe d'erreurs ?✓ Copié→ Chronologie de déploiement alignée sur le début des erreurs
Résultat : Une hypothèse concrète comme 'le déploiement abc123 à 14:22 UTC correspond à l'apparition 5xx à 14:23' avec les preuves à l'appui.
Pièges
- Les requêtes Logs Insights sur un grand groupe de logs sans fenêtre de temps coûtent de l'argent réel — Incluez toujours les limites
@timestampplus étroites que 1 heure ; le MCP ne vous empêchera pas de facturer $$$ - Les ressources inter-comptes nécessitent le bon profil de credentials — Définissez la variable d'environnement
AWS_PROFILEpar invocation de serveur ; ne supposez pas que le profil par défaut est celui que vous voulez