Monitoring des conteneurs Kubernetes et Docker avec Beats : logs, indicateurs et métadonnées

Ce blog présente le monitoring de l'environnement d'un conteneur, pouvant inclure Google Kubernetes Engine (GKE), IBM Cloud Kubernetes Service et tous les autres environnements Kubernetes (k8s) et Docker. Dans ce blog, j'utilise IBM Cloud Kubernetes Service.

Vous vous demandez peut-être pourquoi le sujet de cet article est le monitoring des conteneurs Kubernetes et Docker. Les fournisseurs cloud gèrent l'infrastructure et je n'ai qu'à me soucier de mon application, n'est-ce pas ? C'est peut-être vrai, mais je suis le genre de personne qui consulte les avis Yelp même si j'ai reçu des recommandations personnelles, et plus j'ai d'informations, mieux c'est. Je veux que tous les logs et indicateurs concernant mon application et son environnement soient disponibles. Je veux également pouvoir rechercher, visualiser et créer des alertes à leur sujet. Ce monitoring classique des conteneurs est génial, mais je vais aussi vous présenter une façon sympa d'utiliser les événements et les métadonnées Kubernetes pour annoter le diagramme de performances de mon application avec des notifications concernant la montée en charge ou les mises à niveau.

Avant de poursuivre, définissons quelques termes.

• Log : un horodatage et un message. Il pourrait comprendre des entrées de logs classiques telles que "NGINX started at 13:42" (NGINX a démarré à 13:42) ainsi que des événements k8s tels que "There was an NGINX container with a Back-off restarting failed container at 16:20" (Un conteneur NGINX a envoyé des messages plusieurs fois et n'a pas pu redémarrer à 16:20).
• Indicateur : une mesure numérique collectée au cours d'une période définie. Par exemple, "Sales through the eCommerce site were $50,000 over the past ten minutes" (Les ventes sur le site d'e-commerce s'élevaient à 50 000 $ ces dix dernières minutes) ou "CPU utilization was 17% from 14:00:00 to 14:00:10" (L'utilisation du processeur était de 17 % de 14:00:00 à 14:00:10).

Déploiement de l'application dans un cluster Kubernetes

Pour mon exemple, je vais utiliser cette application basée sur Apache HTTP Server, PHP et Redis.

D'autre part, pour monitorer l'application et l'infrastructure du conteneur, nous avons : 

• Un déploiement Elasticsearch Service hébergé sur Elastic Cloud.
• Les agents Beats, les agents légers de transfert de logs et d'indicateurs sont déployés comme un DaemonSet dans le même cluster Kubernetes. Notez que cela peut remplacer Fluentd qui est généralement déployé dans un cluster Kubernetes.

Logs et indicateurs

L'application ci-dessus n'est qu'une partie d'un écosystème qui génère en permanence des informations que nous devrions collecter. Voici les niveaux à partir desquels nous collectons ces logs et indicateurs :

1. Orchestration (Kubernetes)
2. Hôtes
3. Application
4. Conteneur (Docker)

Pour collecter les données, nous utilisons les agents Beats (Filebeat, Metricbeat et Packetbeat) et les modules System, Kubernetes et Docker ainsi que des modules pour l'application (Apache et Redis). Nous avons déployé un DaemonSet pour chaque agent Beat et nous laissons Kubernetes les gérer. Si la liste semble longue, ne vous laissez pas effrayer. En effet, la fonctionnalité Autodiscover de Beats vous simplifie la tâche.  Dans ce blog et dans la vidéo qui l'accompagne, vous trouverez les détails du déploiement des agents Beats pour monitorer une application.  En fait, si vous souhaitez commencer par le commencement, consultez la page du monitoring des conteneurs.

Pour indexer, stocker, rechercher, analyser et visualiser les données, j’ai utilisé Elasticsearch Service hébergé sur Elastic Cloud. Le déploiement d’Elasticsearch Service sur Elastic Cloud est détaillé dans notre page "Getting Started" tout comme le déploiement d’Elasticsearch et de Kibana dans un système que vous gérez vous-même. Dans tous les cas, ça fonctionne très bien.

J'ai évoqué les agents Beats et les modules, et je pense que ceux-ci méritent une meilleure introduction. Un agent Beat est un agent léger qui envoie des données à Elasticsearch ou Logstash. Parfois, les agents Beats sont déployés à l'origine des données, comme sur un système physique ou virtuel. D'autres fois, ils sont déployés parallèlement aux sources, comme, par exemple, un DaemonSet (c’est ce que j'ai fait ici). Les modules simplifient la collecte, l'analyse, l'indexation et la visualisation des formats de logs les plus courants.

Ce que je viens de vous présenter peut vous sembler un peu ennuyeux. Voyons les choses sous un autre angle : les modules Elastic propose une expérience prête à l'emploi. Imaginons que vous savez tout de la gestion d'Apache HTTPD Server, mais que vous ne connaissez pas NGINX. Vous pourriez aller voir quelqu'un qui s'y connaît en NGINX et lui demander "À quoi fais-tu attention dans les logs ? À quels indicateurs fais-tu attention ? Peux-tu me donner les greps de ton fichier d'historique ?" Selon moi, les réponses à ces questions définissent les modules des agents Beats : tableaux de bord prédéfinis, recherches enregistrées, analyse et collecte pour des tas de choses comme Kubernetes, Docker, NGINX, Apache, systèmes d'exploitation, bases de données, etc. D'après mon expérience, il s'agit d'un ensemble de fonctionnalités très puissantes.

Le module k8s collecte des indicateurs relatifs aux pods, nœuds, volumes, ReplicaSets, déploiements, etc. Chaque indicateur possède un ensemble riche de métadonnées pour que vous puissiez relier les données à votre application. Par exemple, vous pourriez ne pas vous soucier du fait que le pod xyz soit proche de la limite d'utilisation de la mémoire, mais si cet indicateur est présenté en association avec le frontend de votre application, alors vous connaissez la valeur pour votre entreprise. Il collecte également des événements (souvenez-vous, j'avais inclus les événements Kubernetes dans la définition du log ci-dessus) que nous utilisons pour enrichir le diagramme de performances dans la vidéo ci-dessous.

Le module Docker collecte des indicateurs relatifs aux conteneurs, aux hôtes, à la mémoire, au réseau, aux vérifications d'intégrité, etc. À l'instar du module Kubernetes, les métadonnées sont très précieuses pour comprendre les performances de votre application et de l'environnement.

Il existe de nombreux autres modules pour Filebeat et Metricbeat. En outre, Packetbeat est compatible avec de nombreux tableaux de bord pour des services tels que Cassandra, Flows, HTTP, MySQL, MongoDB, etc.

Regardez cette vidéo et découvrez à quel point il est facile de transformer les données en renseignements exploitables. La vidéo traite les points suivants :

• Visualiser les événements Kubernetes avec les indicateurs de performance de l'application
• Découvrir l'ensemble d'indicateurs d'événements du module Metricbeat Kubernetes
• Naviguer dans les événements Kubernetes et créer la visualisation personnalisée