Surveillance des conteneurs Docker

Au cœur de tout cela, Scalingo concerne l'exécution de conteneurs Docker. Chacun de ces conteneurs doit être surveillé pour obtenir des données significatives pour nos utilisateurs et pour nous en tant que fournisseur. Lors de l'événement APIDays Berlin et APIStrat Europe 2015, j'ai donné une conférence sur les différentes API qui peuvent être utilisées pour surveiller les conteneurs sur un serveur. Cela traite des limites de l'API Docker Stats et de la manière d'accéder aux données des groupes de contrôle Linux et des namespaces créés par Docker et du projet open source Acadock qui est le résultat de mes investigations sur le sujet.

Depuis Docker 1.5, son API distante contient un point de terminaison pour obtenir des métriques des conteneurs en cours d'exécution sur vos hôtes : GET /containers/:id/stats. Le démon Docker répond par un flux de JSON contenant, pour chaque seconde, toutes les métriques possibles pour les conteneurs donnés. Il y a un problème principal avec cela : il n'y a aucun moyen de paramétrer les données obtenues. Lorsque de nombreux conteneurs sont exécutés sur un serveur et que vous souhaitez surveiller tous, cela entraînera rapidement un problème de charge. Surveiller 200 conteneurs avec l'API Docker peut prendre jusqu'à un cœur CPU complet, ce qui est vraiment trop pour une solution de surveillance. Il n'y a aucun moyen de modifier la période d'une seconde entre chaque envoi de métriques et il n'est pas possible de spécifier quelles données sont envoyées. Cela entraîne beaucoup d'appels système inutiles, créant un surcoût important.

C'est pourquoi il peut être intéressant de récupérer l'information à la source, le noyau Linux. Docker utilise deux mécanismes du noyau pour isoler les processus les uns des autres, ces fonctionnalités sont aussi celles qui nous ont permis d'obtenir des informations par conteneur. D'abord, les groupes de contrôle nous permettent d'obtenir des métriques sur le CPU, la mémoire et les E/S de disques d'un conteneur. Ces informations peuvent être trouvées dans le répertoire des différents contrôleurs : cpuacct, memory et blkio

Standard: /sys/fs/cgroup/:cgroup/docker/:container_id
Systemd: /sys/fs/cgroup/:cgroup/system.slice/docker-#{id}.scope

Standard: /sys/fs/cgroup/:cgroup/docker/:container_id
Systemd: /sys/fs/cgroup/:cgroup/system.slice/docker-#{id}.scope

Standard: /sys/fs/cgroup/:cgroup/docker/:container_id
Systemd: /sys/fs/cgroup/:cgroup/system.slice/docker-#{id}.scope

Standard: /sys/fs/cgroup/:cgroup/docker/:container_id
Systemd: /sys/fs/cgroup/:cgroup/system.slice/docker-#{id}.scope

Ensuite, pour obtenir l'utilisation du réseau d'un conteneur, l'espace de noms réseau doit être entré grâce à l'appel système setns(fd). Le paramètre fd provient d'un gestionnaire de fichiers du fichier /proc/:pid/ns/net. Après avoir appelé cette fonction, le processus actuel est dans le même espace de noms réseau que le conteneur, et des outils standards peuvent être utilisés pour voir la bande passante réseau consommée. (c'est-à-dire lire /proc/net/dev)

Nous avons publié le démon open-source Acadock qui expose toutes les différentes données des groupes de contrôle et des namespaces sous forme d'une simple API HTTP. De plus, il calcule le pourcentage CPU et la consommation réseau au fil du temps. Évidemment, vous pouvez le configurer pour avoir un temps de rafraîchissement inférieur à une seconde, consultez le README.md pour plus d'informations. Le code est disponible sur Github. Essayez-le.

Vous pouvez vous attendre dans les mois suivants à pouvoir lire les données d'utilisation des ressources de notre API, et bien sûr sur notre tableau de bord web. Avec toutes ces métriques, vous pourrez prendre les bonnes décisions concernant vos conteneurs d'application, comme choisir le bon nombre ou la bonne taille pour eux.

Les diapositives de la présentation sont également disponibles :

– Léo Unbekandt, CTO chez Scalingo