Monitoring et Audit dans AWS - CloudWatch, X-Ray et CloudTrail
Photo de Gontran Isnard sur Unsplash

Un des aspects importants lorsqu’on déploie une application dans le Cloud, est le monitoring et la supervision afin d’une part, de s’assurer que tous les services applicatifs fonctionnent bien et d’autre part, de pouvoir réagir en cas de défaillance.

AWS propose plusieurs outils afin d’accomplir ces deux tâches :

  • AWS CloudWatch
    • Metrics : collecte les mĂ©triques intĂ©grĂ©s aux services AWS et ceux de votre application
    • Logs : collecte et stocke les fichiers journaux (logs)
    • Events : envoie de notification en rĂ©action Ă  certains Ă©vĂ©nements
    • Alarms : dĂ©finit des seuils d’activation (alarms) qui dĂ©clenche une action
  • AWS X-Ray
    • Aide Ă  l’analyse et au dĂ©bogage d’applications mĂŞmes celles distribuĂ©es
    • Produit sous forme graphique le parcours d’une requĂŞte et des composants qu’elle traverse avec les erreurs associĂ©es
  • AWS CloudTrail
    • Monitoring des appels aux APIs
    • Analyse de conformitĂ©
    • Audit opĂ©rationnel


AWS CloudWatch Metrics

Les métriques sont des données sur l’activité de vos systèmes. Par défaut, de nombreux services AWS fournissent des métriques.

  • Les mĂ©triques gratuits ont une pĂ©riodicitĂ© de 5 min, il est possible de la reduire en activant l’option Detailed Monitoring mais pour un coĂ»t supplĂ©mentaire
  • Les mĂ©triques sont horodatĂ©s
  • Les mĂ©triques sont regroupĂ©es d’abord par namespace, puis par les diffĂ©rentes combinaisons de dimensions (attributs de la ressource) au sein de chaque namespace. Par exemple, vous pouvez afficher toutes les mesures EC2, les mesures EC2 regroupĂ©es par instance ou les mesures EC2 regroupĂ©es par groupe de mise Ă  l’échelle automatique.
  • Seuls les services AWS que vous utilisez envoient des mĂ©triques Ă  Amazon CloudWatch.
  • Pour obtenir une liste des services AWS qui envoient des mesures Ă  CloudWatch, voir Services AWS qui publient des mesures CloudWatch. Ă€ partir de cette page, vous pouvez Ă©galement voir les mesures et les dimensions publiĂ©es par chacun de ces services.

Custom Metrics

Vous pouvez publier vos propres mesures (Custom Metrics) dans CloudWatch à l’aide de la commande put-metric-data du CLI AWS ou PutMetricData de l’API :

  • Leur pĂ©riodicitĂ© peut ĂŞtre Standard (1 min ou plus) ou High resolution (1, 5, 10 ou 30s)
  • Il est possible de dĂ©finir jusqu’à 10 dimensions

AWS CloudWatch Logs

Généralités

  • CloudWatch peut rĂ©colter les logs de la plupart des services AWS et des applications qui utilisent le SDK
  • Il existe un Log Group qui reprĂ©sente l’application et un Log Stream qui reprĂ©sente chaque service
  • Il existe une politique d’expiration (30, 90 jours, jamais,…)
  • Ces logs peuvent ĂŞtre exportĂ©s vers S3 (pour ĂŞtre sauvegardĂ©s) ou bien vers un Cluster Elastic Search pour analyse
  • Il faut des permissions IAM particulières pour autoriser CloudWatch Ă  rĂ©cupĂ©rer les logs et il est possible de les chiffrer Ă  l’aide de AWS KMS (au niveau du Log Group)

CloudWatch Log Agent

Pour les instances EC2 et les serveurs on-premise, il est nécessaire d’installer un Agent.

Il en existe deux versions :

  • CloudWatch Log Agent : Une ancienne version, ne peut gĂ©rer que les logs
  • CloudWatch Unified Agent : La dernière version, peut gĂ©rer les logs mais aussi la remontĂ©e de mĂ©triques dĂ©taillĂ©s telles que CPU, RAM, Disk, NetStat, Process, Swap,… du serveur et les SSM Parameter Store

CloudWatch Metric Filters et CloudWatch Alarms

  • CloudWatch Metric Filters peut filtrer les logs avec des expressions (IP, RegExp,…) afin de dĂ©clencher des Alarms
  • CloudWatch Alarm peut dĂ©clencher des notifications vers un ASG, un AWS SNS, une EC2 Action en fonction d’un mĂ©trique

CloudWatch Events et Amazon EventBridge

  • CloudWatch Events :
    • RĂ©agit Ă  partir de règles Ă  ce qu’un service fait (ArrĂŞt d’une instance,…)
    • CrĂ©e un Ă©vĂ©nement sous la forme d’un message JSON contenant ce qui l’a fait rĂ©agir
    • Peut s’interfacer Ă  un AWS SQS, SNS ou bien Kinesis
  • Amazon EventBridge :
    • Il prend en compte 3 Event Bus :
      • Default Event Bus pour les Services AWS
      • Partner Event Bus pour les Services SaaS et les partenaires d’AWS
      • Custom Event Bus pour votre application
    • Il fonctionne aussi Ă  partir de règles tout comme CloudWatch Event
    • EventBridge peut dĂ©duire la structure du message et le Schema Registry permet de gĂ©nĂ©rer le code applicatif nĂ©cessaire Ă  votre application

A noter

CloudWatch Events et Amazon EventBridge reposent sur les mêmes infrastructures AWS mais Amazon EventBridge est la version la plus récente et offre plus de fonctionnalités que CloudWatch Events.


AWS X-Ray

  • AWS X-Ray est un service qui collecte les donnĂ©es des requĂŞtes que servent vos applications. Il permet aussi de les afficher et les filtrer afin d’identifier des problèmes ou des possibilitĂ©s d’optimisation.
  • Pour toute requĂŞte tracĂ©e dans votre application, vous pouvez voir des informations dĂ©taillĂ©es non seulement sur la requĂŞte et la rĂ©ponse, mais aussi sur les appels que votre application effectue vers les ressources AWS en aval, les microservices, les bases de donnĂ©es et les API Web HTTP.

Fonctionnement

Architecture et composants du Service X-Ray
Architecture et composants du Service X-Ray
  • Chaque composant intervenant dans la requĂŞte envoie une trace Ă  l’API X-Ray :
    • Le code applicatif en y intĂ©grant le X-Ray SDK propre Ă  son langage (supportĂ© Java, Node.js, .NET,…) et du X-Ray Daemon installĂ© sur le serveur
    • Les scripts via l’AWS SDK ou l’AWS CLI au travers du X-Ray Daemon
    • Certains services AWS automatiquement si l’on active l’option sauf cas particulier pour les instances EC2 et On-Premise
  • Toutes les requĂŞtes peuvent ĂŞtre envoyĂ©es ou uniquement un Ă©chantillon
  • NĂ©cessite une autorisation IAM et est chiffrĂ© par AWS KMS

X-Ray SDK

L’intégration du X-Ray SDK nécessite d’apporter quelques modifications au code applicatif.

Exemple d’une application Java

  • Gestion des dĂ©pendances
<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>com.amazonaws</groupId>
      <artifactId>aws-xray-recorder-sdk-bom</artifactId>
      <version>2.9.0</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>
<dependencies>
  <dependency>
    <groupId>com.amazonaws</groupId>
    <artifactId>aws-xray-recorder-sdk-core</artifactId>
  </dependency>
  <dependency>
    <groupId>com.amazonaws</groupId>
    <artifactId>aws-xray-recorder-sdk-apache-http</artifactId>
  </dependency>
  <dependency>
    <groupId>com.amazonaws</groupId>
    <artifactId>aws-xray-recorder-sdk-aws-sdk</artifactId>
  </dependency>
  <dependency>
    <groupId>com.amazonaws</groupId>
    <artifactId>aws-xray-recorder-sdk-aws-sdk-instrumentor</artifactId>
  </dependency>
  <dependency>
    <groupId>com.amazonaws</groupId>
    <artifactId>aws-xray-recorder-sdk-sql-postgres</artifactId>
  </dependency>
  <dependency>
    <groupId>com.amazonaws</groupId>
    <artifactId>aws-xray-recorder-sdk-sql-mysql</artifactId>
  </dependency>
</dependencies>
  • Client DynamoDB
import com.amazonaws.xray.AWSXRay;
import com.amazonaws.xray.handlers.TracingHandler;

public class SessionModel {
  private AmazonDynamoDB client = AmazonDynamoDBClientBuilder.standard()
        .withRegion(Constants.REGION)
        .withRequestHandlers(new TracingHandler(AWSXRay.getGlobalRecorder()))
        .build();
  private DynamoDBMapper mapper = new DynamoDBMapper(client);

X-Ray Daemon

  • Le Daemon X-Ray est une application qui Ă©coute le trafic sur le port UDP 2000, recueille des donnĂ©es des Segments et les transmet Ă  l’API X-Ray
  • Il est dĂ©jĂ  intĂ©grĂ© Ă  de nombreux services AWS mais doit ĂŞtre installĂ© sur les instances EC2 ou les serveurs On-Premise

Instances EC2 d'un cluster ECS

Il existe 2 possibilités d’intégration du Daemon X-Ray :

  • DĂ©ployez un conteneur Daemon amazon/aws-xray-daemon sur chaque instance EC2
  • CrĂ©ez conteneur SideCar contenant une image du Daemon X-Ray et une image du code applicatif

AWS CloudTrail

AWS CloudTrail est un service AWS qui vous aide dans la gouvernance, la conformité et l’audit opérationnel et de sécurité de votre compte AWS :

  • Chaque action prise par un utilisateur, un rĂ´le ou un service AWS est enregistrĂ©e comme Ă©vĂ©nement dans CloudTrail.
  • Les Ă©vĂ©nements comprennent les actions prises dans la console de gestion de l’AWS, le CLI AWS et les SDK et API de l’AWS.

CloudTrail est activé par défaut sur votre compte AWS

CloudTrail Trail

  • Seuls les 90 derniers jours d’activitĂ© dans votre compte AWS sont enregistrĂ©s
  • CrĂ©ez un Trail dans CloudTrail pour archiver, analyser et rĂ©agir aux changements de vos ressources AWS :
    • Un Trail est une configuration qui permet d’envoyer l’activitĂ© enregistrĂ©e par CloudTrail sur un Bucket S3
    • Vous pouvez Ă©galement livrer et analyser des Ă©vĂ©nements dans CloudWatch Logs et CloudWatch Events
    • Un Trail est appliquĂ©, par dĂ©faut, sur toutes les rĂ©gions mais peut l’être sur une seule

CloudTrail Events

Un Event dans CloudTrail est l’enregistrement d’une activité. Il sont catégorisés en 3 types :

  • Management Events :
    • Fournit des informations sur les opĂ©rations de gestion effectuĂ©es sur un compte AWS
    • ConfigurĂ© par dĂ©faut
    • Exemples : OpĂ©rations IAM, enregistrement de devices tels qu’un VPC, crĂ©ation de Trail dans CloudTrail Logs,…
  • Data Events :
    • Fournit des informations sur les opĂ©rations effectuĂ©es sur ou dans une ressource
    • Pas actif par dĂ©faut car cela produit une très grande quantitĂ© d’Events
    • Exemples : Amazon S3 Get/Put/Delete, activitĂ© d’une AWS Lambda function, Amazon DynamoDB Get/Put/Delete,…
  • Insights Events :
    • Capture les activitĂ©s inhabituelles d’un compte AWS
    • DĂ©sactivĂ© par dĂ©faut
    • Exemples : toute utilisation qui diffère considĂ©rablement des habitudes d’utilisation typiques du compte

Intégration à EnventBridge

L’intégration de CloudTrail à EventBridge permet de lancer des actions automatisées en réponse à des événements sur les appels d’API (pour le moment au niveau d’une Region)

Jean-Jerome Levy

Ecrit par

Jean-JĂ©rĂ´me LĂ©vy

Consultant DevOps

Professionnel chevronné dans le domaine de l’informatique, cumulant plus de 20 années d’expérience au sein de DSI de grandes entreprises, mon expertise diversifiée m’a permis de jouer un rôle clé dans de nombreux projets, caractérisés par la mise en place de pratiques DevOps innovantes.