Cet article présente un petit retour d’expérience sur l’intégration de WebLogic Server avec l’outil de monitoring de plus en plus populaire et open-source, Prometheus. L’intégration technique est réalisée via le composant open-source WebLogic Monitoring Exporter.
L’objectif n’est pas de détailler cette intégration mais d’exprimer mon feedback sur ce composant. Plusieurs articles, comme celui-là, exposent déjà comment réaliser cette intégration.
Prometheus est une solution de monitoring open-source que je croise de plus en plus au fil de mes interventions. Il est très répandu dans les architectures micro-services et particulièrement dans les clouds publics ou privés.
Le principe de fonctionnement est assez simple : Chaque service doit exposer ses métriques via une API HTTP. Ces métriques sont lues régulièrement par Prometheus et sont stockées dans sa base de données de type Time-Series. Ces données peuvent ensuite être consultées via la console intégrée à Prometheus ou via un outil tel que Grafana.
Il est également possible de bâtir une stratégie d’alerting basée sur les données recueillies.
Fonctionnement
L’exposition des métriques se fait grâce à un exporter déployé au sein du service à superviser. Prometheus dispose de plusieurs exporters pour les produits les plus courants.
WebLogic n’apparait pas dans cette liste mais il existe un projet open source sous Git Hub qui implémente un exporter spécifique pour WebLogic Server : WebLogic Monitoring Exporter.
Cet exporter se présente sous la forme d’une application web wls-exporter.war qu’il faut déployer sur les serveurs WebLogic à superviser.
Cette application web expose 2 urls :
- /metrics pour récupérer les métriques configurées
- /configure pour configurer l’exporter
Configuration
L’accès aux métriques est sécurisé, il faut montrer patte blanche. Le plus simple est de créer un utilisateur dédié à Prometheus dans le security realm de WebLogic et de l’affecter au groupe Monitors. Une liaison sécurisée avec TLS est recommandée.
L’accès à la page de configuration (/configure) n’est pas sécurisé, l’accès à la consultation de la configuration est libre. Par contre, la modification de la configuration via l’envoi d’un nouveau fichier (appel HTTP POST) est sécurisée.
La configuration de l’exporter est embarquée directement dans l’application web (wls-exporter.war) et il est possible de la remplacer ou de la compéter via la page de configuration (/configure).
[pastacode lang= »markup » manual= »metricsNameSnakeCase%3A%20true%0Aqueries%3A%0A-%20JVMRuntime%3A%0A%20%20%20%20key%3A%20name%0A%20%20%20%20prefix%3A%20jvm_%0A%20%20%20%20values%3A%20%5BheapFreeCurrent%2C%20heapFreePercent%2C%20heapSizeCurrent%2C%20heapSizeMax%2C%20uptime%2C%20processCpuLoad%5D%0A%0A-%20applicationRuntimes%3A%0A%20%20%20%20key%3A%20name%0A%20%20%20%20workManagerRuntimes%3A%0A%20%20%20%20%20%20prefix%3A%20workmanager_%0A%20%20%20%20%20%20key%3A%20applicationName%0A%20%20%20%20%20%20%0A-%20threadPoolRuntime%3A%0A%20%20%20%20key%3A%20name%0A%20%20%20%20prefix%3A%20threadpool_%0A%20%20%20%20values%3A%20%5BexecuteThreadTotalCount%2C%20throughput%2C%20hoggingThreadCount%2C%20standbyThreadCount%2C%20executeThreads%2C%20executeThreadIdleCount%5D%0A%20%20%0A-%20JTARuntime%3A%0A%20%20%20%20key%3A%20name%0A%20%20%20%20prefix%3A%20jta_%0A%20%20%20%20values%3A%20%5BactiveTransactionsTotalCount%5D%0A » message= »Exemple de configuration WebLogic Monitoring Exporter » highlight= » » provider= »manual »/]
La page Git Hub du composant explique très bien comment construire le livrable à l’aide de Maven.
La solution dispose également d’un composant complémentaire, WLS Prometheus Exporter Coordinator développé en GO qui permet de partager la configuration de l’exporter quand il est déployé sur plusieurs instances WebLogic, dans un cluster par exemple. Il permet donc de garder toutes les configurations synchronisées sur tous les serveurs. Il permet également de modifier à chaud cette configuration sur tous les serveurs d’un coup sans avoir besoin de redéployer l’application.
Retour d’expérience
L’approche proposée par les exporters Prometheus est intéressante car elle permet en 1 seul appel HTTP(s) de récupérer un ensemble de métriques. Ce qui n’est pas le cas par exemple si on utilise l’API REST Management de WebLogic Server car il faudra 1 appel HTTP(s) par métrique collectée.
WebLogic Monitoring Exporter versus JMX Exporter
Prometheus dispose d’un exporter officiel « JMX Exporter » qui permet d’exposer les métriques souhaitées depuis une application Java pour peu qu’elle dispose d’un service JMX. Fonctionnellement cet exporter fait la même chose, à savoir exposer via HTTP une liste de métriques pré-configurée. Cette configuration n’est pas dynamique par contre.
Techniquement, cette solution demande de déployer un agent Java sur chaque JVM ce qui est un peu plus compliqué et offre moins de souplesse que l’application web proposée par WebLogic Monitoring Exporter. L’application web peut être déployée, retirée, démarrée stoppée à la demande et sans arrêt/relance du serveur WebLogic, ce qui n’est pas le cas avec l’agent du JMX Exporter.
Fonctionnement de WebLogic Monitoring Exporter
La mauvaise surprise !
Problème #1
J’ai été sans doute un peu naïf sur ce coup mais quelle ne fut pas ma surprise en lisant le code et en comprenant comment fonctionne le composant. La récupération des métriques se fait via un appel HTTP-POST vers l’API Management RESTful du serveur WebLogic (POST /management/weblogic/latest/serverRuntime/search). En clair, chaque appel vers /metrics sur un serveur provoque n appels vers lui-même pour récupérer les métriques. Si vous avez par exemple besoin de métriques sur JVMRuntime, JTARuntime et ThreadPoolRuntime le composant effectuera 3 appels.
Donc au total, la lecture des données depuis Prometheus donnera lieu à 4 appels HTTP :
- 1 entre Prometheus et le serveur WebLogic
- 3 entre le serveur WebLogic et lui-même (!)
A multiplier par le nombre de serveurs WebLogic dans le domaine…
Pas très optimisé tout ça, y’a moyen de faire mieux.
Problème #2
De plus, mes tests sur ce composant ont relevé 2 problèmes pour lesquels j’ai ouvert un bug sur le site Git Hub du composant :
- Si les serveurs WebLogic tournent sous MS-Windows (si si ça existe), Prometheus est incapable de « parser » les métriques renvoyés par l’exporter à cause des caractères de fin de ligne : Prometheus attend une fin de ligne à la mode Linux/Unix, c’est à dire \n alors que sous Windows les fins de ligne sont signifiées avec les caractères \n\r (Carriage return, line feed)
- Prometheus ne sait « parser » les nombres à virgules que si le séparateur décimal est le point « . », ce qui n’est pas le cas du français qui utilise la virgule…
J’ai bon espoir que ces 2 points soient pris en compte et corrigés rapidement. Dans le cas contraire, les corrections sont simples à réaliser soi-même sur le code.
Problème #3
Last but not least. L’url vers l’API RESTful Management de WebLogic est dans le code du composant : /management/weblogic/latest/serverRuntime/search
Elle pointe directement vers le contexte serverRuntime de l’API REST. En conséquence :
- J’ai pas trouvé comment accéder aux métriques globales du domaine
- J’ai pas trouvé comment accéder aux métriques du serveur lui-même car le modèle de configuration impose d’aller chercher des informations dans les sous-contextes de serverRuntime (JTARuntime, JVMRuntime, etc…)
De ce fait, il n’est pas possible de récupérer l’état du serveur (RUNNING) par exemple. Une gageure pour un outil de monitoring…
Je garde un petit espoir d’y arriver mais c’est pas gagné.
Conclusion
Le composant est très jeune ce qui explique sans doute les défauts que je lui ait trouvé. Je pense que la conception mériterait de tirer un meilleur parti des concepts et fonctionnalités offertes par WebLogic pour améliorer et optimiser le fonctionnement du composant. Pourquoi, par exemple, interroger tous les serveurs du domaine alors que le serveur d’administration à lui-seul détient déjà toutes les informations sur les métriques collectées ?
Si certains ont des expériences différentes avec ce composant je serai ravi de lire leurs commentaires sur le sujet et d’en discuter.