Le monitoring d’une infrastructure virtualisée ne consiste plus à vérifier qu’un hyperviseur répond au ping. Les incidents les plus coûteux apparaissent souvent dans les zones grises : une latence de stockage qui progresse lentement, une contention CPU ponctuelle masquée par des moyennes, une mémoire surallouée sans pression visible à court terme, ou un cluster HA dont la capacité de basculement ne correspond plus au risque réel. Entre une stack Prometheus et Grafana, des exporteurs adaptés à vSphere ou Proxmox, et VMware Aria Operations, le choix dépend moins d’une liste de fonctionnalités que des compétences disponibles, du budget et du niveau d’intégration attendu.

Deux philosophies : plate-forme composable ou produit intégré

Prometheus et Grafana forment une approche modulaire. Prometheus collecte et stocke des métriques de séries temporelles, tandis que Grafana fournit l’exploration, les tableaux de bord et l’alerting. L’infrastructure virtualisée est exposée via des exporteurs : vmware_exporter ou un collecteur s’appuyant sur les API vCenter pour VMware, et pve-exporter ou des variantes similaires pour Proxmox VE.

Cette architecture présente plusieurs caractéristiques importantes :

À l’inverse, VMware Aria Operations adopte une approche intégrée, centrée sur l’écosystème VMware. La plate-forme collecte les objets vCenter, les relations entre clusters, hôtes, datastores, VM et pools de ressources, puis propose des analyses de capacité, des alertes contextualisées et des mécanismes de corrélation. L’objectif n’est pas seulement d’afficher une métrique brute, mais d’identifier les objets affectés et de qualifier le risque : saturation, sous-dimensionnement, déséquilibre de charge ou perte de résilience.

Le compromis est classique. Une stack open source donne plus de liberté et peut couvrir un périmètre très large. Aria Operations réduit la phase de modélisation pour les environnements VMware, mais implique un coût de licence et un cadre fonctionnel plus prescriptif.

Construire une stack Prometheus pour vSphere ou Proxmox

Dans une architecture Prometheus, le point de départ consiste à distinguer trois plans de supervision :

  1. la disponibilité des composants ;
  2. les performances et la capacité ;
  3. les événements et la santé logique de la plate-forme.

Pour vSphere, l’exporteur interroge généralement vCenter plutôt que chaque ESXi individuellement. C’est la méthode la plus simple pour récupérer les objets inventoriés, les compteurs de performance et certaines informations sur les clusters. Il faut toutefois contrôler la fréquence de collecte et le volume de métriques : une infrastructure contenant plusieurs milliers de VM peut produire une cardinalité importante.

Un exemple simplifié de cible Prometheus pour un exporteur vSphere :

scrape_configs:
  - job_name: vmware
    metrics_path: /metrics
    static_configs:
      - targets:
          - vmware-exporter:9272

Dans la pratique, la configuration de l’exporteur contient les accès vCenter, les collecteurs activés et, idéalement, des filtres limitant les objets non pertinents. Un compte de service dédié, en lecture seule, doit être utilisé. Les identifiants ne doivent pas figurer en clair dans un dépôt Git : secrets Kubernetes, Vault, Ansible Vault ou mécanisme équivalent sont préférables. Pour aller plus loin, consultez Aria Operations for Logs pour la centralisation des journaux.

Pour Proxmox VE, les exporteurs s’appuient sur l’API REST et peuvent récupérer les statistiques des noeuds, VM, conteneurs, stockages, tâches et états de cluster. Là encore, un jeton API à droits minimaux est préférable à un compte administrateur. Les métriques du système hôte restent souvent collectées par node_exporter, ce qui complète les données remontées par l’API Proxmox.

La valeur de Prometheus apparaît lorsque les données sont croisées. Un dashboard ne doit pas isoler une VM de son contexte : il doit permettre de voir le noeud d’hébergement, le datastore ou pool de stockage, le cluster, la consommation réseau et, si possible, les métriques applicatives.

Une organisation typique peut inclure :

Le principal piège est de confondre collecte exhaustive et supervision utile. Exporter toutes les dimensions disponibles pour chaque VM, disque virtuel, interface et datastore peut dégrader Prometheus et rendre Grafana illisible. Il faut définir les métriques nécessaires à l’exploitation avant de multiplier les labels.

Tableaux de bord Grafana : partir des symptômes, pas des objets

Grafana devient réellement utile lorsqu’il structure l’investigation. Un tableau de bord uniquement composé de jauges vertes et rouges rassure, mais n’aide pas lors d’une dégradation progressive.

Un tableau de bord Grafana centralise les métriques d'infrastructure.
Un tableau de bord Grafana centralise les métriques d'infrastructure.

Un premier niveau doit fournir une vue de service :

Un deuxième niveau cible les clusters. Il doit montrer les ressources allouées, consommées et disponibles, mais aussi les indicateurs de contention. Pour VMware, CPU ready time, co-stop pour les VM SMP, mémoire balloonée, swapping hôte et consommation active sont souvent plus révélateurs que la seule utilisation CPU ou RAM. Pour Proxmox, la charge des noeuds, la pression mémoire, le swap, le taux d’I/O wait et les statistiques Ceph ou ZFS sont des indicateurs essentiels selon l’architecture.

Un troisième niveau cible le stockage. La latence est plus importante que le seul débit. Une baie peut fournir beaucoup de Mo/s tout en présentant une latence pénalisante pour des charges transactionnelles. Il faut distinguer :

Dans vSphere, les métriques de latence doivent être interprétées avec prudence selon le type de stockage : VMFS, NFS, vSAN ou volumes présentés par une baie externe. Une hausse de latence peut provenir de la VM, de l’hôte, du réseau de stockage ou de la baie. Le dashboard doit donc conserver une navigation depuis la VM vers le datastore, puis vers l’hôte et, si les métriques existent, vers le contrôleur de stockage.

Une règle PromQL illustrative peut détecter une latence moyenne élevée sur une période courte :

avg_over_time(vmware_vm_disk_latency_milliseconds[10m]) > 20

Le nom exact de la métrique dépend de l’exporteur choisi. La logique compte davantage que l’expression brute : il faut déclencher une alerte sur une durée significative, avec un seuil adapté au type de charge, puis inclure dans la notification les labels permettant d’identifier la VM, le datastore et le cluster concernés.

VMware Aria Operations : contexte, capacité et corrélation native

VMware Aria Operations est pertinent lorsque vSphere constitue le cœur de l’infrastructure et que l’équipe recherche une visibilité opérationnelle immédiatement exploitable. La plate-forme connaît nativement les objets VMware et leurs dépendances. Elle peut notamment fournir :

La différence avec Grafana est souvent dans la sémantique. Grafana affiche très bien les métriques que l’on lui fournit, mais l’équipe doit définir les modèles de diagnostic, les relations d’objets et les règles de décision. Aria Operations embarque une part plus importante de cette logique, particulièrement utile pour analyser un cluster DRS, un déséquilibre de ressources ou le risque de capacité HA. Pour aller plus loin, consultez la sécurisation d’un cluster.

La santé du cluster HA ne doit pas être réduite à la disponibilité de tous les hôtes. Une infrastructure peut être techniquement verte tout en ayant perdu sa capacité à absorber la panne d’un hôte. Les éléments à surveiller incluent :

Aria Operations peut faciliter ce diagnostic en présentant le risque au niveau du cluster. Dans une stack Prometheus, la même visibilité est possible, mais elle nécessite d’exposer les métriques adéquates et de construire les règles de calcul. Ce n’est pas un défaut intrinsèque : pour une équipe SRE ou plateforme mature, cette maîtrise peut être précisément l’objectif.

CPU, mémoire et stockage : les métriques qui comptent réellement

La surveillance de l’utilisation moyenne reste nécessaire, mais elle est insuffisante. Une VM peut afficher 30 % de CPU moyen tout en subissant de fortes périodes de CPU ready. De même, un hôte peut disposer de mémoire libre tout en rencontrant une pression liée à une surallocation mal répartie.

Pour le CPU, les indicateurs prioritaires sont :

Un CPU ready élevé n’a pas de seuil universel. Il faut l’interpréter avec la taille de la VM, la fréquence des pointes et le profil applicatif. Une VM avec 16 vCPU peut souffrir d’une difficulté de planification que ne révèle pas une simple moyenne d’utilisation. Réduire le nombre de vCPU peut parfois améliorer les performances, à condition de mesurer avant et après.

Une alerte de supervision bien calibrée évite l'incident.
Une alerte de supervision bien calibrée évite l'incident.

Pour la mémoire, il faut distinguer :

Le ballooning n’est pas nécessairement une panne, mais il indique que l’hyperviseur commence à arbitrer la mémoire. Le swap côté hôte est beaucoup plus critique, car son impact sur les performances peut être très important. Dans Proxmox, la pression mémoire et le swap sur les noeuds doivent être mis en relation avec les limites, ballooning QEMU et la politique de surallocation.

Pour le stockage, les indicateurs fondamentaux sont :

Dans un environnement Ceph, surveiller seulement la capacité brute est insuffisant. Les états HEALTH_WARN, les objets dégradés, les PG bloqués, la latence des OSD, le taux de récupération et la répartition des données doivent être intégrés au monitoring. Un pool presque vide peut être plus dangereux qu’un cluster CPU chargé, car l’effet peut se propager à de nombreuses VM.

Choisir selon le budget, les compétences et le périmètre

Le coût d’une stack open source n’est pas nul. Les licences peuvent être absentes, mais il reste le temps d’intégration, la maintenance des exporteurs, la gestion des mises à jour, l’observabilité de la plate-forme de monitoring elle-même et la conception des dashboards. Il faut aussi prévoir la haute disponibilité de Prometheus ou une architecture de stockage distribué si le monitoring devient critique.

Prometheus et Grafana sont particulièrement adaptés lorsque :

Aria Operations est souvent préférable lorsque :

Une approche hybride est fréquente et raisonnable. Aria Operations peut rester l’outil principal pour l’analyse vSphere, tandis que Prometheus et Grafana assurent la corrélation avec les applications, les services Kubernetes, les équipements réseau, les sauvegardes et les métriques métiers. Dans ce modèle, il faut éviter de dupliquer toutes les alertes dans deux outils. Définissez clairement la source d’autorité : par exemple, Aria Operations pour la capacité VMware et Prometheus pour les SLO applicatifs et l’infrastructure transverse. Pour aller plus loin, consultez l’administration quotidienne d’ESXi.

Rendre les alertes exploitables

Une alerte utile doit décrire une condition durable, un impact probable et une action possible. Une règle du type « CPU > 80 % » génère souvent du bruit. Une alerte plus pertinente combine durée, contention et contexte.

Exemple de logique opérationnelle :

Alerter si :
- la latence d'écriture dépasse 25 ms pendant 15 minutes ;
- au moins cinq VM du même datastore sont concernées ;
- la tendance est en hausse sur la dernière heure.

Inclure :
- datastore ou pool ;
- hôtes concernés ;
- VM les plus touchées ;
- lien vers le dashboard ;
- procédure de vérification de la baie et du réseau de stockage.

La même logique s’applique au HA. Une alerte « hôte indisponible » est nécessaire, mais insuffisante. Une alerte « capacité de basculement non garantie après la mise en maintenance d’un hôte » est souvent plus utile, car elle permet d’agir avant l’incident.

Enfin, le monitoring doit être testé comme un service de production. Vérifiez que les exporteurs remontent bien les métriques attendues, que les alertes arrivent au bon canal, que les dashboards restent utilisables sous charge et que la rétention est conforme aux besoins d’analyse. Une plate-forme de supervision qui tombe pendant un incident de stockage ne doit pas devenir une dépendance aveugle.