Fonction Autodiscover basée sur les indices, compatible avec Docker et Kubernetes, dans Beats

Dès la version 6.0, nous avons commencé à ajouter des fonctionnalités à Beats qui améliorent la prise en charge du monitoring de conteneurs. Nous avons récemment ajouté une nouvelle fonctionnalité : Autodiscover dans Filebeat et Metricbeat, compatible avec Docker et Kubernetes. La fonction Autodiscover vous permet de définir un ensemble de configurations qui sera lancé de façon dynamique par Beats chaque fois que vous en aurez besoin. Cette fonctionnalité est particulièrement utile pour monitorer les conteneurs en raison de la nature dynamique de ces derniers.

Défi du monitoring de conteneurs

Dans le cadre d'une infrastructure traditionnelle, vous êtes normalement amené à configurer un nouvel hôte ainsi que tous les services qui doivent s'exécuter sur ce dernier. Vous devez aussi configurer l'agent de monitoring chargé d'interroger les services en question. Les outils de gestion de configuration facilitent la tâche, mais la situation reste assez statique.

Avec l'architecture de conteneurs, toutes les cibles sont mobiles. Les déploiements sont dynamiques. Ils grandissent, se réduisent, puis disparaissent. Les conteneurs vont et viennent d'un nœud à l'autre. Vous ne pouvez obtenir aucun indicateur à partir d'adresses IP fixes.

Vos opérations de suivi requièrent des outils spécifiques.

Autodiscover

Penchons-nous sur son fonctionnement. Voici un exemple de configuration :

metricbeat.autodiscover:
  providers:
   - type: docker
     templates:
       - condition.contains:
           docker.container.image: etcd
         config:
          - module: etcd
            metricsets: ["leader", "self", "store"]
            hosts: "${data.host}:2379"

output.elasticsearch:
  hosts: ["localhost:9200"]

Ce script configure Metricbeat pour utiliser le fournisseur Autodiscover de Docker. Vous pouvez définir une liste de modèles à utiliser. Ces modèles sont liés à une condition chargée de les déclencher. Dans ce cas, la condition correspond à l'image du conteneur qui contient etcd (nous utilisons la valeur contains, car le champ image stocke les paires name:tag). Lorsqu'un conteneur etcd est créé, Metricbeat lance le module etcd pour le monitorer en remplaçant la variable ${data.host} par l'adresse IP du conteneur.

Observons attentivement comment tout cela fonctionne :

1. Événements Autodiscover

Beats Autodiscover est compatible avec plusieurs fournisseurs, notamment avec Kubernetes et Docker. Les fournisseurs mettent en œuvre une façon de suivre les événements sur une plateforme spécifique. Dès qu'un événement a lieu, le fournisseur génère un événement Autodiscover qui contient toutes les informations nécessaires pour interagir avec celui-ci.

2. Vérification des conditions

Chaque événement est comparé à une liste de conditions qui utilise le même format de configuration que les processeurs. Si une condition correspond à l'événement, elle produit alors l'ensemble correspondant de configurations.

3. Expansion de variables

Les modèles de configuration peuvent contenir des variables. Celles-ci sont remplacées par des valeurs réelles provenant de l'événement qui a vérifié la condition. Ce mécanisme vous permet de définir des configurations dynamiques qui peuvent être associées au statut d'un conteneur, comme une adresse IP. Il permet aussi d'effectuer des configurations plus complexes au moyen d'étiquettes et d'annotations.

4. Début/fin de la configuration

Dès que la configuration finale est créée, elle est lancée par le processus Autodiscover. Les configurations valides comprennent des modules dans Metricbeat et Filebeat, ainsi que des entrées dans ce dernier.

On trouve des événements de début comme de fin. Par conséquent, une configuration lancée par Autodiscover sera automatiquement stoppée par le départ du conteneur. Aucune configuration spéciale n'est requise.

La fonction Autodiscover comporte une fonctionnalité utile qui enrichit tous les événements qu'elle génère avec des métadonnées de Docker ou de Kubernetes. Vous n'avez donc pas besoin d'utiliser les processeurs adddockermetadata ou addkubernetesmetadata. Ces métadonnées sont utiles lorsque vous examinez des logs et des indicateurs, car elles servent de filtres et vous permettent de vous concentrer sur l'essentiel.

Présentation des indices

Avec la sortie de la version 6.3, vous pouvez désormais utiliser des indices pour définir le monitoring des conteneurs. Auparavant, vous deviez mettre à jour votre fichier de paramètres Beats pour configurer le monitoring d'une application fraîchement déployée.

La fonction Autodiscover basée sur les indices inverse le contrôle des paramètres de monitoring. Elle permet de stocker ces paramètres au niveau du conteneur de l'application plutôt que dans un emplacement centralisé. Cela signifie que l'équipe qui crée et déploie une application est habilitée à définir le monitoring de cette dernière.

La configuration suivante active la fonction Autodiscover basée sur les indices pour qu'elle puisse être utilisée avec les logs de conteneurs Kubernetes (cette modification peut être effectuée dans notre manifeste Kubernetes de référence pour Filebeat) :

filebeat.autodiscover:
  providers:
    - type: kubernetes
      hints.enabled: true

Voilà, vous pouvez utiliser les annotations de pods Kubernetes ou les étiquettes Docker pour indiquer à Filebeat et à Metricbeat comment traiter les logs de vos conteneurs. Par exemple, si vous exécutez une application Java dans un pod, vous pouvez y ajouter ces annotations :

annotations:
  co.elastic.logs/multiline.pattern: '^\['
  co.elastic.logs/multiline.negate: 'true'
  co.elastic.logs/multiline.match: after

Lors du démarrage du pod, Filebeat traite les annotations et commence à lire les logs en fonction du modèle multiligne donné, et ce, dans le but de rapprocher les traces d'appels Java. Reportez-vous à la documentation pour consulter la liste complète des indices disponibles.

Vous pouvez aussi utiliser les modules pour convertir les logs en données structurées. Par exemple, si vous exécutez un serveur NGINX, ajoutez ces annotations, et tous les logs du serveur seront convertis pour vous fournir des informations sur vos visites :

annotations:
  co.elastic.logs/module: nginx
  co.elastic.logs/fileset.stdout: access
  co.elastic.logs/fileset.stderr: error

Comme vous pouvez le constater, chaque flux de sortie du log est mappé vers un ensemble de fichiers différent. Vous pouvez également mapper tous les flux vers un même ensemble de fichiers en indiquant simplement co.elastic.logs/fileset.

Vous pouvez aussi tirer profit des indices avec Metricbeat. Voici comment configurer la même instance NGINX pour permettre à Metricbeat d'extraire des indicateurs. Comme vous pouvez l'observer, l'expansion de variables fonctionne ici aussi : ${data.host} sert à récupérer l'adresse IP du conteneur.

annotations:
  co.elastic.metrics/module: nginx
  co.elastic.metrics/metricsets: stubstatus
  co.elastic.metrics/hosts: '${data.host}:80'
  co.elastic.metrics/period: 10s

Si vous exécutez à la fois Filebeat et Metricbeat, vous pouvez utiliser les deux ensembles d'indices en même temps.

Conclusion

La fonction Autodiscover basée sur les indices transfère la configuration de vos paramètres de monitoring au niveau des applications que vous souhaitez monitorer. Elle met ainsi les outils adéquats à la disposition des équipes, particulièrement dans le cadre de scénarios mutualisés. L'ensemble simple d'instructions qui accompagne la fonction facilite l'expérience d'utilisation tout en la rendant pertinente.

Nous n'avons qu'effleuré les possibilités d'Autodiscover. Nous avons hâte de recevoir vos commentaires et d'en savoir plus sur la façon dont vous utilisez cette fonction. N'hésitez pas à visiter notre forum Beats et à partager vos expériences.