Grafana, pour les gouverner tous

Le nerf de la guerre dans toute production informatique d’envergure, c’est la supervision. Vous le savez tous, rien n’est pire que d’être aveugle quand il s’agit de suivre et d’entretenir comme il se doit tous les composants qui participent au fonctionnement général de nos systèmes d’information. A l’opposé, il serait illusoire d’imaginer qu’un seul et même outil puisse couvrir tous les besoins en la matière : certains seront plus orientés “diagnostic temps réel” (comme VMware Log Insight, SexiLog par exemple), d’autres au contraire seront plus adaptés à un suivi moyen ou long terme, avec des courbes de tendances et/ou des outils de simulation de type “What If”. Enfin, suivant la diversité des équipements et constructeurs impliqués, on va plutôt privilégier “des intégrés” (comme vRealize Operations ou Turbonomics) ou se tourner vers de l’Open Source riche en plugins et très ouvert aux évolutions.

En somme, il n’y a pas de solution miracle et pour le coup, cela me pousse régulièrement à tester de nouveaux produits, histoire de voir si par hasard, l’herbe ne serait pas plus verte ailleurs … C’est là que démarre le sujet de ce billet.

A la suite de nombreux échanges avec mon pote Erwan Quelin, que j’ai connu il y a déjà plus deux ans à l’occasion du VMworld 2016, nous avons décidé de nous rencontrer pour démarrer une collaboration autour, au départ, de la supervision des baies Unity. Il se trouve en effet qu’Erwan venait de terminer le développement de la v1 de UnityMetrics, un outil open source capable d’interroger l’API REST d’une baie et d’en récupérer les divers points de supervision et les restituer au format “Telegraf” (j’y reviendrai).

Histoire de remettre cette initiative dans le contexte, les Unity disposent aujourd’hui, certes, d’un super outil “Cloud” géré par Dell EMC, CloudIQ. Malgré tout, je trouvais intéressant de conserver des metrics en local pour le capacity planning et de disposer d’une accessibilité plus directe par nos équipes de production. Il me fallait un framework adapté pour construire cela. D’autre part, je voulais depuis longtemps me mettre à Grafana… les planètes étaient donc parfaitement alignées pour travailler sérieusement et profiter de l’expertise d’Erwan sur ce sujet.

Dont acte, décision est prise de se voir… ce n’était que le début, tout de suite, la suite !

Découverte du pipe Telegraf-InfluxDB-Grafana avec UnitytMetrics

Le premier objectif était de tester UnityMetrics (dispo ici) sur nos baies Unity et voir ce qu’il était capable de récupérer, puis faire ingérer ces extractions à un agent Telegraf, qui lui-même les enverrait dans la foulée vers une base de données adaptée, en l’occurence InfluxDB. Comme présenté dans le chapeau, cela m’a permis aussi de découvrir le pipe Telegraf -> InfluxDB -> Grafana et dégrossir un peu la configuration générale associée. Après quelques heures, nous sommes arrivés à un premier dashboard satisfaisant pour une première baie !

Je ne vais pas vous faire l’article sur Grafana et son orchestre ici, d’autant qu’Erwan a prévu de publier un billet (je vais lui mettre la pression ^^) spécifique à ce sujet sur MyVMworld.fr, son repère de bloggueur en compagnie de Damien et Noham. Cependant, et pour faire écho à de précédents articles personnels sur Cacti/RRDTools (ça commence à dater), voici à quoi ressemble une sortie type “Telegraf” issue de UnityMetrics :

Vous pouvez noter que le type d’output reste relativement simple à appréhender : un mot clé en tête pour définir le type de paramètre remonté, la liste des paramètres définissant le contexte (hostname, sp, etc.) et enfin, le couple clé/valeur et le timestamp (en nanosecondes depuis le 1/1/1970). Simple à sortir, du moment que vous avez accès aux clés/valeurs intéressantes pour vous !

De là… une idée a germé dans mon cerveau de geek invétéré … “Mais, mais … et si je construisais petit à petit des graphs complémentaires pour les autres équipements de stockage de nos environnements de production en utilisant les compétences acquises grâce à Erwan, ça serait sympa d’avoir un point de supervision unique et évolutif !”. En effet, après avoir pas mal bourlingué sur Cacti et avoir ensuite utilisé des outils “sur étagère” comme SexiLog ou SexiGraf, j’ai été converti à l’utilisation de Grafana comme plateforme de graphing particulièrement “sexy” c’est le cas de le dire ^^

De UnityMetrics à VSANMetrics …

Me voilà donc parti à construire de nouveaux plugins Telegraf pour récupérer et à terme, mettre en forme, les points de supervisions importants pour toujours plus d’équipements en prod chez nous. Et le fait est qu’aujourd’hui nous travaillons avec de nombreux produits : VPlex, XtremIO, VNX (en fin de vie), VxRail/VSAN, Isilon … Il y avait du travail !

Après UnityMetrics j’ai donc recyclé mes développements perso précédents pour Cacti (voir ici pour XtremIO et ici pour VPlex) et les ai adapté au type de sortie attendue par Telegraf afin qu’il puisse les envoyer ensuite sur InfluxDB.

J’ai également du développer de zéro un script spécifique pour récupérer les points de supervision de nos clusters Isilon en utilisant l’API REST ad-hoc. Je vous colle ici le script qui en résulte, mais attention, il n’est ni documenté ni terminé (pas de tests d’erreur notamment). En gros, c’est “roots” et fourni sans garantie d’aucune sorte : si votre Isilon explose à la suite de l’utilisation de ce script shell, je décline toute forme de responsabilité ^^.

Après quelques jours, j’avais intégré et généré des tableaux de supervision synthétiques pour notre VPlex Metro, nos XtremIO, nos Unity, nos deux Isilon. Il me restait malgré tout “le plus dur”, récupérer aussi nos environnements VSAN. En effet, VSAN ne disposant pas d’API REST, j’étais contraint à explorer les API classiques nécessitant un contexte de développement, quel que soit le langage employé. Pour le coup, il y en a plusieurs (voir ici), mais aucun que je ne maîtrisais vraiment (j’ai passé des nuits sur C/C++ dans une autre vie, mais c’était il y a longtemps ^^).

Je vous passe les détails des échanges nombreux sur Twitter et en message privé, mais au final, Erwan – il est vrai emballé par mon magnifique projet :D – a entrepris de coder un plugin Python de son cru, VSANMetrics, capable de récupérer les indicateurs de clusters VSAN 6.6 (compatible 6.7). Cela lui a aussi permis, accessoirement, de se mettre à ce langage, d’ailleurs vous pouvez déjà aller consulter son premier billet dédié à ses pérégrinations ici. J’ai ensuite lâchement profité de son travail pour y ajouter nos clusters ! Des belles courbes sensuelles sont alors venu enrichir les autres déjà présente, pour obtenir un panel complet de l’ensemble de notre stockage de production (hors VNX) !!

Conclusion : vers l’infini et au delà !

Concernant le temps consacré à ce “développement personnel”, en dehors de la partie scripting qui m’a pris quelques heures (disons une dizaine en tout), l’intégration et l’approche progressive de Grafana favorise énormément l’amélioration de votre efficacité : le premier Dashboard est assez laborieux, vous devez apprendre la logique et la syntaxe du produit, mais plus vous en construisez et plus cela devient rapide. Si en plus vous avez la chance, comme moi, d’avoir un tuteur pendant la phase de découverte, vous gagnez un temps important. Une fois les bases acquises, la réalisation d’une intégration Telegraf->Influx->Grafana ne prend que quelques dizaines de minutes avant d’obtenir quelque chose de particulièrement satisfaisant, professionnel, et très visuel.

Aujourd’hui, je ne vois pas encore de limite à Grafana, à mon échelle évidemment, et nul doute que je vais désormais continuer à capitaliser sur cette plateforme.

De manière plus personnelle, quel plaisir de remettre un peu les mains dans le concret, le dur, le cambouis, et travailler de la ligne de commande, du script, et par dessus tout, de démarrer une collaboration avec des gens de qualité qui ont la même passion de la construction que moi, intacte, après toutes ces années ! Sans vouloir du tout venir ne serait-ce qu’approcher le niveau d’excellence et d’intégration d’un SexiLog ou SexiGraf, j’ai beaucoup de travail, encore, afin d’améliorer et compléter les dashboards de base déjà produits, les rendre plus génériques et adaptable à d’autres contextes de production. Si je devais me projeter dans les prochains moi, j’espère pouvoir, avec l’aide d’Erwan et de tous ceux qui voudraient nous aider, construire une base de plugin adaptés à la plupart des environnements techniques majeurs du stockage et de la virtualisation en général : il nous en manque donc encore beaucoup, Nutanix bien sûr, mais aussi Netapp, Pure Storage, Avamar/Datadomain, Veeam et j’en passe …

On vous attend avec plaisir sur Twitter ( Erwan: @erwanquelin ou Moi: @cqchu ), mais aussi, si vous êtes intéressé, sur le Channel Slack VMUG France (prenez contact avec Noham Medyouni ou Frédéric Giovannacci sur VMUG, ici)

7 thoughts on “Grafana, pour les gouverner tous

  1. SLMitch says:

    Bonjour,
    Pour les clusters isilons,j’utilisais dans le passé

    https://github.com/Isilon/isilon_data_insights_connector
    qui fait le grab + envoit dans l’influxdb.

    Tous les dashboards grafana sont disponibles sur le repo git aussi.

    N’utilisant pas telegraf, je peux aussi vous indiquer une facon assez simple de pousser les lignes aux formats influxdb directement dans influxdb :

    ./unitymetrics -unity ….. |while read line
    do
    curl -i -XPOST ‘http://:8086/write?db=unity’ –data-binary “$line” &>/dev/null
    done

    A mettre en cron.

    Distribuez vous vos dashboard grafana pour unity par hasard ?

  2. Cédric Cédric says:

    Merci pour les infos ! J’ai oublié de préciser dans le billet qu’on réinvente sans doute la poudre pour certains plugins, mais c’est autant un moyen pour faire du capacity planning que pour découvrir et se former sur les outils :)

    Pour les dashboard, je peux les distribuer sans souci, même s’ils sont, pour le moment, assez “ad-hoc” ! Il faut que je développe un peu des templates génériques avant qu’ils soient vraiment utile pour n’importe qui, je pense.

    Cédric

  3. Jihefge says:

    Hello,
    beau boulot, c’est très appétissant.
    Je suis aussi preneur d’un exemple de dashboard, sachant que je vais bientôt remplacer mes vieilles vnx par de l’unity et du vplex…… :-)
    Et que ça me tente quand même bien de mettre en place un outil de ce genre (pour l’instant, on ne monitore pas les baies).

  4. Cédric Cédric says:

    Hello Jihefge ! clairement, c’est du tout bon pour Unity/VPlex ;)

    Je vais prendre un peu de temps d’ici fin de semaine pour construire des dashboard plus génériques et adaptables. Je publierai un billet à ce sujet dès que possible.

  5. MicKBfr says:

    Bonjour Cédric, on s’est croisé lorsque j’étais encore jeune padaone de D.supiot. Je fais moins d’Aix mais toujours du VMware et NetApp. Je suis ton blog avec intérêt depuis plusieurs années.Je suis aussi un grand fan de Grafana. j’utilise NetApp-Harvest pour la partie NetApp et https://github.com/Oxalide/vsphere-influxdb-go pour la collecte de l’environnement VMware. ça permet de voir rapidement la VM qui fait trop d’IOPS sur un datastore et de corréler avec la vue NetApp. Pour veeam,j’ai fait aussi un script sur chaque lancement de job backup replication et qui permet de faire un “histographe”. Je suis disponible pour échanger et pourquoi pas vous aider dans l’aventure.@ bientôt Mickaël B

  6. Raviere says:

    pour la partie netapp , nabox dév par Yann (Netapp) et j’ai un poil contribué côté scalabilité pour les perfs (on monitore 150 filers avec ca)

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. Apprenez comment vos données de commentaires sont traitées.