Qu'est-ce que le Cloud Monitoring ?

Qu'est-ce que le cloud monitoring ?

Le cloud monitoring (surveillance du cloud) est la collecte et l'examen continus de métriques, de logs, de traces et d'événements issus des charges de travail et des services managés exécutés sur un cloud public comme AWS, Google Cloud ou Azure, ou sur un environnement hybride. Ces données alimentent des tableaux de bord, des alertes et des processus d'incident : l'équipe sait quand un service est en panne, lent ou plus coûteux que prévu, et par où commencer.

Cloud monitoring, surveillance on-premise et APM

• Le cloud monitoring lit les sources natives du fournisseur (CloudWatch, Google Cloud Monitoring, Azure Monitor, métriques des répartiteurs de charge et des bases de données) et s'accommode d'un calcul éphémère comme les conteneurs et les fonctions. Les étiquettes (compte, région, service, environnement) pilotent le regroupement, car chaque hôte change sans cesse.
• La surveillance on-premise suit du matériel fixe, en général avec des agents par hôte et des protocoles comme SNMP.
• La surveillance des performances applicatives (APM) instrumente votre code et rapporte latence et erreurs par endpoint, où qu'il s'exécute.

La plupart des équipes cloud ont besoin des deux ensemble : le cloud monitoring pour l'infrastructure, l'APM pour l'application. L'observabilité est la pratique plus large qui consiste à exploiter tous ces signaux pour enquêter sur des problèmes imprévus.

Ce que couvre le cloud monitoring

• Calcul : CPU, mémoire et disque des machines virtuelles ; nombre de conteneurs, redémarrages et pods en attente.
• Services managés : connexions et latence de la base de données, taux de succès et évictions du cache, profondeur des files, erreurs du stockage d'objets, temps de réponse des cibles du répartiteur de charge.
• Serverless : invocations de fonctions, durée, erreurs, limitations et concurrence.
• Réseau et bordure : taux de succès du CDN, trafic NAT et VPC, volume de requêtes DNS.
• Coûts : dépense quotidienne par compte, service ou étiquette, avec alerte en cas de hausse brutale. Le volet des règles est traité dans gouvernance du cloud.
• Sécurité et audit : événements du journal d'audit et détections de menaces, comme alerte précoce et non comme remplaçant d'un outil de sécurité.

Métriques clés du cloud monitoring

1. Disponibilité par service : nombre de cibles saines, état de l'instance, agrégés sur l'objectif promis aux utilisateurs.
2. Latence par composant : temps de réponse du répartiteur de charge à p50, p95 et p99, latence des requêtes de base de données.
3. Taux d'erreurs par couche : compteurs 5xx au répartiteur de charge, erreurs de fonctions, profondeur de la file de lettres mortes.
4. Saturation : CPU et crédits sur les instances à performances variables, utilisation des connexions de base de données, évictions du cache, groupe d'autoscaling souhaité contre en service.
5. Débit : requêtes par seconde par service, messages par minute dans les files et flux.
6. Coût par requête : dépense divisée par le travail utile, une mesure d'efficacité à long terme.

Comment mettre en place le cloud monitoring

Commencez par les métriques natives du fournisseur et envoyez-les à un endroit que vous consulterez vraiment : la console du fournisseur ou un backend central comme Grafana ou Datadog. Étiquetez chaque ressource de façon cohérente (service, environnement, équipe, centre de coût) pour qu'une même requête de tableau de bord puisse segmenter selon chacune. Ajoutez ensuite logs et traces. Dirigez les alertes vers un outil d'astreinte, une rotation par service, et alertez d'abord sur les symptômes ressentis par les utilisateurs (erreurs, latence) avant les causes (CPU). Passez régulièrement en revue métriques et alertes et supprimez celles que personne ne gère : la plupart des fournisseurs facturent les métriques personnalisées et le volume de logs.

Les tableaux de bord du cloud ne montrent que ce qui se passe dans votre compte. La surveillance synthétique vérifie le service de l'extérieur, comme y accède un utilisateur, et la surveillance d'API fait de même pour les endpoints. La surveillance d'API de LoadFocus vérifie codes de statut, corps de réponse et latence selon un calendrier depuis 25 régions cloud, avec des alertes par e-mail, Slack, Microsoft Teams, PagerDuty et d'autres canaux. Pour savoir quoi surveiller et sur quoi alerter, lisez les bonnes pratiques de surveillance pour les équipes DevOps.

Cloud monitoring et tests de charge

La surveillance dit comment le système se comporte aujourd'hui. Les tests de charge et les tests de pic montrent comment il réagit à un trafic encore jamais vu. Lancez le test depuis l'extérieur de votre réseau, observez les tableaux de bord cloud pendant l'exécution et notez quel composant sature en premier : connexions de base de données, retard de l'autoscaling ou profondeur de file. Les tests de charge de LoadFocus exécutent des tests JMeter, k6 et sans code depuis 25 régions cloud, de sorte que les horodatages d'une exécution coïncident avec vos tableaux de bord.

Erreurs fréquentes en cloud monitoring

• Des étiquettes incohérentes. Les ressources sans étiquette disparaissent de tous les tableaux de bord filtrés et des rapports de coûts.
• Alerter sur toutes les métriques. Les alertes bruyantes finissent coupées. Alertez sur les symptômes visibles des utilisateurs et gardez le reste en tableaux de bord.
• Ne surveiller que de l'intérieur. Un tableau de bord au vert ne prouve pas que les utilisateurs atteignent le service.
• Seulement des moyennes. Une bonne latence moyenne peut cacher une longue traîne lente. Regardez les centiles.
• Oublier la facture de surveillance. L'ingestion de logs et les métriques personnalisées gonflent discrètement. Passez-les en revue.

Questions fréquentes : cloud monitoring

Quelle différence entre cloud monitoring et observabilité ?

Le cloud monitoring surveille des signaux connus et alerte quand ils franchissent un seuil. L'observabilité est la capacité de poser de nouvelles questions à vos métriques, logs et traces lorsqu'une panne inattendue survient. La surveillance l'alimente.

La surveillance intégrée du fournisseur suffit-elle ?

C'est le bon point de départ et, avec un seul cloud, elle peut suffire. On ajoute en général une vérification externe, car les outils du fournisseur voient l'intérieur du compte mais pas ce que vit un utilisateur dans une autre région, ainsi qu'un backend central dès que l'on utilise plusieurs clouds.

Sur quoi alerter en premier ?

Sur la disponibilité et le taux d'erreurs du service exposé aux utilisateurs, puis sur les centiles de latence, puis sur la saturation des ressources partagées en arrière-plan, comme les connexions de base de données et les files.

Le cloud monitoring remplace-t-il l'APM ?

Non. Le cloud monitoring montre la santé de l'infrastructure et des services managés. L'APM montre quel endpoint ou quel chemin de code est lent. Ils répondent à des questions différentes.

Comment limiter le coût du cloud monitoring ?

Étiquetez les ressources pour savoir qui possède quoi, supprimez les métriques et logs que personne ne lit, définissez des durées de rétention et évitez les étiquettes à forte cardinalité sur les métriques personnalisées.