Maîtrise d'AWS CloudWatch pour une Surveillance et une Optimisation Proactives des Performances

AWS CloudWatch est l'endroit où de nombreux incidents AWS commencent à prendre sens. Un flux de paiement lent, une fonction Lambda qui se limite soudainement, une base de données RDS qui manque de connexions, ou une file d'attente SQS qui ne cesse de croître : tout laisse des indices dans les métriques et les journaux. La difficulté n'est pas d'activer CloudWatch. La difficulté est de choisir les signaux qui vous aident à agir avant que les utilisateurs ne vous disent que quelque chose ne va pas.

Une bonne surveillance CloudWatch relie les symptômes de la plateforme au comportement de l'application. Le CPU, la mémoire et les E/S sont importants, mais les échecs de paiement, l'âge des files d'attente, la latence des paiements et le nombre de tâches réussies par minute le sont tout autant.

Composants Principaux d'AWS CloudWatch

CloudWatch fonctionne sur un système de collecte de données de séries temporelles, appelées Métriques, qui sont ensuite évaluées par rapport à des seuils à l'aide d'Alarmes. Ces données sont visualisées via des Tableaux de bord et complétées par des Journaux et des Événements.

1. Métriques : Le Fondement de la Surveillance

Les métriques sont des mesures numériques suivies dans le temps. Chaque service AWS publie automatiquement des métriques standard (par exemple, Utilisation CPU EC2, Nombre de requêtes S3). Cependant, une véritable surveillance des performances nécessite d'aller au-delà des valeurs par défaut.

Métriques Standard vs Personnalisées

• Métriques Standard : Collectées automatiquement par les services AWS. La résolution varie selon le service et la configuration ; de nombreux services courants publient des métriques à 1 minute, tandis que certaines configurations de base ou plus anciennes utilisent des périodes de 5 minutes.
• Métriques Personnalisées : Données que vous publiez vous-même, souvent utilisées pour mesurer des indicateurs de performance spécifiques à l'application.

Publication de Métriques Personnalisées à l'aide de l'AWS CLI :

Vous pouvez publier des métriques personnalisées à l'aide de la commande put-metric-data. Ceci est crucial pour surveiller les temps de réponse des applications, les profondeurs de files d'attente ou les statuts opérationnels critiques pour l'activité.

aws cloudwatch put-metric-data \
    --metric-name "CheckoutLatency" \
    --namespace "MyApp/ECommerce" \
    --value 150 \
    --unit "Milliseconds" \
    --region us-east-1

Granularité des Métriques

Les métriques personnalisées CloudWatch peuvent être à résolution standard ou haute résolution. Les métriques personnalisées haute résolution peuvent être stockées à une résolution de 1 seconde et déclencher des alarmes sur des périodes plus courtes, ce qui est utile pour les systèmes à évolution rapide. Utilisez cela de manière sélective, car un volume plus élevé et plus d'alarmes peuvent augmenter les coûts.

2. Alarmes : Déclencher des Actions Basées sur des Seuils

Les alarmes transitent entre trois états : OK, DONNÉES_INSUFFISANTES et ALARME. Une alarme déclenche une action lorsque le seuil spécifié est dépassé pendant un nombre défini de périodes.

Configuration d'Alarmes de Performance

Les alarmes de performance efficaces se concentrent sur les indicateurs avancés plutôt que sur les seuls échecs réactifs. Par exemple, surveiller l'utilisation CPU d'EC2 est bien, mais surveiller la métrique BurstBalance pour les instances de la famille T peut prédire une future limitation avant que l'utilisation n'atteigne 100 %.

Exemple : Configuration d'une Alarme pour une Latence Élevée

Si votre métrique personnalisée CheckoutLatency dépasse en moyenne 500 ms sur trois périodes consécutives d'une minute, déclenchez une alarme et notifiez un sujet SNS.

aws cloudwatch put-metric-alarm \
    --alarm-name "HighCheckoutLatencyAlarm" \
    --alarm-description "Alerte lorsque la latence P95 dépasse 500ms" \
    --metric-name "CheckoutLatency" \
    --namespace "MyApp/ECommerce" \
    --statistic Average \
    --period 60 \
    --threshold 500 \
    --evaluation-periods 3 \
    --datapoints-to-alarm 3 \
    --comparison-operator GreaterThanThreshold \
    --actions-enabled \
    --alarm-actions arn:aws:sns:us-east-1:123456789012:PerformanceAlertsTopic

Meilleure Pratique : Utilisation des Centiles (p99, p95) Lors de la surveillance de la latence, évitez de vous fier uniquement à la Moyenne. Un petit mais pénible groupe de requêtes lentes peut disparaître dans une moyenne d'apparence saine. Utilisez des statistiques comme P99 ou P95 lorsque la latence de queue importe.

3. Tableaux de Bord : Visualiser la Santé du Système

Les tableaux de bord regroupent les métriques pertinentes dans un seul écran. Les tableaux de bord efficaces sont adaptés à l'audience (par exemple, Opérations, Développement, Direction).

Construction d'un Tableau de Bord d'Optimisation des Performances

Un tableau de bord bien structuré pour l'optimisation des performances doit regrouper les métriques connexes.

• Panneau Santé du Système : Utilisation CPU, Réseau Entrée/Sortie, E/S Disque Lecture/Écriture (pour EC2/EBS).
• Panneau Performance de l'Application : Métriques de latence personnalisées (P99), Taux d'erreur (compteurs HTTP 5xx), Débit de requêtes.
• Panneau Coût/Efficacité : Nombre d'instances en cours d'exécution, Utilisation des instances réservées, Utilisation des volumes EBS (pour identifier le stockage sous-utilisé).

Les tableaux de bord CloudWatch prennent en charge des widgets complexes, y compris des annotations textuelles, des expressions mathématiques de métriques (par exemple, calcul de ratios d'efficacité), et même l'intégration des résultats de requêtes CloudWatch Logs Insights.

CloudWatch pour l'Optimisation Automatisée des Performances

Les données de surveillance n'ont de valeur que lorsqu'elles conduisent à une action. Les alarmes CloudWatch sont le mécanisme principal pour initier des workflows d'optimisation automatisés.

Intégration des Alarmes avec Auto Scaling

L'une des techniques d'optimisation les plus puissantes consiste à utiliser les alarmes CloudWatch pour piloter les groupes Auto Scaling (ASG) AWS. Cela garantit que la capacité correspond précisément à la demande, évitant le sur-dimensionnement (économies de coûts) et le sous-dimensionnement (dégradation des performances).

Exemple : Mise à l'Échelle Basée sur la Profondeur de la File d'Attente

Au lieu de se fier uniquement au CPU, dimensionnez en fonction de l'arriéré en attente de traitement. Pour une file d'attente SQS, vous créeriez une alarme sur la métrique ApproximateNumberOfMessagesVisible. Lorsque l'alarme passe à l'état ALARME, elle déclenche une action Auto Scaling pour ajouter une instance EC2 à l'ASG.

Conseil de Configuration : Assurez-vous que vos politiques de mise à l'échelle utilisent le Target Tracking Scaling configuré pour maintenir une métrique d'utilisation moyenne (par exemple, maintenir le CPU moyen à 60 %). Cela permet à AWS de gérer la mise à l'échelle dynamiquement, ce qui est généralement préféré à la mise à l'échelle par paliers statique.

Exploitation des Journaux pour des Analyses Approfondies

Lorsque des problèmes de performance surviennent, CloudWatch Logs est essentiel pour l'analyse des causes profondes.

• Journalisation Centralisée : Configurez toutes les applications et services (VPC Flow Logs, journaux Lambda, journaux de conteneurs ECS/EKS) pour les diffuser vers CloudWatch Logs.
• Log Insights : Utilisez le langage de requête puissant de Log Insights pour rechercher rapidement dans des volumes de journaux massifs. Par exemple, pour trouver toutes les requêtes qui ont pris plus de 2 secondes :

fields @timestamp, @message
| filter @message like /duration: \d{4,}/ 
| parse @message "*duration: *ms*" as duration
| filter as_number(duration) > 2000
| sort @timestamp desc
| limit 50

Meilleures Pratiques pour la Surveillance CloudWatch

Pour maximiser la valeur tirée de CloudWatch et optimiser les performances :

1. Surveiller les Limites de Service : Définissez des alarmes sur vos quotas de service AWS (par exemple, nombre maximum d'exécutions simultanées de Lambda, E/S EBS maximum disponibles pour votre compte). Atteindre un quota arrête net les performances, souvent sans erreur d'application claire.
2. Établir une Référence de Performance : Avant d'optimiser, surveillez votre système pendant les heures de pointe et creuses pour définir ce à quoi ressemble la normale. Cela évite de définir des alarmes basées sur un bruit non pertinent.
3. Utiliser le Calcul de Métriques pour les Ratios : Calculez les ratios d'efficacité directement dans CloudWatch. Par exemple, (Total des Erreurs / Total des Requêtes) * 100 pour obtenir un pourcentage direct du taux d'échec, plutôt que de jongler avec plusieurs métriques distinctes.
4. Gestion des Coûts : Les métriques personnalisées haute résolution coûtent plus cher. Soyez judicieux. Utilisez une résolution d'une minute uniquement pour les systèmes critiques à évolution rapide (comme les équilibreurs de charge). La résolution par défaut de 5 minutes est suffisante pour la plupart des services backend.
5. Stratégie de Balisage : Assurez-vous que toutes les ressources surveillées (EC2, RDS, Lambda) sont balisées de manière cohérente. Cela vous permet de créer des tableaux de bord et des alarmes filtrés spécifiques à des environnements (par exemple, Env: Prod, App: CheckoutService).

Faire Correspondre le Tableau de Bord à l'Incident

Un tableau de bord CloudWatch doit aider quelqu'un à prendre une décision sous pression. Si le tableau de bord prouve seulement que le système a de nombreuses métriques, il n'aidera pas lors d'une panne.

Pour une application web, j'aime construire le premier écran autour d'un chemin simple : le trafic entre, l'application le traite, les dépendances répondent, et les utilisateurs réussissent ou échouent. Cela signifie généralement que ces widgets sont placés les uns près des autres :

• Nombre de requêtes et nombre d'erreurs de l'équilibreur de charge ou d'API Gateway.
• Latence P95 ou P99 pour le même point d'entrée.
• Métriques de succès et d'échec au niveau de l'application.
• CPU, mémoire et nombre de tâches pour ECS, EKS, Lambda ou EC2.
• Métriques RDS, DynamoDB, Redis, SQS ou de dépendances externes qui expliquent couramment les requêtes lentes.

Les services exacts changent, mais la forme reste la même. Si la latence de paiement augmente, vous voulez voir si le trafic a grimpé, les erreurs ont augmenté, la latence de la base de données a grimpé, ou les travailleurs ont pris du retard. Mettez ces indices au même endroit.

Évitez les tableaux de bord qui mélangent production, préproduction et développement sans étiquettes claires. Lors d'un incident, quelqu'un finira par lire le mauvais graphique. Utilisez des dimensions, des balises et des conventions de nommage qui rendent l'environnement évident.

Utiliser les Centiles avec Précaution

Les centiles sont utiles pour la latence car les moyennes cachent des expériences utilisateur douloureuses. Si la plupart des requêtes se terminent en 100 ms mais qu'un groupe plus petit prend 8 secondes, la moyenne peut encore sembler acceptable. Un graphique de centiles rend la longue traîne visible.

Cela dit, les centiles ne sont pas magiques. Ils nécessitent suffisamment de trafic pour être significatifs, et ils peuvent sembler bruyants sur les services à faible volume. Pour un petit travail interne qui s'exécute quelques fois par heure, une durée maximale ou une métrique d'échec explicite peut être plus utile que P99. Pour une API publique avec un trafic régulier, P95 et P99 valent souvent la peine d'être surveillés.

Lorsque vous créez une alarme, assurez-vous que la commande CLI utilise la statistique que vous avez réellement l'intention d'utiliser. Pour une alarme de centile, utilisez --extended-statistic p95 ou p99, pas --statistic Average :

aws cloudwatch put-metric-alarm \
  --alarm-name "HighCheckoutP95Latency" \
  --metric-name "CheckoutLatency" \
  --namespace "MyApp/ECommerce" \
  --extended-statistic p95 \
  --period 60 \
  --threshold 500 \
  --evaluation-periods 5 \
  --datapoints-to-alarm 3 \
  --comparison-operator GreaterThanThreshold \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:PerformanceAlertsTopic

Le paramètre datapoints-to-alarm est important. Exiger trois périodes sur cinq peut détecter un problème soutenu sans pages pour une minute bruyante. Pour les systèmes critiques, ajustez cela avec du trafic historique réel plutôt que de deviner.

Placer les Métriques d'Application à Côté des Métriques AWS

Les métriques de service AWS vous disent ce que la plateforme voit. Vos métriques d'application vous disent ce que l'utilisateur essaie de faire. Vous avez besoin des deux.

Par exemple, un service ECS peut montrer un CPU et une mémoire normaux alors que le paiement est cassé parce qu'un fournisseur de paiement expire. CloudWatch ne le saura pas à moins que votre application ne publie une métrique telle que PaymentAuthorizationFailure, CheckoutCompleted ou PaymentProviderLatency.

Les bonnes métriques personnalisées sont généralement liées à des actions commerciales :

• LoginSucceeded et LoginFailed
• OrderCreated
• PaymentAuthorizationLatency
• QueueJobProcessed
• ImportRowsFailed

Gardez les dimensions utiles mais pas explosives. Service, Environnement et Région sont généralement corrects. Une dimension pour chaque ID utilisateur, ID de requête ou chemin d'URL peut créer un coût de haute cardinalité et rendre les données plus difficiles à utiliser. Pour une enquête détaillée par requête, les journaux et les traces sont un meilleur endroit.

Le format de métrique intégré CloudWatch (Embedded Metric Format) est pratique lorsque vous écrivez déjà des journaux JSON structurés. Il vous permet d'émettre des journaux et des métriques à partir du même événement, ce qui simplifie l'instrumentation de l'application. Le compromis est le coût et le volume : les journaux structurés sont puissants, mais les journaux bruyants deviennent rapidement coûteux.

Construire des Alarmes Autour des Symptômes et des Causes

Une erreur de surveillance courante est de ne déclencher des alarmes que sur les causes : CPU élevé, mémoire élevée, file d'attente disque élevée. Ce sont utiles, mais ils ne signifient pas toujours que les utilisateurs sont affectés. Une autre erreur est de ne déclencher des alarmes que sur les symptômes : taux d'erreur élevé, latence élevée, échecs de commandes. Ceux-ci vous disent que les utilisateurs sont affectés, mais ils n'expliquent pas pourquoi.

Une configuration pratique utilise les deux :

• Les alarmes de symptômes pagent le propriétaire du service : taux d'erreur élevé, latence élevée, aucune commande réussie, âge de la file d'attente en augmentation.
• Les alarmes de cause soutiennent le diagnostic : CPU de la base de données, requêtes DynamoDB limitées, concurrence Lambda, solde de rafale épuisé, espace disque faible.
• Les alarmes de capacité avertissent tôt : Auto Scaling proche du maximum, quota de service approché, arriéré de file d'attente croissant plus vite que les travailleurs ne peuvent le drainer.

Si chaque alarme page le même canal avec la même urgence, les gens cessent de faire confiance au canal. Rendez les alarmes d'avertissement visibles sans réveiller quelqu'un, et réservez les pages pour l'impact utilisateur ou l'impact utilisateur quasi certain.

Utiliser Logs Insights pour des Questions, Pas Seulement des Recherches

CloudWatch Logs Insights est plus utile lorsque l'équipe enregistre des requêtes pour des questions qu'elle se pose régulièrement. Exemples :

fields @timestamp, status, path, durationMs
| filter status >= 500
| stats count() as errors by path
| sort errors desc
| limit 20

fields @timestamp, requestId, customerId, durationMs
| filter durationMs > 2000
| sort durationMs desc
| limit 50

fields @timestamp, @message
| filter @message like /ThrottlingException|Rate exceeded/
| sort @timestamp desc
| limit 100

Ces requêtes ne remplacent pas le traçage, mais elles sont assez rapides pour une première réponse. Enregistrez-les dans des runbooks ou des widgets de texte de tableau de bord afin que la personne suivante n'ait pas à se souvenir de la syntaxe pendant que le système est lent.

Examiner les Coûts Tout en Améliorant la Visibilité

CloudWatch peut devenir coûteux lorsque les équipes activent des métriques personnalisées haute résolution, conservent chaque journal indéfiniment ou créent trop de dimensions de métriques uniques. La surveillance des performances ne devrait pas créer une facture surprise.

Définissez les périodes de conservation intentionnellement. Les journaux d'application de production peuvent nécessiter une conservation plus longue que les journaux de débogage du développement. Les journaux de sécurité et d'audit peuvent avoir leurs propres règles. Pour les services verbeux, envisagez de filtrer ou d'échantillonner les journaux d'information bruyants avant qu'ils n'atteignent CloudWatch.

Pour les métriques, commencez par la résolution qui correspond à l'action que vous pouvez entreprendre. Si un service prend plusieurs minutes pour évoluer en toute sécurité, les métriques à une seconde peuvent ne pas améliorer la réponse. Si un pic de latence doit être détecté immédiatement, les métriques haute résolution peuvent en valoir la peine pour ce signal étroit.

Une Première Configuration CloudWatch Utile

Pour un nouveau service de production, un premier passage solide est :

1. Un tableau de bord avec le trafic, la latence, les erreurs, la saturation et la santé des dépendances.
2. Des alarmes pour un taux d'erreur élevé, une latence élevée, aucun trafic réussi lorsque le trafic est attendu, l'âge de la file d'attente et un espace disque faible le cas échéant.
3. Des métriques d'application pour les principales actions des utilisateurs.
4. Des journaux structurés avec des ID de requête et suffisamment de champs pour filtrer par route, statut, durée et dépendance.
5. Des requêtes Logs Insights enregistrées pour les requêtes lentes, les erreurs 5xx, la limitation et les tâches d'arrière-plan échouées.
6. Une revue mensuelle des alarmes bruyantes, des alarmes manquantes et du coût CloudWatch.

CloudWatch fonctionne mieux lorsqu'il fait partie de la façon dont l'équipe opère, pas un tableau de bord que quelqu'un ouvre seulement après que les utilisateurs se plaignent. Commencez par les questions que vous posez lors des incidents, puis façonnez les métriques, les alarmes et les journaux autour de ces questions.