Construire une pile ELK avec Elasticsearch

App Cloud

Construire une pile ELK avec Elasticsearch

Nous avons lancé notre tout nouveau service Elasticsearch sur le cloud d'application Swisscom (en phase de bêta fermée au moment de la rédaction de cet article, mais la disponibilité générale ne saurait tarder). Ce service remplace notre ancienne offre ELK par des options plus stables et plus flexibles. Dans cet article, nous te montrons comment utiliser Elasticsearch en combinaison avec les buildpacks Logstash et Kibana pour obtenir la pile ELK que tu connais déjà. Nous te donnons également quelques points de départ pour utiliser la flexibilité accrue de l'offre afin d'adapter la pile à tes besoins.

Par Mathis Kretz, Former Head of Cloud Empowerment

Création de l'instance de service

Nous commençons par créer une instance du nouveau service Elasticsearch. Si tu regardes sur notre place de marché, tu verras qu'il y a six plans différents parmi lesquels tu peux choisir, de xxsmall* à xlarge*. Ces tailles de T-shirt indiquent le montant de RAM que ton instance Elasticsearch reçoit, et en fonction de cela, le montant d'espace disque. Pour les besoins de notre tutoriel, xxsmall* est suffisant. Pour ta pile ELK productive, tu as bien sûr besoin d'un plan plus grand. Créons donc cette instance :

Cela permet de fournir un cluster Elasticsearch à trois nœuds, qui s'étend sur trois sites. Ensuite, nous ajouterons Logstash et Kibana. Notre ancienne offre ELK comprenait Logstash et Kibana avec des configurations câblées en dur comme partie de l'instance de service. Dans la nouvelle approche, ce n'est plus le cas. Au lieu de cela, nous installons ces deux composants nous-mêmes à l'aide des buildpacks Logstash(ouvre une nouvelle fenêtre) et Kibana(ouvre une nouvelle fenêtre). Ces buildpacks sont utilisés pour pousser les deux composants en tant qu'apps dans Cloud Foundry, en prenant la configuration respective que l'utilisateur a indiquée dans différents fichiers de configuration. L'installation est certes un peu plus compliquée, mais elle a l'avantage de permettre de créer des configurations individuelles de manière tout à fait naturelle.

Installer Logstash

Note : cette section est en cours de modification pour décrire la nouvelle façon de déployer Logstash(ouvre une nouvelle fenêtre).

Installons donc la configuration minimale dont nous avons besoin pour pousser Logstash avec le buildpack(ouvre une nouvelle fenêtre) Logstash. Nous commençons dans un nouveau répertoire

et nous créons les deux fichiers suivants

Comme d'habitude dans Cloud Foundry, nous écrivons un manifest.yml pour indiquer à la plateforme comment configurer Logstash en tant qu'app. Nous appelons l'application my-logstash et elle est bien sûr liée à notre instance Elasticsearch. Nous demandons également à Cloud Foundry d'utiliser le buildpack de Logstash(ouvre une nouvelle fenêtre) avec l'option buildpack.

Le fichier Logstash que nous avons également créé contient des paramètres de configuration pour Logstash. Si tu laisses ce fichier vide, Logstash s'exécutera avec les paramètres par défaut. Dans notre cas, nous voulons ajouter l'authentification pour protéger notre instance Logstash contre les accès non autorisés. Nous ajoutons donc les lignes suivantes à Logstash

Avec cette étape, notre instance Logstash est prête à être déployée, donc nous la poussons.

Dès que le push est terminé, nous avons une instance logstash en cours d'exécution qui est connectée à notre instance Elasticsearch. Maintenant, nous faisons la même chose pour Kibana.

Installation de Kibana

Note : cette section est en cours de modification pour décrire la nouvelle façon de déployer Kibana(ouvre une nouvelle fenêtre).

Repartons donc d'un nouveau répertoire pour préparer notre déploiement de Kibana.

Nous ajoutons les deux fichiers suivants dans ce répertoire pour fournir la configuration minimale

Dans le fichier de configuration de Kibana, nous intégrons le plugin X-Pack. Ce plugin offre un soutien pour l'accès authentifié dont nous avons besoin pour protéger notre interface utilisateur Kibana. Le plugin offre également toute une série d'autres fonctions supplémentaires pour Kibana et Logstash, qui dépassent le cadre de cet article.

Dans manifest.yml, nous indiquons que notre instance Kibana s'appelle my-kibana, se connecte à notre instance Elasticearch et reçoit 3 Go de mémoire pour l'installation du plug-in X-Pack. En principe, tu peux réduire ton instance Kibana à 2G après la première utilisation, car la mémoire supplémentaire n'est plus nécessaire après l'installation. Ici aussi, nous utilisons l'option buildpack pour indiquer à Cloud Foundry d'utiliser le buildpack de Kibana.

Maintenant, nous pouvons continuer à faire avancer Kibana.

Lorsque le push est terminé, nous avons fini d'installer tous les composants nécessaires. Nous pouvons vérifier l'installation en entrant les éléments suivants

Vérifie si nous pouvons voir l'instance Elasticsearch et les liens de l'app à my-logstash et my-kibana.

Connecter la pile à ton application

Ensuite, nous voulons transmettre les protocoles d'application à notre pile ELK nouvellement créée. Pour cela, nous créons un service personnalisé avec l'option -l. Avec cette option, les applications qui se lient au service peuvent transmettre leurs logs à un composant compatible avec syslog, dans notre cas Logstash.

Dans la dernière étape, nous lions ce service fourni par l'utilisateur à l'application dont nous voulons collecter les logs, et nous restaurons l'application.

Nous avons maintenant terminé la configuration de base de nos composants ELK. Avant de passer à la suite de la configuration, nous faisons un premier test rapide en nous connectant à Kibana. Dans cet exemple, l'URL de l'instance Kibana est my-kibana.scapp.io. Nous obtenons les données de connexion à partir de la variable d'environnement VCAP_SERVICES de notre application Kibana.

et cherche les champs full_access_username etfull_access_password

Après la connexion, il nous est demandé de créer un premier modèle d'index. Pour le moment, nous n'avons qu'un seul index logstash à choisir (assure-toi d'avoir déclenché un peu de trafic log de ton app pour le voir).

Nous pouvons spécifier un modèle pour indiquer à Kibana quel(s) indice(s) utiliser lors de l'affichage des données. Si tu saisis *, tous les indices seront utilisés. Si tu saisis logstash-*, les indices dont le nom commence par logstash- sont utilisés. Si nous indiquons un modèle d'index, nous pouvons également indiquer à Kibana quel champ dans les données doit être utilisé pour trier les enregistrements au fil du temps. Nous pouvons toujours choisir @timestamp, un champ qui est automatiquement ajouté par Elasticsearch. Nous pouvons aussi choisir un champ plus approprié que nous ajoutons à nos données dans le cadre de notre configuration Logstash. Pour cet exemple, nous choisissons @timestamp.

Nous pouvons maintenant naviguer vers l'écran Discover de Kibana et vérifier si nous voyons des entrées de log de l'application que nous avons liée.

Cependant, si nous regardons les entrées du journal, nous constatons qu'elles ne sont pas encore structurées comme nous l'étions dans l'ancien service ELK. Le champ de message contient en fait tout le message non analysé. Ensuite, nous verrons quelles parties de la configuration nous devons adapter pour obtenir le même traitement des messages de log que l'ancien ELK.

Options de configuration

L'ancien service ELK disposait d'un filtre qui analysait les messages de log et

- extrayait les champs selon la spécification du protocole Syslog(ouvre une nouvelle fenêtre)
- extrayait les messages contenant des objets JSON en fonction des JSON
-Divise les noms d'attributs en champs

Il y avait aussi une configuration Curator(ouvre une nouvelle fenêtre) qui permettait de nettoyer Elasticsearch à intervalles réguliers. Nous décrirons les détails de la configuration de Curator dans un futur article.

Avant de commencer la configuration des filtres, tu dois savoir que tu peux trouver les modèles des fichiers de configuration ci-dessous(ouvre une nouvelle fenêtre) sur Github. Il s'agit de modèles, car tu dois remplacer certains paramètres, comme le nom d'hôte Elasticsearch de ton instance et les données d'accès, par les valeurs correspondantes de ton environnement.

Pour configurer notre nouvelle pile ELK de manière à ce qu'elle traite les logs de la même manière que l'ancienne ELK, nous devons choisir le mode de configuration mixte, décrit dans la documentation du buildpack Logstash(ouvre une nouvelle fenêtre). Avant tout, nous devons définir notre propre configuration de filtre et de sortie. Pour cela, nous ajoutons deux nouveaux sous-répertoires conf.d et grok-patterns au répertoire dans lequel nous avons établi notre configuration Logstash. Nous ajoutons également les fichiers filter.conf, output.conf et grok-patterns dans ces répertoires comme suit :

Dans filter.conf, nous définissons une définition de filtre personnalisée qui effectue l'analyse syntaxique Syslog et JSON. Ce fichier doit donc contenir les lignes suivantes :

Cette définition de filtre fait référence à un modèle Grok qui doit être présent dans le fichier grokpatterns :

Le modèle Grok ci-dessus sépare le préfixe standard d'une ligne de log Cloud Foundry dans les champs correspondants de la spécification syslog.

Comme avec l'ancien ELK, nous voulons diviser l'indexation en deux index séparés, l'un pour les messages analysés et l'autre pour les messages qui n'ont pas été analysés par le filtre ci-dessus. Pour ce faire, le fichier output.conf contient les lignes suivantes :

Les valeurs HOST, USER et PASSWORD doivent correspondre à l'hôte, au full_access_username et au full_access_password de l'entrée elasticsearch dans VCAP_SERVICES de my-logstash.

Comme nous sommes en mode de configuration mixte du buildpack Logstash et que nous indiquons nos propres définitions de filtre et de sortie, nous devons faire explicitement référence à la définition d'entrée par défaut dans le fichier Logstash :

Nous devons pousser Logstash à nouveau pour que ces changements prennent effet.

Si nous déclenchons un peu de trafic log et revenons ensuite à Kibana, nous pouvons voir qu'il y a deux nouveaux index dans Elasticsearch si nous allons dans Administration > Motifs d'index > Créer un motif d'index. Le nom du premier commence par parsed-. Il s'agit de l'index qui accueille tous les messages qui ont été analysés par le filtre que nous venons d'écrire. Le nom du deuxième nouvel index commence par unparsed-. Il contient tous les messages qui n'ont pas pu être analysés par le filtre. En quelques étapes de configuration, nous avons donc obtenu le comportement de l'ancien service ELK. Que faire si tu veux migrer quelques index d'une ancienne instance ELK vers le nouveau Elasticsearch ? Voyons comment y parvenir.

Migration de l'ancien service ELK

Nous allons utiliser l'utilitaire elasticdump(ouvre une nouvelle fenêtre) pour migrer les index d'un ancien ELK vers une nouvelle instance Elasticsearch. Pour installer elasticdump, nous exécutons

Ensuite, nous devons mettre en place des tunnels ssh vers notre ancien ELK et vers notre nouveau Elasticsearch. Nous devons nous assurer que les deux services sont liés à au moins une app dans l'espace où nous travaillons, afin que les groupes de sécurité correspondants soient créés dans Cloud Foundry et que l'accès aux deux services soit possible depuis cet espace. Si la connexion est refusée la première fois, essaie de redémarrer ton application pour que les derniers paramètres des groupes de sécurité soient appliqués. Maintenant, nous devons rassembler une série de paramètres pour la mise en place des tunnels. Commençons par l'ancienne instance ELK. Nous examinons l'environnement d'une app à laquelle cette instance est liée :

Dans VCAP_SERVICES, nous trouvons l'hôte, le port et les données de connexion pour ELK

Continuons avec la nouvelle instance d'Elasticsearch. Nous examinons à nouveau l'environnement d'une application à laquelle cette instance est liée.

et nous notons l'hôte et les données de connexion de VCAP_SERVICES.

Maintenant, nous pouvons configurer le tunnel avec l'une des apps de cette zone (peu importe laquelle).

Comme Elasticsearch vérifie le nom d'hôte lors des requêtes HTTP entrantes et le compare aux noms de cluster, nous devons mettre en place une résolution de nom locale dans /etc/hosts pour que l'hôte ELK et l'hôte Elasticsearch soient tous deux résolus en localhost. Nous ajoutons donc les deux lignes suivantes dans /etc/hosts

Une fois que le tunnel et la résolution de nom sont mis en place, nous pouvons vérifier quels indices sont présents dans l'instance ELK avec une simple requête HTTP.

Nous obtenons une sortie sous la forme suivante, qui répertorie tous les indices

Avec elasticdump, nous pouvons maintenant migrer les index un par un vers notre nouveau Elasticsearch ou écrire un script qui les migre tous. Pour les index créés dans le passé, cela peut se faire pendant le fonctionnement normal. Tu peux donc importer petit à petit les anciens index d'ELK pendant que ton nouveau Elasticsearch fonctionne déjà et reçoit de nouvelles données de log. Supposons que tu veuilles importer l'index parsed-2018.04.09 d'ELK vers Elasticearch. Pour cela, tu exécuterais les deux commandes suivantes

Si tu te connectes maintenant à l'instance de Kibana à laquelle le nouveau Elasticsearch est lié, tu verras parsed-2018.04.09 comme l'un de tes index.

Conclusion

Et voilà, tu y es ! Dans cet article, nous t'avons montré comment configurer la pile ELK sur la base de la nouvelle offre Elasticsearch, y compris les buildpacks Logstash et Kibana. Nous t'avons également montré comment adapter la configuration du nouveau buildpack Logstash pour simuler les paramètres de l'ancien service ELK. Enfin, nous t'avons montré comment migrer les index d'un ancien ELK vers une nouvelle instance Elasticsearch. Cette nouvelle façon de configurer la pile ELK te permet aussi de partager une instance ELK avec plusieurs orgs et espaces. Tu peux ainsi regrouper les logs de différents projets et stades de développement (et économiser de l'argent). Nous espérons que tu apprécieras notre nouvelle offre Elasticsearch. Fais-nous savoir ce que tu en penses !

Mathis Kretz

Mathis Kretz

Senior Data and Analytics Consultant

Plus d’articles getIT

Prêts pour Swisscom

Trouve le Job ou l’univers professionnel qui te convient. Où tu veux co-créer et évoluer.

Ce qui nous définit, c’est toi.

Vers les univers professionnels

Vers les postes vacants cybersécurité