Pratiquement tous les éditeurs proposent des outils de monitoring inclus dans leurs produits. Là où ca devient plus compliqué, c’est lorsque l’on souhaite centraliser ces données dans une même interface. Heureusement des outils Open Sources tels que Grafana, InfluxDB, Graphite ou Telegraf existent et vont nous permettre d’atteindre ce but (moyennant un peu d’huile de coude quand même…). Je vous propose dans cet article de voir comment il est possible d’exporter les statistiques de performance d’un cluster VMware vSAN dans une base de données InfluxDB. Ces données pourront par la suite être mises sous forme de graphique dans Grafana.
L’agent de collecte Telegraf ne sachant pas nativement récupérer les statistiques d’un cluster vSAN, nous allons détailler plus particulièrement l’utilisation de l’utilitaire vsanmetrics qui permet d’extraire des statistiques d’utilisation et de performance et va ensuite les traduire dans un format que peut interpréter Telegraf.
Infrastructure de monitoring
Voyons comment vont cohabiter les différents éléments de l’infrastructure de monitoring. Telegraf va, toutes les 5 minutes, executer vsanmetrics pour collecter les données du cluster vSAN. Telegraf va ensuite stocker ces données dans une base InfluxDB. Grafana va venir chercher les données dans la base InfluxDB puis les presenter sous forme de graphiques aux utilisateurs.
Ca devrait ressembler à quelque chose comma ça:
Nous ne détaillerons pas comment installer l’ensemble des briques, vous retrouverez toutes les informations nécessaire dans mon précédent article Centraliser les métriques d’un serveur Windows grace à Telegraf, InfluxDB et Grafana. A la différence de ce qui est présenté dans l’article, nous partirons du principe que Telegraf est installé sur le même serveur que Grafana et InfluxDB.
Prérequis et remarques préalables à l’utilisation de vsanmetrics
- Cela parait évident mais cela ne coute rien de le rappeler, il vous faut disposer d’un Cluster VMware vSAN ou Dell EMC VxRail…
- Vsanmetrics va se connecter au vCenter via un compte utilisateur. l’identifiant et mot de passe du compte apparaissant en claire dans le fichier de configuration de Telegraf, je vous conseille fortement de créer un compte dédié au monitoring et n’ayant que des droits en lecture.
- Même si l’article a été rédigé alors que la version 0.2.0 de vsanmetrics était disponible, il est probable qu’une version plus récente soit téléchargeable au moment ou vous lirez ces lignes. Je mettrai à jour l’article si les nouvelles versions venait à changer la façon d’utiliser l’utilitaire.
- Python doit être installé sur votre serveur et les librairies vSphere et vSAN doivent êtres aussi disponibles. Vous pouvez vous referer à l’article Python, vSphere, vSAN et moi pour savoir comment procéder.
- Une liste des différentes métriques disponibles via l’API vSAN est disponible dans l’article Le service de performance vSAN
vsanmetrics dans le détail
vsanmetrics est un outil développé par votre serviteur en Python. Son but est d’interroger le vCenter via les API pour en extraire des statistiques d’utilisation et de performance vSAN. Une fois les données collectées, elles sont misent en forme au format InfluxDB line protocol pour pouvoir par la suite être envoyées par Telegraf dans la base de données InfluxDB.
L’utilitaire est téléchargable sur GitHub. Il fonctionne de la même manière quelque soit l’OS. Nous utiliserons pour les tests une distribution Ubuntu 17.10. Une fois téléchargé il faut rendre le script vsanmetrics.py
executable et accessible avec les commandes suivantes (libre à vous de les adapter suivant vos habitudes):
% chmod +x vsanmetrics.py
Validons que l’utilitaire est accessible avec la commande vsanmetrics -h
qui devrait afficher les parametres disponibles.
% ./vsanmetrics -h usage: vsanmetrics.py [-h] -s VCENTER [-o PORT] -u USER [-p PASSWORD] -c CLUSTERNAME [--performance] [--capacity] [--skipentitytypes SKIPENTITYTYPES] Export vSAN cluster performance and storage usage statistics to InfluxDB line protocol optional arguments: -h, --help show this help message and exit -s VCENTER, --vcenter VCENTER Remote vcenter to connect to -o PORT, --port PORT Port to connect on -u USER, --user USER User name to use when connecting to vcenter -p PASSWORD, --password PASSWORD Password to use when connecting to vcenter -c CLUSTERNAME, --cluster_name CLUSTERNAME Cluster Name --performance Output performance metrics --capacity Output storage usage metrics --skipentitytypes SKIPENTITYTYPES List of entity types to skip. Separated by a comma
Essayons maintenant de nous connecter à un cluster vSAN. Munissez-vous des identifiants d’un compte ayant à minima des droits de lecture et tapez la commande ci-dessous. Il vous faudra spécifier quels types de métriques vous souhaitez récupérer en utilisant les arguments --performance
et --capacity
:
./vsanmetrics.py -s vcenter.example.com -u [email protected] -p MyAwesomePassword -c VSAN-CLUSTER --capacity --performance
Si tout se passe bien, vous devriez voir des données apparaitre. Cela devrait ressembler à quelque chose comme ça:
capacity_global,scope=global,vcenter=vcenter.example.com,cluster=VSAN-CLUSTER totalCapacityB=7200999211008,freeCapacityB=1683354550260 1525422314084382976 capacity_summary,scope=summary,vcenter=vcenter.example.com,cluster=VSAN-CLUSTER temporaryOverheadB=0,physicalUsedB=2636212338688,primaryCapacityB=2688980877312,usedB=5380734189568,reservedCapacityB=3607749040540,overReservedB=2744521850880,provisionCapacityB=6986210377728,overheadB=2828663783436 1525422314084382976 capacity_vmswap,scope=vmswap,vcenter=vcenter.example.com,cluster=VSAN-CLUSTER temporaryOverheadB=0,physicalUsedB=8422162432,primaryCapacityB=177330978816,usedB=355240771584,reservedCapacityB=355089776640,overReservedB=346818609152,overheadB=177909792768 1525422314084382976 capacity_checksumOverhead,scope=checksumOverhead,vcenter=vcenter.example.com,cluster=VSAN-CLUSTER temporaryOverheadB=0,physicalUsedB=0,primaryCapacityB=0,usedB=8858370048,reservedCapacityB=0,overReservedB=0,overheadB=8858370048 1525422314084382976
Félicitation, tout fonctionne ! On peut passer à l’étape suivante.
Configuration d’InfluxDB
Nous allons devoir créer une base de données pour stocker les métriques puis configurer une durée de rétention pour éviter de saturer la base.
En etant connecté à votre serveur, lancez l’utilitaire ‘influx’
% influx Connected to http://localhost:8086 version 1.3.5 InfluxDB shell version: 1.3.5 >
Créez la base VSAN
> CREATE DATABASE VSAN
Configurez une durée de rétention de 12 semaines (environs 3 mois) pour les données stockées dans la base VSAN
> CREATE RETENTION POLICY "douze_semaines" ON "VSAN" DURATION 12w REPLICATION 1 DEFAULT
vsanmetrics et Telegraf
Rentrons maintenant un peu plus dans le vif du sujet. Nous allons configurer Telegraf pour qu’il execute vsanmetrics à interval régulier. Pour ce faire nous allons éditer le fichier de configuration de Telegraf (telegraf.conf), configurer le plugin par défaut [[outputs.influxdb]]
pour qu’il envoie les données dans la base InfluxDB et rajouter un plugin [[inputs.exec]]
. Le but de ce plugin est tout simplement d’executer le script et d’envoyer le resultat dans les plugin Output configurés (ici InfluxDB mais ça pourrait aussi être une base Graphite). Un exemple de fichier de configuration fonctionnel est disponible sur GitHub.
Editez le fichier telegraf.conf et modifiez ou rajoutez les lignes suivantes (à adapter suivant votre configuration):
############################################################################### # OUTPUTS # ############################################################################### # Configuration for influxdb server to send metrics to [[outputs.influxdb]] # The full HTTP or UDP endpoint URL for your InfluxDB instance. urls = ["http://127.0.0.1:8086"] # required # The target database for metrics (telegraf will create it if not exists) database = "VSAN" # required # Precision of writes, valid values are "ns", "us" (or "µs"), "ms", "s", "m", "h". # note: using second precision greatly helps InfluxDB compression precision = "s" ## Write timeout (for the InfluxDB client), formatted as a string. ## If not provided, will default to 5s. 0s means no timeout (not recommended). timeout = "5s" ############################################################################### # INPUT PLUGINS # ############################################################################### [[inputs.exec]] # Shell/commands array # Full command line to executable with parameters, or a glob pattern to run all matching files. commands = ["python /path/to/script/vsanmetrics.py -s vcenter.example.com -u [email protected] -p MyAwesomePassword -c VSAN-CLUSTER --performance --capacity"] # Timeout for each command to complete. timeout = "60s" # Data format to consume. # NOTE json only reads numerical measurements, strings and booleans are ignored. data_format = "influx" interval = "300s"
Relancez le service Telegraf:
% sudo systemctl restart telegraf.service
Attention, Telegraf doit pouvoir accéder au script avec le compte qui éxecute le service Telegraf. Il s’agit par défaut du compte root. De plus, si vous avez installé pyvmomi avec PIP, assurez vous de l’avoir fait pour le compte root avec la commande sudo -H pip install pyvmomi
.
InfluxDB
Maintenant que Telegraf est censé envoyer des données dans InfluxDB, vérifions que c’est bien le cas ! Toujours sur votre serveur, relancez l’utilitaire ‘influx’
% influx Connected to http://localhost:8086 version 1.3.5 InfluxDB shell version: 1.3.5 >
Connectez-vous à la base de données VSAN
que nous avons créer precedemment
> use VSAN Using database VSAN
Enfin assurez vous que des données sont bien présentes:
&> show MEASUREMENTS name: measurements name ---- cache-disk capacity-disk capacity_checksumOverhead capacity_dedupOverhead capacity_efficientcapacity capacity_fileSystemOverhead capacity_global capacity_namespace capacity_other capacity_statsdb capacity_summary capacity_vdisk capacity_vmswap cluster-domclient cluster-domcompmgr disk-group host-domclient host-domcompmgr virtual-disk virtual-machine vsan-host-net vsan-pnic-net vsan-vnic-net vscsi
Affaire à suivre…
Maintenant que les données sont présentes dans InfluxDB, elles sont donc accessibles par Grafana. La création de dashboards fera l’objet d’un autre article mais en attendant vous trouverez pleins de ressources disponibles sur internet. N’hésitez pas à m’envoyer une capture d’écran de vos créations, je les ajouterais dans l’article.
Bonjour Erwan,
J’ai une erreur lors du test de mon cluster vsan avec ton script :
Traceback (most recent call last):
File « ./vsanmetrics.py », line 527, in
main()
File « ./vsanmetrics.py », line 365, in main
apiVersion = vsanapiutils.GetLatestVmodlVersion(args.vcenter)
AttributeError: ‘module’ object has no attribute ‘GetLatestVmodlVersion’
C’est lié à la version du Vcenter peut-être?
ça avance en changeant la version de python :
ligne 357 il mange des parenthèses :
File « vsanmetrics.py », line 357
print ‘The required cluster not found in inventory, validate input.’
^
SyntaxError: Missing parentheses in call to ‘print’. Did you mean print(‘The required cluster not found in inventory, validate input.’)?
maintenant ça marche en partie mais à un moment le script fait :
Traceback (most recent call last):
File « vsanmetrics.py », line 527, in
main()
File « vsanmetrics.py », line 509, in main
tags = parseEntityRefId(measurement,metric.entityRefId,uuid,vms,disks)
File « vsanmetrics.py », line 199, in parseEntityRefId
tags[‘hostname’] = disks[entityRefId[1]]
KeyError: ‘526e56b9-03b4-2f66-30ae-7c825801cae2’
une idée?
Salut David,
Tout d’abord merci beaucoup d’essayer mon script et désolé que ca ne fontionne pas du premier coup 😉
Tu peux me donner plus d’infos (version Python, vSAN, etc…)? Tu peux me contacter en privé si besoin.
Problème corrigé, les grafs sont en cours de construction !!!
Merci Erwan.
Bonjour Erwan,
Beau travail pour ce module et pour ce tutoriel aussi!
Je bloque sur un petit soucis qui semble lié à vsanmgmtObjects.py :
# ./vsanmetrics.py -h
Traceback (most recent call last):
File « ./vsanmetrics.py », line 19, in
import vsanapiutils
File « /root/scripts/vsan/vsanapiutils.py », line 22, in
import vsanmgmtObjects
File « /root/scripts/vsan/vsanmgmtObjects.py », line 1, in
from pyVmomi.VmomiSupport import CreateDataType, CreateManagedType, CreateEnumType, AddVersion, AddVersionParent, F_LINK, F_LINKABLE, F_OPTIONAL, F_SECRET, newestVersions, stableVersions, publicVersions
ImportError: cannot import name F_SECRET
As tu une idée de ce qui ne va pas?
Je suis sous debian 9.5 avec Python 2.7.13
a+
Bonjour et merci pour votre retour !
Quelles versions des API vSphere et vSAN utilisez vous ?
Finalement, je me suis rabattu sur le plugin intégré dans telegraf depuis la version 1.8. Merci encore pour ton tuto, il m’a au moins permis de mieux comprendre le fonctionnement de l’API vsphere.
a+
vmware 6.7 mais je n’en suis même pas à ce stade puisque je n’ai fait que demander l’aide. Pour les librairies vSphere et vSAN je ne trouve pas de numéro de version, tout ce que je peux te donner c’est la release date : 2017-07-27
Bonjour Erwan,
Un énorme merci pour le travail réalisé.
J’ai plusieurs questions, svp :
Comment faire lorsqu’on a plusieurs cluster vSAN au sein d’un même vCenter ?
Je n’ai pas créé de Database au départ, j’ai laissé le fichier .conf le faire, j’aimerais changer la durée de retention sur 1 an,
est-ce qu’un ALTER RETENTION POLICY 365d fonctionnerais ? Connaissez vous la durée de retention par défaut ?
J’ai aussi beaucoup de metrics dropped… quelles sont les best practices selons la volumétrie de l’infra virtualisé que l’on possède ? (environs 1500 vms)
Par ailleurs, j’aimerais savoir si vous aviez un dashboard grafana qui va avec ce plugin svp ? (De mon côté je suis en train de travailler sur 2 dashboards, mais j’ai du mal a faire remonter les data, peut-être du aux metrics dropped).
Merci à vous. Excellente journée et continuation à vous.
Bonjour Pierre,
Je suis en train de travailler sur des dashboards mais je n’ai pour l’instant aucune idée de quand ils seront disponibles… Si vous en avez fait n’hésitez pas à les partager !
Je suis désolé mais je n’ai pas constaté de metrics dropped sur mes infras de test et on ne m’a jamais remonté ce problème…Concernant la rétention, je ne pense que par défaut il n’y en a pas. Et dans le cas ou vous avez plusieurs clusters, il vous suffit de définir plusieurs ‘[[inputs.exec]]’ dans le fichier de conf de telegraf (vous trouverez un exemple sur GitHub)
Bonjour et merci pour ce script bien utile, qui évite de bidouiller avec des branches de forks de telegraf 😉
Petite précision, sur un ensemble de données assez conséquent, j’ai été obligé d’augmenter les limites nofile pour le user telegraf car j’avais un message du genre sur une RHEL 7 :
2020-01-30T15:37:36Z E! [inputs.exec] Error in plugin: exec: exit status 1 for command ‘python3 /expldata/vmware/vsanmetrics/vsanmetrics.py -s 192.168.0.1 -u USER -p PASSWORD -c CLUSTER –performance –capacity –health’: Traceback (most recent call last):…
Dans un fichier /etc/security/limits.d/99-telegraf.conf, ajoutez cette ligne :
telegraf – nofile 10000
Vérifiez la prise en compte avec :
# su -s /bin/bash telegraf -c ‘ulimit -n’
Et redémarrer telegraf.
Sinon, je suis preneur pour la suite avec un json Grafana qui va bien ^_^
Il y a bien ceux-là, mais il faut tout adapter : https://grafana.com/grafana/dashboards/10430 & https://grafana.com/grafana/dashboards/10431
Merci encore Erwan
Bonjour Arnaud,
Merci pour ces infos ! J’ai bien l’intention de publier des dashboards, il me reste juste à trouver du temps pour le faire 😉
Bonjour,
Je viens d’installer tout ça ce jour (Python 3.7, sdk 6.7) et si le script fonctionne pour la remonté de capacité ou encore pour l’état de santé, mais il renvoi pas contre une erreur au niveau de la performance :
Exception in thread Thread-1:
Traceback (most recent call last):
File « C:\script\vsanmetrics\vsanmetrics.py », line 685, in getPerformance
cluster=cluster_obj
File « C:\Program Files\Python37\lib\site-packages\pyVmomi\VmomiSupport.py », line 706, in
self.f(*(self.args + (obj,) + args), **kwargs)
File « C:\Program Files\Python37\lib\site-packages\pyVmomi\VmomiSupport.py », line 512, in _InvokeMethod
return self._stub.InvokeMethod(self, info, args)
File « C:\Program Files\Python37\lib\site-packages\pyVmomi\SoapAdapter.py », line 1397, in InvokeMethod
raise obj # pylint: disable-msg=E0702
pyVmomi.VmomiSupport.vmodl.fault.SystemError: (vmodl.fault.SystemError) {
dynamicType = ,
dynamicProperty = (vmodl.DynamicProperty) [],
msg = ‘Unable to execute query. DB error code: 1, please check log file for details’,
faultCause = ,
faultMessage = (vmodl.LocalizableMessage) [],
reason = ‘Runtime fault’
}
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File « C:\Program Files\Python37\lib\threading.py », line 926, in _bootstrap_inner
self.run()
File « C:\Program Files\Python37\lib\threading.py », line 870, in run
self._target(*self._args, **self._kwargs)
File « C:\script\vsanmetrics\vsanmetrics.py », line 692, in getPerformance
except vmodl.fault.NotFound as e:
File « C:\Program Files\Python37\lib\site-packages\pyVmomi\VmomiSupport.py », line 263, in __getattr__
raise AttributeError(attr)
AttributeError: NotFound
J’ai fait un arrêt relance du service de perfornance du vsan, mais sans succès. Vous avez une idée du problème ?