Les applications dockérisées à l'épreuve du monitoring

Les applications dockérisées à l'épreuve du monitoring Avec l'avènement des containers logiciels, la supervision de la performance des architectures fait face à de nouveaux défis. Le point sur la démarche à adopter pour ne pas se rater.

Taux de disponibilité, temps d'accès, fréquence de mises à jour, temps moyen de résolution d'incidents... Dans l'univers des containers logiciels, les indicateurs de supervision ne seront pas très différents de ceux utilisés jusqu'ici pour analyser la santé des infrastructures informatiques historiques. "Mais contrairement aux serveurs physiques ou virtuels qui restent très statiques, cette technologie se traduit par des architectures nettement plus dynamiques. Ce qui rend beaucoup plus complexe la mise en place de points de contrôle", reconnait Olivier Pomel, cofondateur et CEO de Datadog, pure player américain du monitoring orienté cloud.

Appréhender la complexité de l'architecture

Très légers, les containers ont tendance à se multiplier comme des petits pains. Typiquement, un container sera dédié à chaque composant applicatif, puis répliqué pour gérer les pics d'audience encaissés par ce dernier. Dans cette logique dite de microservices, "quelques machines physiques ou virtuelles pourront vite être remplacées par des dizaines voire des centaines de containers. Sachant qu'au moment des mises à jour logicielles, des containers seront tués au profit de nouveaux. Ce qui complexifie encore la supervision", poursuit Olivier Pomel.

Obtenir des vues par application

Autre problématique technique, le monitoring devra embrasser toutes les briques de l'architecture et pas seulement les containers. A savoir également : les composants qu'ils encapsulent, l'orchestrateur (DC/OS, Kubernetes, Swarm…), l'infrastructure serveur et réseau sous-jacente (qu'elle soit privée ou publique), etc.

Difficile de savoir par où débuter. "Pour obtenir une première vision opérationnelle du système, il faudra commencer par regrouper les métriques des containers correspondant aux composants des mêmes applications", avance Hervé Leclerc, directeur technique d'Alter Way, une filiale d'Econocom spécialiste de Docker. Pour ce faire, le DT recommande d'adjoindre un "label" à chaque container. Des sortes d'étiquettes qui permettront ensuite d'obtenir une vue par application, concaténant les logs de chaque container sous-jacent. Pour mettre en œuvre ce processus sur sa propre plateforme cloud, Alter Way a recours à l'outil open source Prometheus.

Plusieurs agents de mesure

Différents agents de mesure sont utilisables pour collecter les métriques au sein d'une architecture de containers. Dans l'univers Docker, le plus populaire d'entre eux est cAdvisor. S'exécutant en arrière-plan, il agrège les données propres à l'exécution des containers (consommation machine, réseau, niveau d'isolation des ressources...), puis les exporte vers la plateforme de supervision. "Il existe beaucoup d'autres agents taillés pour Docker. C'est le cas notamment de node-exporter, qui est centré sur le suivi du serveur Docker. Il y en a aussi pour contrôler des briques plus particulières qui auront été containérisées, comme la base de données MySQL par exemple", complète Hervé Leclerc. Pour faciliter leur pilotage, les agents pourront être eux-mêmes containérisés.

"Vu la complexité des architectures de containers, il sera crucial d'automatiser au maximum le monitoring"

"Vu le niveau de complexité que peuvent atteindre les architectures de containers, il sera crucial d'automatiser au maximum la mise en œuvre de la plateforme de monitoring", enchaîne Olivier Pomel. Une solution capable de s'auto-configurer (pour prendre en compte dynamiquement l'ajout de nouveaux containers) se révélera souvent indispensable. L'offre de Datadog comme la technologie Prometheus réalisent ce tour de passe-passe. Elles poussent même l'automatisation encore plus loin en permettant de recourir aux données de métrologie pour auto dimensionner les ressources machines allouées aux containers (en fonction de la montée en puissance des accès notamment).

Autre élément à avoir en tête : du fait de leur grande légèreté, la durée de vie des containers pourra être réduite à quelques secondes. "C'est une aubaine pour optimiser la répartition des traitements et la consommation de ressources machine, mais un nouveau défi à relever en matière de monitoring", pointe Hervé Leclerc. Le rythme de scraping devra être finement réglé pour ne pas passer à côté de certains workloads, mais sans atteindre un niveau trop soutenu qui risquerait de grever les performances applicatives. "Et comme des containers ne cesseront de disparaître et d'apparaître, il est également important de conserver les mesures de performance des containers post-mortem. Ce qui implique une base de logs robuste capable de se repérer dans le temps, à partir de séries temporelles par exemple", ajoute Hervé Leclerc.

Suivre le cycle de vie du container

Mais la problématique du monitoring de containers ne serait pas seulement technique, loin de là. "Elle présente aussi une dimension humaine importante", estime Olivier Pomel. Grâce à la portabilité des containers, les développeurs peuvent désormais être intégrés au processus de déploiement. Du coup, ils devront eux-aussi bénéficier d'indicateurs de performance, à minima de ceux relatifs aux codes dont ils sont responsables. Capable de corréler la performance des applications avec celles des containers et des infrastructures sous-jacentes, la solution de Datadog s'attaque justement à cet enjeu. Elle permet aux développeurs de commencer à concevoir des tableaux de bord de monitoring dès la phase de codage, puis de les partager avec les équipes de test et de production. Ces dernières pouvant à leur tour les enrichir au fur et à mesure de l'avancée du projet.

"Grâce aux containers, les piles applicatives des environnements de développement, de test et de production pourront être quasi-identiques. D'où l'intérêt de commencer à concevoir les indicateurs dès l'étape de développement. L'idée est d'offrir aux équipes le même niveau de compréhension", insiste Olivier Pomel. Et Hervé Leclerc de renchérir : "Dans la logique du DevOps, ce partage de tableaux de bord devient central pour optimiser la qualité du produit fini, puis la maintenance applicative."