CloudUnit utilise la Suite Elastic pour monitorer vos projets dès la première ligne de code
Le contexte
En 2015 Treeptik, une jeune startup aixoise, partenaire premium de Docker sur le volet formation et conseils, a mis à disposition en open source une forge logicielle orientée développement Java : CloudUnit. Nous fournissons de facto les images pour Tomcat, WildFly, Fatjar (vertx, springboot, etc.) mais aussi de nombreux modules base de données et autres comme NoSQL, JMS, etc.
Le projet est entièrement disponible sous licence GPLV3 sur Github.
Figure 1 - Page d'accueil des applications
Figure 2 - Liste des modules disponibles
Problématique
Le principe de CloudUnit est de fournir un environnement complet mais simple à mettre en oeuvre que ce soit pour son installation ou son utilisation. CloudUnit, développé en Java sur SpringFramework, expose une API REST qui est consommée par un Client Angular (FrontWeb) ou un CLI écrit en SpringShell. Plus exactement CloudUnit est un orchestrateur au dessus de Docker qui fait tourner des images standards mais très customisées.
Au fait, que vient faire Elastic là dedans à côté de Nexus, Jenkins2, SonarQube… ?
Et bien, nous savons tous que le monitoring est rarement un point prioritaire durant les phases de développement. D’ailleurs, rares sont les équipes intégrant les compétences liées à la Suite Elastic – Elasticsearch, Kibana, Beats et Logstash. Généralement c’est en production que l’on se rend compte des problèmes de performance et au mieux en pré-production lors des tests de charge. Nous souhaitons donner à toutes les équipes (petites ou grosses) les moyens de monitorer leurs développements dès la première ligne de code. Nous fournissons ainsi une plateforme sur étagère avec des tableaux de bord préconfigurés.
Figure 3 - Tableau de bord de l’état de santé global de la plateforme
(nombre et type des conteneurs applicatifs, consommation globale de ressources)
Les cas d’utilisation
Un éditeur de logiciel ou le plateau d’une grande SSII peut utiliser CloudUnit dès le début de ses projets pour qualifier ses développements. Le chef de projet bénéficie d’une vue claire sur les tableaux de bord Kibana et peut très vite se rendre compte, par exemple, qu’un développeur utilise mal Hibernate en surchargeant la base de données. Pour cela nous formons les équipes de développement aux bonnes pratiques Java avec la librairie DropWizards Metrics afin que ceux-ci puissent générer leurs propres métriques et exploiter la Suite Elastic au mieux. Par ailleurs, nous faisons souvent le constat qu’il est nécessaire de former les développeurs avant même de parler d’Elastic ou Kibana. C’est pourquoi, CloudUnit permet de disposer immédiatement de la Suite Elastic déployée localement. Les administrateurs système peuvent évidemment la prendre main et la configurer en mode cluster.
Comment cela fonctionne-t-il ?
Le monitoring de CloudUnit se base aujourd’hui sur
- des agents légers de transport Beats
- un agent java fork de jmxtrans pour la partie JMX.
Les images CloudUnit présentes sur le dockerhub intègrent toutes ces fonctionnalités.
Plus précisément, voici comment tout fonctionne. Afin de monitorer non seulement les ressources consommées par les conteneurs Docker mais aussi les métriques spécifiques aux applications déployées, nous utilisons l’agent Metricbeat qui dispose de nombreux modules. L’agent collecte les statistiques des conteneurs (CPU, mémoire disque, etc.) mais aussi les métriques applicatives et les envoie directement dans Elasticsearch. Nous sommes donc capables de déployer de nouvelles applications depuis l’interface de CloudUnit, de générer des tableaux de bords sans aucune configuration manuelle.
Figure 4 - Metricbeat data workflow
Pour cela nous avons créé un conteneur Docker dédié au stockage des binaires de nos agents de monitoring nommés cu-monitoring. Ce conteneur contient les binaires de Metricbeat, Heartbeat et Packetbeat.
Notre agent cu-monitoring est démarré via un fichier docker compose :
monitoring-agents:
container_name: cu-monitoring-agents
hostname: ${HOSTNAME}
build:
context: cu-elk/monitoring-agents
image: cloudunit/elk-monitoring-agents
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro
- ./cu-elk/monitoring-agents/metricbeat-conf:/opt/cloudunit/monitoring-agents/metricbeat/conf.d
- monitoring-agents:/opt/cloudunit/monitoring-agents
environment:
- "TZ=${TZ}"
- "ELASTICSEARCH_URL=$ELASTICSEARCH_URL"
- "HOSTNAME=${HOSTNAME}"
labels:
- "traefik.enable=false"
depends_on:
- elasticsearch
Dans ce fichier on spécifie deux volumes persistants Docker dont un pour y stocker les fichiers de configuration de l’agent Metricbeat (un par type d’application) ainsi qu’une variable d’environnement définissant l’url du backend Elasticsearch.
Afin de démarrer le processus Metricbeat au démarrage de nos applications, il faut modifier le docker-entrypoint.sh pour y ajouter le démarrage du processus on mode background (ou non) en fonction de la valeur de la variable d’environnement APPLICATIVE_MONITORING.
#!/bin/bash
CU_USER=$2
CU_PASSWORD=$3
if [[ ! -z "$CU_USER" ]] && [[ ! -z "$CU_PASSWORD" ]]
then
PATTERN_USER="s/CU_USER/$CU_USER/g"
PATTERN_PASSWD="s/CU_PASSWORD/$CU_PASSWORD/g"
sed -i $PATTERN_USER /opt/cloudunit/tomcat/conf/tomcat-users.xml
sed -i $PATTERN_PASSWD /opt/cloudunit/tomcat/conf/tomcat-users.xml
fi
# if $APPLICATIVE_MONITORING doesn't exist or is equals to 1
if [ -z "$APPLICATIVE_MONITORING" ] || [ "$APPLICATIVE_MONITORING" -eq 1 ]; then
/opt/cloudunit/monitoring-agents/metricbeat/metricbeat -c /opt/cloudunit/monitoring-agents/metricbeat/conf.d/nginx.yml&
fi
# if $JMX_MONITORING doesn't exist or is equals to 1
if [ -z "$JMX_MONITORING" ] || [ "$JMX_MONITORING" -eq 1 ]; then
JAVA_OPTS="$JAVA_OPTS -javaagent:/opt/cloudunit/tomcat/lib/jmxtrans-agent-1.2.5-SNAPSHOT-jar-with-dependencies.jar=/opt/cloudunit/conf/jmxtrans-agent.xml"
fi
# JAVA_OPTS="$JAVA_OPTS -Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n"
if [[ $1 == "run" ]]; then
exec catalina.sh "run"
fi
exec "$@"
Une fois nos conteneurs, visualisations et tableaux de bord définis (un par type d’application) on peut commencer à créer nos applications depuis CloudUnit ou lancer manuellement notre application avec la commande : docker run -d cloudunit/tomcat-8 ce qui permettra d’accéder sans aucune configuration manuelle à ce type de tableau de bord :
Figure 5 - Tableau de bord d'une module de type MySQL
De même nous travaillons sur un agent Java en open source : https://github.com/Treeptik/jmxtrans-agent:
Cet agent Java a été ajouté dans chacun de nos conteneurs et est activé par défaut. Il envoie de façon automatique l’ensemble des données des beans JMX dans l’instance Elastic de CloudUnit.
#!/bin/bash
CU_USER=$2
CU_PASSWORD=$3
if [[ ! -z "$CU_USER" ]] && [[ ! -z "$CU_PASSWORD" ]]
then
PATTERN_USER="s/CU_USER/$CU_USER/g"
PATTERN_PASSWD="s/CU_PASSWORD/$CU_PASSWORD/g"
sed -i $PATTERN_USER /opt/cloudunit/tomcat/conf/tomcat-users.xml
sed -i $PATTERN_PASSWD /opt/cloudunit/tomcat/conf/tomcat-users.xml
fi
# if $APPLICATIVE_MONITORING doesn't exist or is equals to 1
if [ -z "$APPLICATIVE_MONITORING" ] || [ "$APPLICATIVE_MONITORING" -eq 1 ]; then
/opt/cloudunit/monitoring-agents/metricbeat/metricbeat -c /opt/cloudunit/monitoring-agents/metricbeat/conf.d/nginx.yml&
fi
# if $JMX_MONITORING doesn't exist or is equals to 1
if [ -z "$JMX_MONITORING" ] || [ "$JMX_MONITORING" -eq 1 ]; then
JAVA_OPTS="$JAVA_OPTS -javaagent:/opt/cloudunit/tomcat/lib/jmxtrans-agent-1.2.5-SNAPSHOT-jar-with-dependencies.jar=/opt/cloudunit/conf/jmxtrans-agent.xml"
fi
# JAVA_OPTS="$JAVA_OPTS -Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n"
if [[ $1 == "run" ]]; then
exec catalina.sh "run"
fi
exec "$@"
Grâce à l’explorateur de fichier, un utilisateur peut éditer directement le fichier de configuration de l’agent pour décider de ce qui sera envoyé vers le backend Elastic. Evidemment tout ceci peut s’intégrer dans un cycle CI Pipeline avec Jenkins de façon automatique.
Figure 6 - Explorateur de fichiers
Figure 7 - Edition d'un fichier via l'explorateur
Encore plus de Suite Elastic !
Nous sommes en train de mettre en place une solution de logging automatisé de nos application via l’agent Filebeat. Celle-ci utilisera la même suite logicielle que nous utilisons pour les métriques mais avec l’ajout du composant Logstash afin d’enrichir nos données, et les présenter via des tableaux de bord basés sur des métriques tirés de logs.
Avec l’évolution rapide des agents Beats (bientôt version 6), nous envisageons de mettre en place d’autres agents comme Packetbeat, ou encore Heartbeat qui nous permettront de nous assurer du bon fonctionnement de nos services applicatifs.
Dans le but de minimiser les ressources disque occupées par les métriques, nous allons utiliser la fonction native de filtrage des agents Beats qui nous permettra de sélectionner exclusivement les métriques utilisés dans les tableaux de bord.
En parallèle de CloudUnit et pour une intégration future dans celui-ci, nous travaillons également sur la mise en place d’un workflow d'auto-scaling de service Docker à partir de métriques délivrées par Metricbeat et Heartbeat. Ce workflow basé sur Logstash analysera les résultats des métriques délivrés par Heartbeat et Metricbeat dans Elasticsearch pour augmenter ou diminuer automatiquement le nombre de conteneurs dans un service Docker Swarm. L'auto-scaling pourra être effectué en fonction du temps de réponse d’une application ou des ressources consommées.
La collecte automatique de métriques en fonction du type d’application est une fonctionnalité essentielle du PaaS Cloudunit et la richesse de la Suite Elastic nous permet de construire de façon efficace ces outils.
Sébastien Musso est Ingénieur Système Expert Docker chez Treeptik et OPSDev sur le Projet Cloudunit. Il utilise la Suite Elastic dans afin de logger et monitorer des plateformes applicatives. Contributeur au projet Metricbeat sur la partie Docker.
