Les trois piliers du monitoring cloud
Monitoring d'infrastructure
C'est le socle : compute (CPU, mémoire, I/O disque), stockage (débit, IOPS, latence) et santé de la plateforme sous-jacente (hyperviseur, runtime de conteneurs, environnement d'exécution serverless). Chaque fournisseur cloud expose ces données nativement :
- AWS CloudWatch — métriques pour EC2, RDS, EBS, Lambda, plus des métriques personnalisées via l'agent CloudWatch ou StatsD
- Azure Monitor — métriques de plateforme collectées automatiquement pour toutes les ressources Azure, avec un workspace Log Analytics pour des requêtes plus poussées (KQL)
- GCP Cloud Monitoring (ex-Stackdriver) — collecte automatique des métriques pour Compute Engine, GKE, Cloud SQL et Cloud Functions
Le piège ici est de surveiller les moyennes. Un CPU à 45 % en moyenne semble sain, mais s'il monte à 98 % pendant 10 secondes chaque minute, vos utilisateurs subissent des files d'attente que la moyenne masque. Surveillez toujours les percentiles (p95, p99) pour la latence et les métriques liées à la saturation.
Monitoring de la performance applicative (APM)
L'APM instrumente votre code pour tracer les requêtes de bout en bout à travers les microservices, bases de données, caches et API externes. Les signaux standards sont les métriques RED : taux de requêtes (Rate), taux d'erreur (Errors) et durée (Duration — distribution de latence).
OpenTelemetry est devenu le standard de facto pour l'instrumentation. Il est neutre vis-à-vis des fournisseurs, supporte l'auto-instrumentation en Java, Python, .NET, Go, Node.js et plus encore, et exporte vers n'importe quel backend — Datadog, Dynatrace, Grafana Tempo, AWS X-Ray, Azure Application Insights ou GCP Cloud Trace. Si vous partez de zéro en 2026, instrumentez avec les SDK OpenTelemetry et choisissez votre backend séparément. Cela évite le verrouillage fournisseur sur la couche d'instrumentation, qui est la plus difficile à remplacer par la suite.
Ce qui compte opérationnellement : des traces distribuées permettant de voir qu'une requête de paiement a passé 12 ms dans l'API gateway, 45 ms dans le service de commandes, 800 ms en attente d'une API de paiement tierce, et 3 ms en écriture dans DynamoDB. Sans cette décomposition, tout ce que vous savez c'est « le paiement est lent ».
Monitoring réseau
L'observabilité réseau est le point aveugle de la plupart des stratégies de monitoring cloud. À l'intérieur d'un VPC, vous vous appuyez sur les flow logs (VPC Flow Logs sur AWS, NSG Flow Logs sur Azure, VPC Flow Logs sur GCP) pour observer les schémas de trafic, les paquets rejetés et les volumes de transfert inter-AZ/inter-régions.
Pour les configurations hybrides — Direct Connect, ExpressRoute, Cloud Interconnect — surveiller la santé du tunnel, l'état des sessions BGP et la gigue/perte de paquets sur la liaison est critique. Un circuit Direct Connect dégradé n'apparaîtra pas dans vos métriques applicatives tant que la latence n'aura pas doublé et que les clients n'appelleront pas.
Des outils comme Kentik, ThousandEyes (désormais Cisco) et les services natifs de monitoring réseau cloud gèrent bien ce cas. Si votre environnement est mono-cloud et simple, les outils natifs suffisent. Multi-cloud ou hybride ? Vous avez besoin d'une couche d'observabilité réseau dédiée.
Les métriques qui comptent réellement en production
Toutes les métriques ne méritent pas une alerte. Voici ce que notre NOC priorise, classé par valeur opérationnelle :
| Métrique | Pourquoi elle compte | Recommandation de seuil d'alerte |
|---|---|---|
| Latence p95/p99 | Représente l'expérience de vos utilisateurs les plus lents (et souvent les plus importants) | >2× la baseline pendant 5 minutes |
| Taux d'erreur (5xx) | Indicateur direct de fonctionnalité cassée | >0,5 % du total des requêtes pendant 2 minutes |
| Saturation (CPU/Mémoire/Disque) | Prédit une panne imminente avant qu'elle ne survienne | >85 % soutenu pendant 10 minutes |
| Taux de requêtes (RPS) | Les chutes soudaines signalent des problèmes en amont ou du trafic mal routé | >30 % d'écart par rapport à la baseline prédite |
| Time to First Byte (TTFB) | Proxy de performance côté utilisateur, surtout pour les applications mondiales | >500 ms en bordure de CDN |
| Temps de résolution DNS | Souvent négligé ; une résolution DNS lente ajoute de la latence à chaque requête | >100 ms en moyenne |
| Retard de réplication | Pour les bases de données (RDS, Cloud SQL, Cosmos DB) — risque de cohérence des données | >5 secondes pour les charges transactionnelles |
| Compteur de redémarrages de conteneurs | Les patterns OOMKilled ou CrashLoopBackOff signalent une mauvaise configuration des ressources | >3 redémarrages en 15 minutes |
La méthode USE (Utilization, Saturation, Errors) fonctionne bien pour les ressources d'infrastructure. La méthode RED (Rate, Errors, Duration) fonctionne bien pour les services. Utilisez les deux. Elles se complètent — USE vous renseigne sur la machine, RED vous renseigne sur le travail que la machine effectue.
Comparatif des outils : natifs vs. tiers
Outils de monitoring cloud natifs
| Fonctionnalité | AWS CloudWatch | Azure Monitor | GCP Cloud Monitoring |
|---|---|---|---|
| Métriques auto-collectées | Oui (basique) | Oui (métriques de plateforme) | Oui (basique) |
| Métriques personnalisées | Oui (API CloudWatch / embedded metric format) | Oui (API custom metrics) | Oui (API custom metrics) |
| Agrégation des logs | CloudWatch Logs / Logs Insights | Log Analytics (KQL) | Cloud Logging |
| Tracing distribué | X-Ray | Application Insights | Cloud Trace |
| Alerting | CloudWatch Alarms + SNS | Action Groups + Logic Apps | Alerting Policies + Pub/Sub |
| Tableaux de bord | CloudWatch Dashboards | Azure Dashboards / Workbooks | Cloud Monitoring Dashboards |
| Coût à l'échelle | Élevé (métriques personnalisées, ingestion de logs) | Modéré (tarification ingestion Log Analytics) | Modéré |
Le point de vue d'Opsio : Les outils natifs sont le bon point de départ et restent essentiels pour les métriques spécifiques aux ressources que les outils tiers ne peuvent pas collecter (par ex., exécutions concurrentes Lambda, compteurs de lettres mortes Azure Service Bus). Mais si vous opérez des charges de travail sur deux fournisseurs ou plus — ce qui est le cas de la grande majorité des entreprises selon le State of the Cloud de Flexera — vous avez besoin d'une couche cross-cloud.
Plateformes d'observabilité tierces
- Datadog — La solution tout-en-un la plus complète : infrastructure, APM, logs, monitoring synthétique, signaux de sécurité et tableaux de bord FinOps. Large catalogue d'intégrations. Point faible : le coût augmente rapidement avec le nombre de hosts et la cardinalité des métriques personnalisées.
- Dynatrace — L'analyse de cause racine pilotée par l'IA (Davis AI) est réellement utile pour les environnements complexes. Auto-instrumentation solide pour Java/.NET. Point faible : le modèle de licence peut manquer de transparence.
- Grafana Cloud (pile LGTM) — Grafana + Loki (logs) + Tempo (traces) + Mimir (métriques). Cœur open source avec option d'hébergement managé. Idéal pour les équipes voulant garder le contrôle et éviter le verrouillage fournisseur. Point faible : nécessite davantage d'expertise opérationnelle pour affiner et maintenir.
- New Relic — Offre gratuite généreuse, tarification à la consommation. Bon APM. Point faible : le monitoring réseau et la profondeur infrastructure sont en retrait par rapport à Datadog.
- Elastic Observability — Basé sur Elasticsearch. Pertinent si vous utilisez déjà la pile ELK pour le logging. Point faible : mettre à l'échelle les clusters Elasticsearch pour des métriques de haute cardinalité n'est pas trivial.
Pour les équipes sensibles aux coûts, la pile Grafana LGTM avec instrumentation OpenTelemetry offre le meilleur ratio contrôle/coût. Pour les équipes qui veulent du full-managé et acceptent d'en payer le prix, Datadog ou Dynatrace sont les choix pragmatiques.
Bonnes pratiques issues d'un NOC 24/7
Ce ne sont pas des recommandations théoriques. Elles découlent de patterns que nous observons sur des centaines de charges de travail supervisées.
1. Définissez les SLO avant de définir les alertes
Une alerte sans Service Level Objective est du bruit. Commencez par définir ce que « sain » signifie pour chaque service — par ex., « 99,9 % des requêtes de paiement aboutissent en moins de 800 ms avec un taux d'erreur <0,1 % ». Puis configurez les alertes sur le taux de consommation de ce budget d'erreur. Le livre SRE de Google a formalisé cette approche, et elle fonctionne. L'alerting multi-fenêtre et multi-taux de consommation (burn rate rapide pour les pages, burn rate lent pour les tickets) réduit considérablement la fatigue d'alerte.
2. Centralisez dans un pipeline d'observabilité unique
Dans les environnements multi-cloud, la plus grande perte de temps est le changement de contexte entre trois consoles différentes. Utilisez l'OpenTelemetry Collector comme routeur de télémétrie neutre : il reçoit métriques, traces et logs de n'importe quelle source et les exporte vers le(s) backend(s) de votre choix. Cela découple l'instrumentation du stockage et préserve vos options.
3. Monitorez le monitoring
Votre pipeline d'observabilité est lui-même de l'infrastructure. Si votre serveur Prometheus manque d'espace disque, ou si votre agent Datadog plante silencieusement, vous avez un angle mort au moment précis où vous avez besoin de visibilité. Exécutez un contrôle heartbeat/canari léger qui valide que votre pile de monitoring ingère bien des données. Nous exécutons des contrôles synthétiques toutes les 60 secondes qui poussent une métrique connue et alertent si elle n'arrive pas dans les 120 secondes.
4. Corrélez les coûts avec les métriques de performance
C'est là que Cloud FinOps rejoint le monitoring de performance. Une instance tournant à 8 % de CPU n'est pas un problème de performance — c'est un problème de coût. Une instance tournant à 92 % de CPU n'est pas un problème de coût — c'est un risque de fiabilité. Faire apparaître les deux dans le même tableau de bord permet aux équipes de prendre des décisions de dimensionnement avec le contexte complet. AWS Compute Optimizer, Azure Advisor et GCP Recommender fournissent des suggestions de dimensionnement natives, mais ils manquent de contexte applicatif. Superposez-les avec vos données APM pour obtenir des recommandations exploitables.
5. Gérez la rétention des logs de manière stratégique
Stocker tous les logs de debug de chaque conteneur pour l'éternité est le chemin le plus court vers une facture d'observabilité à six chiffres. Échelonnez votre rétention : stockage chaud (7-14 jours) pour le dépannage opérationnel, stockage tiède (30-90 jours) pour l'analyse de tendances, et stockage froid/archive pour la conformité. Le RGPD exige que les données personnelles dans les logs soient traitées avec la même rigueur que les données en base — masquez ou pseudonymisez les données à caractère personnel à la couche de collecte, pas après ingestion. Les exigences de journalisation de NIS2 pour les entités essentielles impliquent que vous ne pouvez pas non plus tout supprimer au bout de 7 jours. En France, les recommandations de la CNIL en matière de durée de conservation des logs (généralement 6 mois pour les logs de connexion et les journaux d'accès selon les directives CNIL/ANSSI) doivent également être respectées. Concevez vos politiques de rétention pour satisfaire à la fois les besoins opérationnels et réglementaires.
6. Instrumentez pour la performance régionale
Si vous servez des utilisateurs à la fois en France et dans d'autres géographies, monitorez depuis les deux régions. Un service performant mesuré depuis eu-west-3 (Paris) peut présenter 400 ms de latence supplémentaire lorsqu'il est accédé depuis ap-south-1 (Mumbai). Le monitoring synthétique avec des points de contrôle à Paris, Francfort, Mumbai et Bangalore vous donne la vérité du point de vue de l'utilisateur. Le NOC d'Opsio exécute des contrôles synthétiques depuis plusieurs géographies précisément parce que les dégradations régionales sont invisibles depuis un point d'observation unique.
Monitoring dans les environnements hybrides et multi-cloud
La plupart des entreprises ne sont pas mono-cloud, quelle que soit leur stratégie officielle. Selon le State of the Cloud de Flexera, l'adoption multi-cloud est restée le schéma dominant pendant plusieurs années consécutives. Le défi de monitoring se multiplie : les métriques portent des noms différents, ont des granularités différentes et des API différentes selon les fournisseurs.
Architecture pratique de monitoring multi-cloud
1. Couche de collecte : Déployez des OpenTelemetry Collectors dans chaque environnement (AWS, Azure, GCP, on-premises). Configurez-les pour normaliser les noms de métriques et ajouter des tags identifiant le fournisseur cloud.
2. Couche d'agrégation : Routez toute la télémétrie vers un backend central — Datadog, Grafana Cloud ou une pile Mimir/Loki/Tempo auto-hébergée.
3. Couche de corrélation : Utilisez des cartographies de services et des graphes de dépendances couvrant plusieurs fournisseurs. Une requête peut débuter sur un CDN Azure Front Door, atteindre une API tournant sur AWS EKS, et interroger une base de données sur GCP Cloud SQL. Sans trace cross-cloud, vous ne trouverez jamais le goulot d'étranglement.
4. Couche d'alerting : Alerting centralisé avec PagerDuty, Opsgenie ou Grafana OnCall comme point de routage unique. Évitez les silos d'alerting natifs — un Azure Action Group qui réveille une équipe pendant qu'un CloudWatch Alarm en réveille une autre engendre des efforts dupliqués et des corrélations manquées.
Spécificités du cloud hybride
Pour les charges de travail réparties entre on-premises et cloud (fréquent dans l'industrie, la santé et le secteur public en France), monitorez l'interconnexion comme un composant de première classe. Les circuits Direct Connect, ExpressRoute et Cloud Interconnect ont des SLA, mais ces SLA ne couvrent pas la sensibilité de votre application à la gigue. Implémentez des sondes de latence bidirectionnelles sur la liaison et alertez sur la dégradation avant qu'elle n'impacte le trafic réel.
Conformité et résidence des données
France et Europe : NIS2, RGPD et SecNumCloud
La directive NIS2, applicable depuis octobre 2024, exige des entités essentielles et importantes qu'elles mettent en œuvre des mesures de gestion des risques appropriées — ce qui inclut explicitement les capacités de monitoring et de détection d'incidents. Votre architecture de monitoring est auditable. Si vous ne pouvez pas démontrer que vous aviez une visibilité sur l'incident, la conversation avec le régulateur devient nettement plus difficile. En France, l'ANSSI est l'autorité nationale compétente pour NIS2, et ses recommandations en matière de journalisation et de détection doivent être prises en compte.
Le RGPD contraint l'endroit où les données de monitoring peuvent être stockées et traitées. Si vos logs applicatifs contiennent des adresses IP, des identifiants utilisateurs ou des jetons de session, ces logs sont des données à caractère personnel au sens du RGPD. Les envoyer vers un SaaS hébergé aux États-Unis sans mécanismes de transfert appropriés (clauses contractuelles types, décisions d'adéquation) constitue un risque de conformité — la CNIL a été particulièrement claire sur ce point. Choisissez des backends de monitoring offrant un traitement des données hébergé en UE, ou auto-hébergez dans des régions UE. Grafana Cloud propose des clusters dédiés UE ; Datadog propose le site EU1 (Francfort). Pour les charges de travail les plus sensibles — notamment dans le secteur public ou les opérateurs d'importance vitale (OIV) — envisagez des solutions qualifiées SecNumCloud par l'ANSSI, qui garantissent un hébergement et une opération souverains sur le territoire français.
Inde : DPDPA 2023
Le Digital Personal Data Protection Act (DPDPA) 2023 introduit des obligations de traitement des données basées sur le consentement et des exigences de localisation des données pour certaines catégories. Les données de monitoring contenant des identifiants personnels de ressortissants indiens doivent être traitées avec précaution. L'impact pratique : si vous monitorez des applications exposées aux utilisateurs servant des clients en Inde, assurez-vous que votre pipeline de masquage de logs supprime ou pseudonymise les données personnelles avant qu'elles ne quittent la couche de collecte.
Mettre en place le monitoring cloud : un parcours pratique
Pour les équipes en début de maturité de monitoring, voici une séquence concrète — pas un exercice exhaustif dès le départ :
Semaines 1-2 : Activez le monitoring natif pour toutes les ressources cloud. Activez le monitoring détaillé CloudWatch (intervalles d'1 minute), les diagnostics Azure Monitor ou GCP Cloud Monitoring. C'est généralement une ligne de Terraform/Bicep/Config Connector par ressource.
Semaines 3-4 : Instrumentez vos trois services les plus critiques avec OpenTelemetry. Déployez l'OTel Collector en sidecar (Kubernetes) ou en daemon (EC2/VM). Exportez traces et métriques vers le backend de votre choix.
Mois 2 : Définissez les SLO pour ces trois services. Implémentez un alerting basé sur la consommation du budget d'erreur. Connectez les alertes à PagerDuty ou Opsgenie avec des rotations d'astreinte.
Mois 3 : Ajoutez du monitoring synthétique depuis au moins deux localisations géographiques (par ex. eu-west-3 Paris et eu-central-1 Francfort). Établissez des tableaux de bord de référence. Commencez la centralisation des logs avec des niveaux de rétention.
En continu : Étendez l'instrumentation aux services restants. Ajoutez le monitoring réseau. Intégrez les données de coûts. Revoyez et ajustez les seuils d'alerte trimestriellement — des seuils obsolètes sont pires que l'absence de seuils, car ils entraînent les équipes à ignorer les alertes.
Moniteurs de machines virtuelles et performance cloud
Un moniteur de machine virtuelle (VMM), aussi appelé hyperviseur, est la couche logicielle qui gère l'allocation des ressources physiques — CPU, mémoire, stockage, réseau — aux machines virtuelles. Dans le cloud computing, l'hyperviseur (AWS Nitro, Azure Hyper-V, le KVM personnalisé de GCP) est le fondement qui rend le multi-tenancy possible. Du point de vue du monitoring, vous interagissez rarement directement avec l'hyperviseur sur le cloud public — le fournisseur l'abstrait. Mais vous observez ses effets : le « steal time » sur une instance Linux (la métrique %steal dans top ou sar) indique que l'hyperviseur alloue des cycles CPU à d'autres locataires. Si le steal time dépasse régulièrement 5-10 %, vous subissez des effets noisy-neighbor et devriez envisager des instances dédiées ou bare-metal.
Logging cloud vs. monitoring cloud : clarifier la relation
Logging et monitoring sont des disciplines distinctes mais interdépendantes. Le monitoring répond à « quelque chose dysfonctionne-t-il en ce moment ? » par des métriques temps réel et des alertes. Le logging répond à « que s'est-il exactement passé ? » par des enregistrements d'événements discrets. Les traces ajoutent la troisième dimension : « comment la requête a-t-elle traversé le système ? »
Le terme moderne « observabilité » unifie ces trois aspects — métriques, logs et traces — en une pratique cohérente. En termes d'outillage : CloudWatch Metrics + CloudWatch Logs + X-Ray ; Azure Monitor Metrics + Log Analytics + Application Insights ; GCP Cloud Monitoring + Cloud Logging + Cloud Trace. Ou, avec des piles tierces : Datadog Infrastructure + Logs + APM ; Grafana Mimir + Loki + Tempo.
Le conseil pratique : ne construisez pas le logging et le monitoring comme des projets séparés avec des équipes séparées. Ils partagent l'infrastructure, partagent le contexte, et sont interrogés ensemble lors de chaque incident.
Questions fréquentes
Comment mesure-t-on la performance cloud ?
On mesure la performance cloud à l'aide de la méthode RED (Rate, Errors, Duration) pour les services et de la méthode USE (Utilization, Saturation, Errors) pour l'infrastructure. L'instrumentation applicative s'appuie sur le tracing distribué (OpenTelemetry), la collecte des métriques d'infrastructure sur les agents natifs cloud, et l'établissement de baselines pour la latence p95, le taux d'erreur et la disponibilité. Le monitoring synthétique ajoute une validation de l'extérieur confirmant que les utilisateurs réels peuvent atteindre vos endpoints dans les seuils de SLA.
Quels sont les trois volets du monitoring cloud ?
Les trois volets sont le monitoring d'infrastructure (compute, stockage, santé réseau), le monitoring de la performance applicative (traces de transactions, taux d'erreur, temps de réponse) et la gestion/analyse des logs (agrégation centralisée, recherche et alerting). Certains référentiels ajoutent un quatrième volet — le monitoring de sécurité — mais en pratique les signaux de sécurité alimentent le même pipeline d'observabilité.
Qu'est-ce que la règle 3-4-5 en cloud computing ?
La règle 3-4-5 est une heuristique de sauvegarde et de reprise après sinistre : conservez 3 copies des données, sur 4 types de supports de stockage différents, dont 5 copies stockées hors site ou dans une autre région. Bien qu'il s'agisse à l'origine d'une directive de protection des données, elle impacte directement la conception du monitoring, car il faut vérifier en continu la santé de la réplication, la conformité RPO et la disponibilité du basculement régional.
Quels sont les cinq types de monitoring ?
Les cinq types couramment cités sont : le monitoring d'infrastructure, le monitoring de la performance applicative (APM), le monitoring réseau, le monitoring de sécurité (SIEM/SOC) et le monitoring utilisateur réel/synthétique. Dans un contexte cloud, ces types se recoupent fortement — un pic de latence peut être un problème réseau, un bug applicatif ou un effet noisy-neighbor sur une infrastructure partagée — ce qui explique pourquoi les plateformes d'observabilité unifiées remplacent les outils cloisonnés.
Quelle est la différence entre logging cloud et monitoring cloud ?
Le monitoring collecte des métriques de séries temporelles (CPU, latence, compteurs d'erreurs) et déclenche des alertes lorsque des seuils sont franchis. Le logging capture des enregistrements d'événements discrets — erreurs applicatives, logs d'accès, pistes d'audit — que l'on interroge a posteriori. En pratique, les deux sont complémentaires : une alerte se déclenche sur une métrique de monitoring, et les ingénieurs pivotent vers les logs pour diagnostiquer la cause racine. L'observabilité moderne unifie métriques, logs et traces dans un workflow unique.
