Journalisation et métriques avec Amazon CloudWatch

Déployer des applications sur AWS

Dunieski Otano

Amazon Web Services Solutions Architect

En panne ?

Un client dit que l'appli est en panne
Vous n'avez aucune donnée pour confirmer ou infirmer
CloudWatch transforme les suppositions en réponses

Un tableau de bord de supervision avec un point d'interrogation, incertitude sur l'état du service (opérationnel ou en panne)

Journalisation vs supervision vs observabilité

Schéma en trois colonnes distinguant la journalisation comme enregistrements d'événements immuables, la supervision comme seuils de métriques avec alarmes, et l'observabilité comme corrélation de données pour répondre à de nouvelles questions

Journalisation : enregistrer les événements discrets au fil de l'eau
Supervision : suivre des métriques connues vs des seuils
Observabilité : poser de nouvelles questions à vos données
Les trois sont nécessaires pour opérer sereinement

Groupes de logs, flux de logs et rétention

Groupe de logs : conteneur nommé pour des logs liés
Flux de logs : séquence d'une source
Rétention : durée de conservation des logs
Les logs coûtent ; fixez la rétention avec intention

Hiérarchie CloudWatch Logs : groupe de logs contenant plusieurs flux, chaque flux affichant une suite d'événements horodatés, avec paramètre de rétention et rappel de coût

Métriques et métriques personnalisées

Métriques : données numériques temporelles
AWS publie automatiquement de nombreuses métriques
Métriques personnalisées : nombres émis par votre appli
Les dimensions segmentent une métrique par attribut

Métriques CloudWatch : métriques de services AWS auto-publiées à gauche, métrique personnalisée avec dimensions à droite, et courbe temporelle avec ligne de seuil d'alarme

Le format de métrique intégrée

Une seule ligne de log structurée contient vos valeurs de métriques plus un bloc _aws qui indique à CloudWatch quels champs sont des métriques :

{
  "_aws": {
    "CloudWatchMetrics": [
      {
        "Namespace": "OrdersApp",
        "Dimensions": [["customerTier"]],
        "Metrics": [{ "Name": "OrderLatencyMs", "Unit": "Milliseconds" }]
      }
    ]
  },
  "customerTier": "premium",
  "OrderLatencyMs": 142
}

Tableaux de bord et alarmes

Panneau de widgets de tableau de bord CloudWatch à gauche et automate d'état d'alarme à droite avec états OK, ALARM et INSUFFICIENT_DATA, routage SNS vers e-mail et automatisation

Tableau de bord : un écran de graphiques et widgets
Alarme : se déclenche quand une métrique passe un seuil
Les alarmes vont vers SNS, puis e-mail, SMS ou automatisation
Déclenchez sur les symptômes ressentis par les utilisateurs, pas sur chaque métrique

Une stratégie de logs structurés

Consignez en JSON, pas en texte libre
Inclure timestamp, level, request ID, user ID
Des champs structurés sont filtrables et requêtables
La cohérence entre services permet la corrélation

Ligne de log JSON structurée avec timestamp, level, requestId et userId, et requête Logs Insights montrant comment des champs nommés permettent un filtrage et des agrégations précis

Passons à la pratique !

Déployer des applications sur AWS