Alarmes et Alertes CloudWatch
Introduction
Les alarmes CloudWatch surveillent vos metriques et declenchent des actions automatiques quand des seuils sont atteints. C'est un composant essentiel de l'observabilite et de la reactivite operationnelle.
Architecture des Alarmes
┌─────────────────────────────────────────────────────────────────┐
│ FLUX DES ALARMES │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────────────────┐ │
│ │ Metrique │────►│ Alarme │────►│ Actions │ │
│ │ │ │ │ │ │ │
│ │ CPU 85% │ │ Seuil>80%│ │ • SNS (email/SMS) │ │
│ └──────────┘ └──────────┘ │ • Auto Scaling │ │
│ │ • Lambda │ │
│ │ • EC2 (stop/reboot) │ │
│ └──────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
Etats d'une Alarme
┌─────────────────────────────────────────────────────────────────┐
│ ETATS D'ALARME │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────┐ │
│ │ OK │ Metrique dans les limites normales │
│ │ (Vert) │ │
│ └────────┬────────┘ │
│ │ │
│ ▼ Seuil depasse │
│ ┌─────────────────┐ │
│ │ ALARM │ Seuil atteint → Actions declenchees │
│ │ (Rouge) │ │
│ └────────┬────────┘ │
│ │ │
│ ▼ Donnees manquantes │
│ ┌─────────────────┐ │
│ │ INSUFFICIENT │ Pas assez de donnees pour evaluer │
│ │ DATA │ │
│ │ (Gris) │ │
│ └─────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
Configuration d'une Alarme
Elements de Configuration
┌─────────────────────────────────────────────────────────────────┐
│ ANATOMIE D'UNE ALARME │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 1. METRIQUE │
│ └── Quelle metrique surveiller ? │
│ Ex: CPUUtilization, NetworkIn, Errors │
│ │
│ 2. STATISTIQUE │
│ └── Comment agreger les donnees ? │
│ Average, Sum, Minimum, Maximum, SampleCount │
│ │
│ 3. PERIODE │
│ └── Fenetre de temps pour chaque point │
│ 60s, 300s (5min), 3600s (1h) │
│ │
│ 4. SEUIL │
│ └── Quelle valeur declenche l'alarme ? │
│ > 80%, < 10, >= 1000 │
│ │
│ 5. PERIODES D'EVALUATION │
│ └── Combien de periodes en violation ? │
│ "3 sur 5 periodes" (evite faux positifs) │
│ │
│ 6. ACTIONS │
│ └── Que faire quand l'alarme se declenche ? │
│ Notification, Auto Scaling, etc. │
│ │
└─────────────────────────────────────────────────────────────────┘
Exemple : Alarme CPU EC2
# Pseudo-configuration CloudFormation
HighCPUAlarm:
Type: AWS::CloudWatch::Alarm
Properties:
AlarmName: "EC2-HighCPU-Production"
AlarmDescription: "CPU superieur a 80% pendant 5 minutes"
# Metrique
Namespace: "AWS/EC2"
MetricName: "CPUUtilization"
Dimensions:
- Name: InstanceId
Value: "i-1234567890abcdef0"
# Evaluation
Statistic: "Average"
Period: 60 # 1 minute
EvaluationPeriods: 5 # 5 periodes
DatapointsToAlarm: 3 # 3 sur 5 en violation
# Seuil
ComparisonOperator: "GreaterThanThreshold"
Threshold: 80
# Actions
AlarmActions:
- "arn:aws:sns:us-east-1:123456789:AlerteOps"
OKActions:
- "arn:aws:sns:us-east-1:123456789:AlerteOps"
Types d'Alarmes Courantes
1. Alarmes de Performance
| Service | Metrique | Seuil typique | Raison |
|---|---|---|---|
| EC2 | CPUUtilization | > 80% | Surcharge |
| EC2 | StatusCheckFailed | > 0 | Instance defaillante |
| RDS | DatabaseConnections | > 80% max | Saturation |
| ELB | TargetResponseTime | > 2s | Latence |
| Lambda | Duration | > 80% timeout | Risque timeout |
2. Alarmes d'Erreurs
| Service | Metrique | Seuil typique | Raison |
|---|---|---|---|
| Lambda | Errors | > 1% | Taux d'erreur |
| ALB | HTTPCode_Target_5XX | > 10 | Erreurs serveur |
| API Gateway | 4XXError | > 5% | Erreurs client |
| SQS | ApproximateNumberOfMessagesVisible | > 1000 | File saturee |
3. Alarmes de Couts
| Metrique | Seuil | Action |
|---|---|---|
| EstimatedCharges | > Budget | Notification |
| EC2 Running Hours | > Prevu | Investigation |
Alarmes Composites
┌─────────────────────────────────────────────────────────────────┐
│ ALARME COMPOSITE │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Combine plusieurs alarmes avec logique AND/OR/NOT │
│ │
│ Exemple : Alerte critique seulement si : │
│ - CPU > 80% ET │
│ - Memoire > 90% ET │
│ - PAS en maintenance │
│ │
│ ┌────────────┐ │
│ │ CPU > 80% │───┐ │
│ └────────────┘ │ │
│ │ AND │
│ ┌────────────┐ ├────────► ALARME COMPOSITE │
│ │ Mem > 90% │───┤ │ │
│ └────────────┘ │ ▼ │
│ │ Actions critiques │
│ ┌────────────┐ │ │
│ │NOT Maint. │───┘ │
│ └────────────┘ │
│ │
│ Avantage : Reduit les faux positifs │
│ │
└─────────────────────────────────────────────────────────────────┘
Actions Automatiques
SNS (Notifications)
┌─────────────────────────────────────────────────────────────────┐
│ NOTIFICATIONS SNS │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Alarme ────► SNS Topic ────► Abonnes │
│ │ │
│ ├──► Email (equipe-ops@company.com) │
│ ├──► SMS (+1-555-123-4567) │
│ ├──► Slack (webhook) │
│ ├──► PagerDuty (integration) │
│ └──► Lambda (automatisation) │
│ │
└─────────────────────────────────────────────────────────────────┘
Auto Scaling
Alarme CPU > 80% ────► Action: Scale Out (+2 instances)
Alarme CPU < 30% ────► Action: Scale In (-1 instance)
Actions EC2
Alarme StatusCheck Failed ────► Action: Recover Instance
Alarme Instance Idle ────► Action: Stop Instance
Bonnes Pratiques
1. Eviter les Faux Positifs
# MAUVAIS : Alarme trop sensible
Period: 60
EvaluationPeriods: 1
DatapointsToAlarm: 1
# → Declenche au moindre pic
# BON : Alarme avec tolerance
Period: 60
EvaluationPeriods: 5
DatapointsToAlarm: 3
# → 3 violations sur 5 minutes = vrai probleme
2. Nomenclature Claire
Format recommande :
[Environnement]-[Service]-[Metrique]-[Severite]
Exemples :
• PROD-EC2-HighCPU-Critical
• PROD-Lambda-Errors-Warning
• DEV-RDS-Connections-Info
3. Documentation des Alarmes
Chaque alarme devrait avoir :
• Description claire
• Runbook associe (que faire quand elle se declenche)
• Proprietaire (qui est responsable)
• Historique des declenchements
Exemple de Configuration Complete
Surveillance d'une Application Web
┌─────────────────────────────────────────────────────────────────┐
│ ALARMES POUR APPLICATION WEB │
├─────────────────────────────────────────────────────────────────┤
│ │
│ COUCHE PRESENTATION (ALB) │
│ ├── ALB-HighLatency (ResponseTime > 2s) │
│ ├── ALB-High5XX (5XX > 10/min) │
│ └── ALB-UnhealthyHosts (> 0) │
│ │
│ COUCHE APPLICATION (EC2/Lambda) │
│ ├── EC2-HighCPU (> 80%) │
│ ├── EC2-HighMemory (> 85%) │
│ ├── Lambda-HighErrors (> 1%) │
│ └── Lambda-NearTimeout (> 80% timeout) │
│ │
│ COUCHE DONNEES (RDS) │
│ ├── RDS-HighCPU (> 80%) │
│ ├── RDS-LowStorage (< 20%) │
│ ├── RDS-HighConnections (> 80% max) │
│ └── RDS-ReplicaLag (> 60s) │
│ │
│ COUTS │
│ └── Billing-OverBudget (> budget mensuel) │
│ │
└─────────────────────────────────────────────────────────────────┘
Exercice : Creer un Plan d'Alarmes
Pour une application e-commerce, definissez les alarmes pour :
- Disponibilite : L'application est accessible
- Performance : Temps de reponse acceptable
- Erreurs : Taux d'erreur bas
- Capacite : Ressources suffisantes
Voir la solution
| Categorie | Alarme | Metrique | Seuil | Action |
|---|---|---|---|---|
| Disponibilite | ALB-NoHealthyTargets | HealthyHostCount | = 0 | PagerDuty Critical |
| Disponibilite | Route53-HealthCheck | HealthCheckStatus | Failed | SNS + Failover |
| Performance | ALB-HighLatency | TargetResponseTime | > 3s | SNS Warning |
| Performance | Lambda-SlowExecution | Duration | > 10s | SNS Warning |
| Erreurs | ALB-High5XX | HTTPCode_Target_5XX | > 50/5min | SNS Critical |
| Erreurs | Lambda-HighErrors | Errors | > 5% | SNS Critical |
| Capacite | EC2-HighCPU | CPUUtilization | > 80% | Auto Scaling |
| Capacite | RDS-LowStorage | FreeStorageSpace | < 10GB | SNS Warning |
Resume
- Les alarmes surveillent les metriques et declenchent des actions
- 3 etats : OK, ALARM, INSUFFICIENT_DATA
- Configurez des periodes d'evaluation pour eviter les faux positifs
- Utilisez des alarmes composites pour des conditions complexes
- Documentez chaque alarme avec un runbook
Prochaine section : Quiz de Validation