Qu'est-ce que le Cloud Monitoring ?

Qu'est-ce que le cloud monitoring ?

Le cloud monitoring est l'observation continue des workloads, services et composants managés tournant sur un cloud public (AWS, GCP, Azure, OCI) ou un mélange hybride cloud et on-prem. Il tire métriques, logs, traces et événements depuis des sources cloud-native (CloudWatch, Cloud Monitoring, Azure Monitor, le control plane de EKS ou ECS, RDS performance insights, S3 request metrics, ALB access logs, invocations Lambda) et depuis tout agent que tu déploies sur VMs ou containers, puis expose le résultat sous forme de dashboards, alertes et workflows d'incidents.

La sortie a la même forme que le monitoring classique (graphes, alertes, rotations on-call) mais les sources de données et l'unit of work diffèrent : containers éphémères au lieu d'hôtes longue durée, services managés au lieu de daemons auto-gérés, billing à l'invocation au lieu de serveurs à coût fixe. Les outils du domaine incluent Datadog, New Relic, Dynatrace, Grafana Cloud, AWS CloudWatch, Google Cloud Operations et Azure Monitor.

Cloud monitoring vs on-prem monitoring vs APM

Les disciplines se chevauchent mais la forme de la donnée diffère :

• Cloud monitoring consomme des métriques de services managés et du compute éphémère (containers, functions). L'unit of work churne à la minute et les tags pilotent le regroupement (account, region, service, environment).
• On-prem monitoring surveille du hardware fixe : hôtes nommés dans DNS depuis des années, switches, storage arrays. Les outils comme Nagios, Zabbix ou PRTG se centrent sur SNMP et l'installation par hôte.
• APM est orthogonal aux deux : il instrumente le code applicatif quel que soit l'endroit où il tourne et reporte la latence et les erreurs par endpoint. Voir application performance monitoring pour la couche application.

La plupart des équipes sur cloud ont besoin de cloud monitoring pour l'infrastructure et d'APM pour le code applicatif ; la voie on-prem rétrécit mais reste pertinente pour les workloads régulés.

Ce que couvre le cloud monitoring

• Santé du compute : CPU, mémoire, disque des EC2/GCE/Azure VM ; nombre de containers, restarts, pods pending sur ECS/EKS/GKE/AKS.
• Métriques des services managés : RDS connections, hit rate ElastiCache, throttles DynamoDB, S3 4xx/5xx, profondeur de file SQS, ALB target response time.
• Serverless : nombre d'invocations Lambda, durée, erreurs, throttles, exécutions concurrentes ; idem pour Cloud Functions et Azure Functions.
• Réseau et edge : hit rate de cache CloudFront, bytes NAT gateway, VPC flow logs, volume de queries Route 53.
• Signaux de coût : spend quotidien par compte, coût unblended par service ou tag, alertes d'anomalie quand le spend quotidien saute.
• Sécurité et audit : événements CloudTrail, findings GuardDuty, IAM access analyzer ; pas un substitut SIEM mais la couche d'early warning.

Métriques clés du cloud monitoring

1. Availability par service : CloudWatch HealthyHostCount, ALB target health, RDS instance state, agrégés en target SLA.
2. Latence par composant managé : latence des queries RDS, ALB TargetResponseTime p50/p95/p99, latence first-byte S3.
3. Error rate par couche : ALB HTTPCode_Target_5XX_Count, Lambda Errors, deadlocks RDS, profondeur dead-letter SQS.
4. Saturation : CPU credits remaining sur les instances burstable, saturation CPU et connexions RDS, evictions ElastiCache, autoscaling group desired vs in-service.
5. Throughput : requests par seconde par service, bytes par seconde par chemin réseau, messages par minute via SQS/SNS/Kinesis.
6. Coût par requête : spend divisé par travail utile, la métrique d'efficacité long-terme que la plupart des équipes ignorent jusqu'à ce que la facture flambe.

Comment faire tourner le cloud monitoring

Commence par le metric stream natif du provider (CloudWatch metric streams vers Firehose, ou polling API direct pour un seul cloud) et redirige-le vers un backend central (Datadog, Grafana, ton propre Prometheus + Mimir). Tague chaque ressource de façon cohérente (service, environment, team, cost-center) pour que la même requête de dashboard slice par n'importe quelle dimension. Empile dessus les logs (CloudWatch Logs ou Cloud Logging) et les traces (X-Ray, Cloud Trace, OpenTelemetry vers le même backend). Branche les alertes sur PagerDuty ou Opsgenie avec rotations on-call par service. Élague périodiquement les métriques que personne ne possède : les factures de cloud monitoring grossissent plus vite que l'infrastructure.

Le cloud monitoring se place à côté du load testing dans le pipeline de launch readiness. Fais tourner load testing ou spike testing depuis l'extérieur du réseau cloud, observe les dashboards de cloud monitoring en direct et capture quel composant managé sature en premier (connexions à la base, lag d'autoscaling, profondeur de dead-letter queue). Voir aussi observability pour le framework d'investigation plus large que le cloud monitoring alimente.

Si ton équipe a besoin de runs de charge production-shape qui corrèlent proprement avec tes dashboards de cloud monitoring, LoadFocus propose des services de load testing avec des runs planifiés pour s'aligner sur tes fenêtres de dashboard, et des rapports de synthèse référencés à tes captures CloudWatch ou Datadog.