Apprenez à expliquer les requêtes échouées, à mesurer la santé d’une application, à observer les alarmes et à identifier les changements de ressources. Vous utiliserez CloudWatch Logs, les métriques CloudWatch et CloudTrail pour enquêter sur de petits incidents d’exploitation.
Cinq laboratoires guidés présentent les différents signaux avant un défi autonome de réparation d’alarme. Les éléments applicatifs fournis vous permettent de vous concentrer sur l’observation et le diagnostic.
Ce que vous apprendrez
- Trouver une requête échouée dans les journaux à partir de son identifiant
- Publier les nombres de requêtes et d’erreurs ainsi que la latence mesurée du gestionnaire
- Choisir des dimensions de métrique qui distinguent les applications
- Observer le déclenchement et le retour à la normale d’une alarme à partir des résultats de requêtes réelles
- Relier une action de gestion à son auteur, sa ressource et son heure
- Combiner les journaux et les métriques pour diagnostiquer un incident
- Réparer une alarme qui surveille la mauvaise application
À qui s’adresse ce cours
Ce cours s’adresse aux débutants en AWS, aux développeurs et aux futurs professionnels de l’exploitation qui souhaitent une introduction pratique à l’observation des applications et aux preuves d’audit.
Prérequis : Commencez par Get Started with AWS on LabEx dans AWS Foundations for Beginners. Le laboratoire d’audit demande les bases sur l’identité de l’appelant et Parameter Store. Chaque laboratoire précise ses prérequis sur les logs, métriques et alarmes.
Environnement d’apprentissage : Toutes les activités se déroulent dans un environnement Linux LabEx fourni, accessible dans le navigateur. Utilisez Terminal pour les commandes AWS CLI et AWS View, à côté de Terminal, pour examiner le même état des ressources et des applications. Les outils et la connexion sont prêts ; vous n’avez besoin ni d’un compte AWS personnel ni de clés d’accès. Chaque laboratoire commence indépendamment dans une nouvelle VM.
Questions fréquentes
Quelle est la différence entre journaux, métriques, alarmes et historique d’audit ?
Les journaux décrivent des événements ; les métriques résument des quantités mesurées au fil du temps ; les alarmes évaluent une métrique choisie selon une règle. L’historique de gestion consigne l’auteur, l’action, la ressource et l’heure d’une opération du plan de contrôle. Combinez ces signaux pour expliquer un incident.
Une alarme OK prouve-t-elle que l’application fonctionne correctement ?
Non. Le traitement des données manquantes peut produire l’état OK. Vérifiez les requêtes réelles et les dimensions de métrique visées. Sum convient aux comptages ; Average décrit la latence mesurée du gestionnaire, pas une latence par percentile. Les échecs précédents restent dans les totaux de la fenêtre : utilisez donc un nouvel identifiant de requête pour confirmer le rétablissement.
Les courtes périodes d’alarme sont-elles recommandées en production ?
Non. Les périodes haute résolution de 10 secondes permettent d’observer les transitions dans ces exercices. La rétention, la résolution, les périodes et le traitement des données manquantes influencent le comportement et le coût. Consultez les concepts CloudWatch et l’évaluation des alarmes.
Le nettoyage efface-t-il toutes les preuves historiques ?
Non. Supprimer une ressource n’efface pas son enregistrement d’audit, et il n’existe pas d’API permettant de supprimer individuellement les points de métrique existants. Arrêtez leur publication, supprimez précisément les ressources qui vous appartiennent, confirmez l’inventaire, puis retirez les identifiants.
Dois-je terminer tout le cours avant Lambda ?
Le premier laboratoire sur les journaux de requêtes fournit les bases de journalisation nécessaires à Lambda. La livraison SNS, le traçage X-Ray et une plateforme complète d’observabilité en production ne font pas partie de ce cours.
