Monitoring VMware vSpheresans toucher à une seule VM
Un agent Glouton, sur une machine Linux ou Windows, dialogue avec votre API vSphere via un compte en lecture seule et découvre tout le parc : clusters, hôtes ESXi, machines virtuelles et datastores. Rien n'est installé dans les VM — ce qui est généralement la raison pour laquelle une équipe VMware refuse la supervision au départ.
vCenter ou ESXi standalone • Compte vSphere en lecture seule • Objets découverts facturés à partir de 3,99 €/mois pièce
Vue d'ensemble
L'objection ne porte jamais sur les métriques
Personne ne discute le fait qu'il faut superviser les hôtes ESXi. La discussion porte sur ce que ça coûte d'y arriver : un paquet sur trois cents VM, une exception dans l'image de référence, une demande de changement par VM, et un parc dont la moitié des machines sont des appliances auxquelles vous n'avez de toute façon pas le droit de toucher.
Bleemeo lit vSphere de la manière dont vSphere s'attend à être lu. Vous installez un agent Glouton sur n'importe quelle machine Linux ou Windows qui atteint vCenter, vous lui donnez un compte vSphere en lecture seule, et il parcourt l'inventaire : chaque cluster, chaque hôte, chaque VM, chaque datastore. Les nouveaux objets apparaissent dans les minutes qui suivent leur création, parce que la découverte tourne en continu et non lors d'une synchronisation nocturne.
Là où vous voulez le détail interne — CPU par processus, services découverts, logs — vous installez l'agent dans cette VM, et il arrive dans le même compte et les mêmes tableaux de bord. C'est un ajout, pas un prérequis.
Couverture
Ce qui est découvert
Quatre types d'objets, parcourus depuis l'inventaire vCenter. Les hôtes ESXi standalone fonctionnent pareil, sans le cluster. Clusters, hôtes et VM sont chacun une ressource facturée ; les datastores ne le sont pas.
Clusters
CPU et mémoire agrégés sur tous les hôtes du cluster, pour voir la pression au niveau où vous planifiez réellement la capacité.
- CPU utilisé sur l'ensemble du cluster
- Mémoire utilisée, en pourcentage
- Recalculé quand un hôte entre ou sort
Hôtes ESXi
Onze métriques par hôte, dont les deux compteurs qui comptent pour le taux de consolidation et qu'on perd facilement de vue : combien de VM tournent et combien sont arrêtées.
- CPU, mémoire totale et utilisée
- Swap in et swap out
- Débit disque en lecture et écriture
- Réseau émis et reçu
- Nombre de VM démarrées et arrêtées
Machines virtuelles
Neuf métriques par VM sans agent à l'intérieur — dont la latence CPU, qui permet de distinguer une VM lente d'un hôte sur-souscrit.
- CPU utilisé et latence CPU
- Mémoire utilisée et swap
- Débit disque en lecture et écriture
- Réseau émis et reçu
- Utilisation des systèmes de fichiers
Datastores
Capacité et E/S par datastore : un datastore qui se remplit devient une date dans le rapport hebdomadaire, pas une surprise au moment d'un snapshot.
- Espace utilisé et total
- Débit en lecture et écriture
- Alimente la prévision de capacité
Mise en place
Trois étapes, une machine
L'agent peut tourner partout où vCenter est joignable — une VM d'administration, un rebond, un conteneur. Plusieurs vCenter et hôtes ESXi peuvent être listés côte à côte.
Créer un compte vSphere en lecture seule
Le compte a besoin d'un accès en lecture aux objets à superviser : datacenter, cluster, hôtes, VM, datastores. La lecture seule suffit, et c'est toute l'histoire des permissions — il n'y a rien à accorder au-delà.
Installer un agent Glouton
Sur n'importe quelle machine Linux ou Windows qui atteint l'API vSphere. Une commande sous Linux, un installeur sous Windows. Cette machine est un collecteur, pas une cible : elle n'a pas besoin d'être dans le cluster.
Ajouter la connexion à sa configuration
Quelques lignes dans un fichier drop-in indiquant l'URL du vCenter ou de l'ESXi et le compte. Ajoutez d'autres entrées pour d'autres vCenter. La découverte démarre immédiatement et les tableaux de bord se remplissent au fil du parcours de l'inventaire.
Migration
Vous quittez VMware ? Vous ferez tourner les deux un moment
Les changements de licence ont mis beaucoup d'équipes sur la route de Proxmox, Nutanix ou de KVM tout court. Ces migrations durent six à dix-huit mois, et pendant tout ce temps vous exploitez deux hyperviseurs, deux consoles et une seule astreinte qui doit couvrir les deux.
Bleemeo couvre les deux côtés sans changer d'outil en cours de route. vSphere est lu par son API, et un hôte Proxmox VE est une machine Debian : le même agent qui supervise votre parc Linux supervise le nouvel hyperviseur — même compte, mêmes tableaux de bord, mêmes règles d'alerte, même rapport hebdomadaire. Migrer d'hyperviseur est assez perturbant sans migrer aussi sa supervision.
Les deux côtés, un seul tableau de bord
Une application répartie entre des VM ESXi et des VM Proxmox pendant une migration peut tenir derrière un seul tag applicatif : la vue de santé ne se fragmente donc pas le long de la frontière de migration.
Proxmox VE et Backup Server
Les deux sont basés sur Debian : l'agent s'installe depuis notre dépôt APT en une commande — Proxmox VE 7, 8 et 9, et toutes les versions de Proxmox Backup Server. Vous obtenez CPU, mémoire, disque, réseau et systèmes de fichiers de l'hôte, ainsi que les services qui y tournent.
Chaque VM garde son propre détail
Côté VMware, le détail par VM est optionnel puisque l'API le fournit. Côté Proxmox, les métriques par VM viennent de l'installation de l'agent dans les VM qui vous intéressent — le même agent, donc rien de nouveau à apprendre.
La comparaison reste honnête
Avant et après une migration, vous regardez les mêmes noms de métriques sur les mêmes graphiques avec la même rétention. C'est ce qui fait de « la nouvelle plateforme est-elle vraiment meilleure ? » une question à laquelle on répond avec des données.
Comparaison
vCenter seul vs vCenter via Bleemeo
| Feature | vCenter seul | Bleemeo |
|---|---|---|
| Métriques d'inventaire vSphere | Complètes, natives | Lues via l'API vSphere, même source |
| Agents dans les VM | Pas nécessaires | Pas nécessaires |
| Infrastructure hors VMware | Hors périmètre | Bare metal, cloud, conteneurs, Kubernetes |
| Historique | Agrégé agressivement au-delà de quelques jours | 13 mois en pleine résolution |
| Alerting | Alarmes vCenter, par objet | Défauts pré-construits, Slack, PagerDuty, SMS |
| Prévision de capacité | Manuelle, ou produit séparé | Une date par datastore et par disque |
| Pendant une migration d'hyperviseur | Couvre le côté que vous quittez | Couvre les deux côtés à la fois |
| Accès requis | Administrateur, en pratique | Un compte vSphere en lecture seule |
Questions fréquentes
La supervision vSphere avec Bleemeo, en pratique
Dois-je installer un agent dans mes machines virtuelles ?
Non. Un agent Glouton, sur une machine qui atteint vCenter, suffit à découvrir et superviser chaque cluster, hôte, VM et datastore. Installer l'agent dans une VM est optionnel et vous apporte ce que seule la VM sait : CPU et mémoire par processus, services découverts comme MySQL ou Nginx, et logs.
Quelles permissions vSphere Bleemeo demande-t-il ?
Des permissions en lecture seule sur les objets à superviser — datacenter, cluster, hôtes, VM, datastores. C'est la totalité du besoin. L'agent lit l'inventaire et les compteurs de performance ; il ne peut rien démarrer, migrer, reconfigurer ni supprimer.
Cela fonctionne-t-il sans vCenter ?
Oui. Glouton se connecte à un hôte ESXi standalone exactement comme à un vCenter. Vous perdez l'objet cluster, puisqu'il n'y a pas de cluster, et tout le reste fonctionne. Vous pouvez aussi lister plusieurs vCenter et plusieurs hôtes standalone dans la même configuration.
À quelle vitesse les nouvelles VM sont-elles prises en compte ?
En quelques minutes. La découverte tourne en continu plutôt qu'en synchronisation nocturne : une VM créée ce matin est sur un tableau de bord ce matin — ce qui compte quand le parc bouge.
Qu'est-ce que la latence CPU et pourquoi est-ce important ?
C'est la part du temps où une VM était prête à s'exécuter mais attendait un CPU physique. Une VM peut afficher une consommation CPU modeste et être lente parce que l'hôte est sur-souscrit : la latence CPU est ce qui distingue les deux cas. Bleemeo la collecte par VM, et « l'appli est lente » cesse d'être un débat entre l'équipe applicative et l'équipe plateforme.
Nous migrons de VMware vers Proxmox. Est-ce que ça marche ?
Oui, et c'est une bonne raison de migrer la supervision en premier. vSphere est lu par son API ; un hôte Proxmox VE est du Debian, donc le même agent s'installe depuis notre dépôt APT — Proxmox VE 7, 8 et 9, et Proxmox Backup Server. Pendant la migration, les deux côtés remontent dans un seul compte avec les mêmes tableaux de bord et les mêmes alertes : vous ne changez pas de supervision en changeant d'hyperviseur.
Comment le monitoring vSphere est-il facturé ?
Chaque cluster, hôte et machine virtuelle découvert est une ressource surveillée, tarifée comme les autres : 4,99 € par mois en Professional et 3,99 € en Starter. Les datastores ne sont pas facturés.
Sur un grand parc, cela s'additionne, et l'agent prévoit le levier : avec skip_monitor_vms, Glouton ne surveille que les clusters, les hôtes et les datastores. Vous gardez le décompte des VM démarrées et arrêtées au niveau de l'hôte, et vous cessez de payer par VM. Voir les tarifs pour le tableau complet.
Quels forfaits incluent le monitoring VMware ?
La supervision vSphere est disponible sur les forfaits Starter et Professional. Voir les tarifs pour le détail.