Lab : Mise en Place du Monitoring
Objectif
Configurer un système de monitoring complet avec métriques, alarmes, logs et dashboard.
Partie 1 : Alarmes de Base
Exercice 1.1 : Alarme CPU
Créez une alarme qui se déclenche quand le CPU dépasse 80% pendant 10 minutes :
# Complétez la commande
aws cloudwatch put-metric-alarm \
--alarm-name _____ \
--metric-name _____ \
--namespace _____ \
--statistic _____ \
--period _____ \
--threshold _____ \
--comparison-operator _____ \
--evaluation-periods _____ \
--dimensions Name=InstanceId,Value=i-xxx \
--alarm-actions arn:aws:sns:...:alerts
💡 Solution
aws cloudwatch put-metric-alarm \
--alarm-name ec2-cpu-high \
--metric-name CPUUtilization \
--namespace AWS/EC2 \
--statistic Average \
--period 300 \
--threshold 80 \
--comparison-operator GreaterThanThreshold \
--evaluation-periods 2 \
--dimensions Name=InstanceId,Value=i-xxx \
--alarm-actions arn:aws:sns:us-east-1:123456789:alerts \
--alarm-description "CPU above 80% for 10 minutes"
Explication :
- Period 300s × 2 evaluations = 10 minutes
- Average pour éviter les faux positifs des pics courts
Exercice 1.2 : Alarme Disque
Créez une alarme pour l'espace disque faible (> 85% utilisé) :
| Paramètre | Valeur |
|---|---|
| Metric Name | ? |
| Namespace | ? |
| Threshold | ? |
| Period | ? |
💡 Solution
| Paramètre | Valeur |
|---|---|
| Metric Name | disk_used_percent |
| Namespace | CWAgent |
| Threshold | 85 |
| Period | 3600 (1 heure) |
Note : Cette métrique nécessite CloudWatch Agent installé sur l'instance.
Partie 2 : Configuration des Logs
Exercice 2.1 : Log Group et Rétention
# Créer un log group avec rétention de 30 jours
aws logs create-log-group \
--log-group-name /app/web-server
aws logs put-retention-policy \
--log-group-name /app/web-server \
--retention-in-days _____
💡 Solution
aws logs put-retention-policy \
--log-group-name /app/web-server \
--retention-in-days 30
Valeurs possibles : 1, 3, 5, 7, 14, 30, 60, 90, 120, 150, 180, 365, 400, 545, 731, 1096, 1827, 2192, 2557, 2922, 3288, 3653
Exercice 2.2 : Metric Filter
Créez un filtre pour compter les erreurs 500 dans les logs :
aws logs put-metric-filter \
--log-group-name /app/web-server \
--filter-name error-500-count \
--filter-pattern '_______________' \
--metric-transformations \
metricName=Error500Count,\
metricNamespace=WebApp,\
metricValue=1
💡 Solution
aws logs put-metric-filter \
--log-group-name /app/web-server \
--filter-name error-500-count \
--filter-pattern '"HTTP/1.1" 500' \
--metric-transformations \
metricName=Error500Count,\
metricNamespace=WebApp,\
metricValue=1
# Ou pour JSON logs
aws logs put-metric-filter \
--log-group-name /app/web-server \
--filter-name error-500-json \
--filter-pattern '{ $.statusCode = 500 }' \
--metric-transformations \
metricName=Error500Count,\
metricNamespace=WebApp,\
metricValue=1
Partie 3 : Log Insights Queries
Exercice 3.1 : Requêtes d'Analyse
Écrivez les requêtes Log Insights pour :
A. Les 10 dernières erreurs :
# Votre requête ici
B. Nombre d'erreurs par heure sur les 24h :
# Votre requête ici
C. Top 5 des pages avec erreur 404 :
# Votre requête ici
💡 Solutions
A. Les 10 dernières erreurs :
fields @timestamp, @message
| filter @message like /ERROR|Exception|error/
| sort @timestamp desc
| limit 10
B. Nombre d'erreurs par heure sur les 24h :
fields @timestamp, @message
| filter @message like /ERROR/
| stats count() as error_count by bin(1h)
| sort @timestamp desc
C. Top 5 des pages avec erreur 404 :
fields @timestamp, @message
| filter @message like /404/
| parse @message /GET (?<path>\/[^ ]*)/
| stats count() as hits by path
| sort hits desc
| limit 5
Partie 4 : Dashboard
Exercice 4.1 : Créer un Dashboard
Définissez les widgets pour un dashboard de production :
| Widget | Type | Métrique | Période |
|---|---|---|---|
| CPU Overview | ? | ? | ? |
| Memory Usage | ? | ? | ? |
| Request Count | ? | ? | ? |
| Error Rate | ? | ? | ? |
| Latency P99 | ? | ? | ? |
| Alarm Status | ? | ? | ? |
💡 Solution
| Widget | Type | Métrique | Période |
|---|---|---|---|
| CPU Overview | Line | CPUUtilization | 5 min |
| Memory Usage | Line | mem_used_percent | 5 min |
| Request Count | Stacked Area | RequestCount | 1 min |
| Error Rate | Number | HTTPCode_5XX / Total × 100 | 5 min |
| Latency P99 | Line | TargetResponseTime p99 | 1 min |
| Alarm Status | Alarm Status | Toutes les alarmes | - |
Exercice 4.2 : Dashboard JSON
{
"widgets": [
{
"type": "metric",
"properties": {
"title": "CPU Utilization",
"metrics": [
["AWS/EC2", "CPUUtilization", "InstanceId", "i-xxx"]
],
"period": 300,
"stat": "Average",
"region": "us-east-1"
}
},
{
"type": "___",
"properties": {
"title": "Alarm Status",
"alarms": [
"arn:aws:cloudwatch:...:alarm:cpu-high",
"arn:aws:cloudwatch:...:alarm:mem-high"
]
}
}
]
}
💡 Solution
{
"widgets": [
{
"type": "metric",
"x": 0, "y": 0, "width": 12, "height": 6,
"properties": {
"title": "CPU Utilization",
"metrics": [
["AWS/EC2", "CPUUtilization", "InstanceId", "i-xxx"]
],
"period": 300,
"stat": "Average",
"region": "us-east-1",
"view": "timeSeries"
}
},
{
"type": "alarm",
"x": 12, "y": 0, "width": 12, "height": 6,
"properties": {
"title": "Alarm Status",
"alarms": [
"arn:aws:cloudwatch:us-east-1:123456789:alarm:cpu-high",
"arn:aws:cloudwatch:us-east-1:123456789:alarm:mem-high"
]
}
}
]
}
Partie 5 : Runbook
Exercice 5.1 : Créer un Runbook
Complétez le runbook pour l'incident "Mémoire Haute" :
┌─────────────────────────────────────────────────────────────┐
│ RUNBOOK : MÉMOIRE HAUTE (> 90%) │
├─────────────────────────────────────────────────────────────┤
│ │
│ ÉVALUATION INITIALE (2 min max) │
│ ☐ _______________________________________ │
│ ☐ _______________________________________ │
│ │
│ DIAGNOSTIC (5 min max) │
│ ☐ _______________________________________ │
│ ☐ _______________________________________ │
│ ☐ _______________________________________ │
│ │
│ ACTIONS DE REMÉDIATION │
│ ☐ _______________________________________ │
│ ☐ _______________________________________ │
│ │
│ VALIDATION │
│ ☐ _______________________________________ │
│ ☐ _______________________________________ │
│ │
└─────────────────────────────────────────────────────────────┘
💡 Solution
┌─────────────────────────────────────────────────────────────┐
│ RUNBOOK : MÉMOIRE HAUTE (> 90%) │
├─────────────────────────────────────────────────────────────┤
│ │
│ ÉVALUATION INITIALE (2 min max) │
│ ☐ Vérifier si plusieurs instances sont affectées │
│ ☐ Vérifier les erreurs utilisateur (502, timeouts) │
│ │
│ DIAGNOSTIC (5 min max) │
│ ☐ Connexion SSH : free -h, top -o %MEM │
│ ☐ Identifier le processus consommateur de mémoire │
│ ☐ Vérifier les logs applicatifs pour fuites mémoire │
│ │
│ ACTIONS DE REMÉDIATION │
│ ☐ Si fuite mémoire : Redémarrer l'application │
│ ☐ Si charge légitime : Scale out (ajouter instances) │
│ ☐ Libérer cache si possible (drop_caches) │
│ │
│ VALIDATION │
│ ☐ Mémoire revenue < 80% ? │
│ ☐ Application fonctionne normalement ? │
│ ☐ Créer ticket pour analyse post-mortem │
│ │
└─────────────────────────────────────────────────────────────┘
Partie 6 : Scénario Complet
Contexte
Vous recevez une alerte : "Error rate above 5% for web-app"
Questions
- Quelles métriques consultez-vous en premier ?
- Quels logs analysez-vous ?
- Quelle requête Log Insights utilisez-vous ?
- Comment identifiez-vous la cause racine ?
💡 Solution Détaillée
1. Métriques à consulter :
- HTTPCode_Target_5XX (ALB) → Confirmer les erreurs 500
- RequestCount → Volume de trafic
- TargetResponseTime → Latence
- HealthyHostCount → Instances down ?
- CPUUtilization, Memory → Ressources saturées ?
2. Logs à analyser :
- /aws/elasticloadbalancing/ → Logs ALB
- /app/web-server → Logs applicatifs
- /var/log/messages → Logs système
3. Requête Log Insights :
fields @timestamp, @message
| filter @message like /500|ERROR|Exception/
| stats count() by bin(5m)
| sort @timestamp desc
Puis pour détailler :
fields @timestamp, @message
| filter @message like /500/
| parse @message /(?<endpoint>\/api\/[^ ]*)/
| stats count() by endpoint
| sort count desc
| limit 10
4. Processus d'identification :
- Corréler le timing du pic d'erreurs avec les déploiements
- Identifier l'endpoint problématique
- Vérifier les logs de cet endpoint spécifique
- Chercher la stack trace de l'erreur
- Identifier la cause (DB timeout, bug code, config...)
Livrable
Document à Produire
- Configuration des alarmes (CLI commands)
- Requêtes Log Insights (3 minimum)
- Définition du Dashboard (JSON ou description)
- Runbook complet pour 2 scénarios
- Analyse du scénario avec solution
Critères d'Évaluation
| Critère | Points |
|---|---|
| Alarmes correctement configurées | /20 |
| Requêtes Log Insights | /20 |
| Dashboard pertinent | /20 |
| Runbooks complets | /25 |
| Analyse du scénario | /15 |
| Total | /100 |
Semaine suivante : MODULE 14 - FinOps