Remède à l’aveuglement de Kafka

Il est difficile de visualiser pour les développeurs, opérateurs et manageurs, ce qui se cache à l’intérieur des entrailles de Kafka. Cet article parle d’une nouvelle interface graphique bientôt disponible. L’interface fut présenté par George Vettcaden, VP Management product chez Hortonworks, en avant première lors de la conférence du DataWorks Summit de Juin 2018 à San José.

Contexte

George nous a décrit le processus de création et de conception, pour la mise à disposition d’un nouveau produit appellé «streams messaging manager», en d’autres termes, le Kafka Manager

Hortonworks a souhaité attendre la mise à disposition de la distribution HDF en version 3.2 pour prendre le temps de concevoir les fonctionnalités qu’ils souhaitaient apporter. Ils ont ainsi priorisé la livraison de la version 3.2 et ont utilisé un tableau de bord Trello pour organiser l’ensemble des évolutions. Pour mémoire, depuis la version 3.0 d’HDF, Kafka fait parti de la distribution HDF et ne sera plus packagé dans HDP à partir de la version 3.0.

Une fois finalisés, les ingénieurs ont pris toutes leurs idées et ont commencé à les analyser et à les partager avec :

  • Hortonworks Support Engineer
  • Hortonworks Professional Service
  • Hortonworks Backlogs
  • les clients

Une interface graphique de qualité

De cette analyse est ressorti que le besoin essentiel est la capacité de superviser l’utilisation de Kafka. En effet, peu importe la charge de travail du cluster et et de ses clients, les utilisateurs n’ont aucune idée de ce qui se passe à l’intérieur de Kafka ou quel est l’état de leurs Topics (au moins pour les clients HDP/HDF de Kafka). En effet, dans cette version, il n’y a pas d’interface utilisateur ni d’API pour surveiller Kafka, la seule solution restante était d’activer JMX et de collecter des mesures par soit-même.

En conséquence, ils ont commencé à travailler sur une interface utilisateur dont la première vocation est de donner l’état d’un cluster Kafka. Cette interface donne un aperçu des métriques du cluster, incluant le nombre de Brokers, le calendrier des événements, les Topics et les partitions créés, le nombre de producteurs et de consommateurs, le nombre de messages consommés et produits par Topic ou par Brokers, …

Ils ont conçu quelques interfaces qui furent soumis directement des clients qui s’étaient portés volontaires pour les tester.

Ce processus a aboutit à l’interface ci-dessous. En la visualisant, ma première réflexion fut de me dire comment faisais-je avant ? Ce n’était pour pas si difficile, n’est-ce pas ?

kafka manager ui

Magnifique.

Cette interface est la dernière itération disponible, et vraiment, vous pouvez voir toutes les informations sur le cluster Kafka au premier coup d’oeil: le nombre de producteurs, leurs identifiants, les événements … En haut de l’interface sont visibles deux onglets: Topics et Brokers. Actuellement, c’est l’onglet Topics qui a été placé en première position à la demande des clients. En effet, en tant qu’ingénieur et développeur, j’aurais personnellement positionné l’onglet Broker en première position mais les clients ont estimé que les Topics étaient la partie la plus importante. La priorité des utilisateurs est de connaître comment un topic a été partitionné et comment les brokers se répartissent la charge d’écriture et de lecteurs des messages.

Bien sûr, l’interface s’intègre à un environnement d’entreprise et les clusters kerberisés sont pris en charge même dès le premier MVP. De nos jours, vous ne pouvez pas avoir de MVP sans le support Kerberos, les choses ont bien changé d’il y a quelques années. L’interface utilisateur s’intègre avec un LDAP et un AD pour l’authentification et avec Ranger pour l’autorisation.

Fonctionnement

Le gestionnaire lit les données JMX de Kafka, les informations de métadonnées de Zookeeper et enfin les métriques principales d’Ambari Metrics puis l’interface utilisateur combine ces trois sources pour concevoir un tableau de bord complet comme celui présenté ci-dessus.

Ce composant sera livré dans le cadre de l’offre Hortonworks DataPlane (DPS) et s’appuiera sur l’architecture de cette offre. Le service DataPlane est déployé sur un noeud et fonctionne comme un agent capable de se connecter aux clusters gérés par Ambari afin d’obtenir des informations de configuration. En conséquence, un hôte DPS peut gérer plusieurs clusters gérés par Ambari et centraliser les informations sur les services en cours d’exécution. Kafka Manager fera partie de DPS (donc présent ni dans HDP ni dans HDF).

Conlusion

La démo donnée était convaincante. Ce service devrait être publié dans les deux prochains mois ce qui nous emmènerait vers août 2018 et fera partie de l’offre Hortonworks DataPlane.

Il ne nous reste plus qu’à prendre notre mal en patience !

Par |2018-06-21T13:08:45+00:00June 20th, 2018|Big Data, DataWorks Summit 2018|0 commentaire

À propos de l'auteur :

Laisser un commentaire