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ée 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 appelé «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 partie de la distribution HDF et ne sera plus packagée dans HDP à partir de la version 3.0.

Une fois finalisées, 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 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 soi-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éées, 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 abouti à l’interface ci-dessous. En la visualisant, ma première réflexion fut de me dire Comment faisais-je avant ? Ce n’était pourtant pas si difficile, n’est-ce pas ?

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 Topicsqui 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 lecteur 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).

Conclusion

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 !