Gestion des journaux · 20 min read · Feb 02, 2026
Installer ELK comme serveur de gestion de journaux centralisé sur CentOS 7
Ce tutoriel explique comment configurer un serveur de gestion de journaux centralisé en utilisant la pile ELK sur CentOS 7. Comme quiconque ne le sait pas déjà, ELK est la combinaison de 3 services : ElasticSearch, Logstash et Kibana. Pour construire un serveur de gestion de journaux centralisé complet en utilisant ce concept, il faudrait avoir chacun de ces paquets car ils servent chacun un but différent et sont liés les uns aux autres. En gros, cela fonctionne ensemble comme ceci :
- Pour chaque client que vous souhaitez gérer, il produira son propre journal des services associés.
- Pour le serveur qui sera utilisé pour gérer toutes les informations de journalisation de chaque client, il utilisera le paquet LogStash pour collecter et transformer les données en une valeur relative. Par définition, c’est un pipeline de traitement de données côté serveur open source qui ingère des données provenant de multiples sources simultanément, les transforme.
- Une fois les données collectées et transformées, le serveur de gestion utilisera ElasticSearch pour aider à analyser les données en une valeur pertinente. Vous pouvez utiliser un langage de requête général si vous souhaitez produire un rapport lié selon vos besoins.
- Une fois que les données pertinentes ont été vérifiées et analysées, c’est là que le paquet Kibana entre en jeu car il peut aider à visualiser et gérer les données pertinentes dans une vue appropriée ou les combiner dans un tableau de bord attrayant pour une compréhension facile.
L’image ci-dessous résume le processus de flux de travail :
1. Remarque préliminaire
Pour ce tutoriel, j’utilise CentOS Linux 7.4 dans la version 64 bits. Dans ce tutoriel, nous utiliserons 3 serveurs : le premier sera utilisé comme serveur de gestion et les 2 autres seront utilisés comme clients. Pour cet exercice, nous utiliserons le serveur de gestion pour surveiller un service MySQL existant qui a déjà été configuré et fonctionne sous chaque client. Comme MySQL est un service de base de données principalement utilisé à des fins OLTP, nous ferons en sorte que notre serveur de gestion consigne 2 processus de journalisation, à savoir la vérification de l’état du service MySQL lui-même et la transaction de requête lente. À la fin de ce tutoriel, nous verrons que toute information consignée à partir de n’importe quel service MySQL à l’intérieur du client dédié peut être vue, visualisée et analysée simultanément depuis le serveur de gestion en temps réel.
2. Phase d’installation
Pour la phase d’installation, nous commencerons par l’installation de FileBeat sur les deux serveurs de base de données MySQL qui agissent comme clients. Commençons le processus, ci-dessous les étapes :
[root@mysql_db1 opt]# cd
[root@mysql_db1 ~]# cd /opt/
[root@mysql_db1 opt]# wget https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-6.2.1-x86_64.rpm
--2018-06-09 10:50:46-- https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-6.2.1-x86_64.rpm
Résolution des artifacts.elastic.co (artifacts.elastic.co)... 107.21.237.188, 107.21.253.15, 184.73.245.233, ...
Connexion à artifacts.elastic.co (artifacts.elastic.co)|107.21.237.188|:443... connecté.
Requête HTTP envoyée, attente de réponse... 200 OK
Longueur : 12697093 (12M) [binary/octet-stream]
Enregistrement dans : ‘filebeat-6.2.1-x86_64.rpm’
100%[==============================================================================>] 12,697,093 2.20MB/s dans 6.9s
2018-06-09 10:51:00 (1.75 MB/s) - ‘filebeat-6.2.1-x86_64.rpm’ enregistré [12697093/12697093]
[root@mysql_db1 opt]# yum localinstall -y filebeat-6.2.1-x86_64.rpm
Plugins chargés : fastestmirror, ovl
Examen de filebeat-6.2.1-x86_64.rpm : filebeat-6.2.1-1.x86_64
Marquage de filebeat-6.2.1-x86_64.rpm pour installation
Résolution des dépendances
--> Exécution de la vérification de transaction
---> Package filebeat.x86_64 0:6.2.1-1 sera installé
--> Résolution des dépendances terminée
Dépendances résolues
========================================================================================================================
Package Arch Version Repository Size
========================================================================================================================
Installation :
filebeat x86_64 6.2.1-1 /filebeat-6.2.1-x86_64 49 M
Résumé de la transaction
========================================================================================================================
Installer 1 package
Taille totale : 49 M
Taille installée : 49 M
Téléchargement des paquets :
Exécution de la vérification de transaction
Exécution du test de transaction
Test de transaction réussi
Exécution de la transaction
Installation : filebeat-6.2.1-1.x86_64 1/1
Vérification : filebeat-6.2.1-1.x86_64 1/1
Installé :
filebeat.x86_64 0:6.2.1-1
Terminé !
Une fois terminé, nous allons lister le module par défaut activé par le paquet FileBeat et activer le module mysql qui est nécessaire pour notre cas ici. Ci-dessous les étapes :
[root@mysql_db1 opt]# filebeat modules list
Activé :
Désactivé :
apache2
auditd
icinga
kafka
logstash
mysql
nginx
osquery
postgresql
redis
system
traefik
[root@mysql_db1 opt]# filebeat modules enable mysql
Module mysql activé
Fait, maintenant éditons la configuration nécessaire pour le module mysql que nous avons activé tout à l’heure. Par défaut, une fois que nous avons activé le module mysql à partir du paquet filebeat, il créera automatiquement un fichier yaml à l’intérieur du répertoire modules.d. Pourtant, si le fichier n’a pas été créé, n’hésitez pas à créer un nouveau fichier yaml à l’intérieur du même emplacement. Ci-dessous les étapes :
[root@mysql_db1 opt]# vi /etc/filebeat/modules.d/mysql.yml
- module: mysql
error:
enabled: true
var.paths: ["/var/lib/mysql/mysql-error.log*"]
slowlog:
enabled: true
var.paths: ["/var/lib/mysql/log-slow-queries.log*"]
Comme indiqué ci-dessus, nous avons décidé de consigner 2 processus de journalisation du service MySQL, à savoir la vérification de l’état de la base de données elle-même et le journal des requêtes lentes.
Maintenant, une fois que tout est fait, faisons quelques configurations dans le fichier de configuration principal pour filebeat sous le fichier filebeat.yml. Ci-dessous les configurations définies :
[root@mysql_db1 opt]# vi /etc/filebeat/filebeat.yml
#=========================== Prospecteurs de Filebeat =============================
filebeat.prospectors:
- type: log
enabled: false
paths:
- /var/lib/mysql/mysql-error.log
- /var/lib/mysql/log-slow-queries.log
#============================= Modules de Filebeat ===============================
filebeat.config.modules:
path: ${path.config}/modules.d/*.yml
reload.enabled: false
#==================== Paramètre de modèle Elasticsearch ==========================
setup.template.settings:
index.number_of_shards: 3
#================================ Général =====================================
setup.kibana:
#----------------------------- Sortie Logstash --------------------------------
output.logstash:
hosts: ["172.17.0.6:5044"]
Remarquez ci-dessus que nous avons défini une adresse IP pour l’hôte logstash qui est 172.17.0.6. Cette IP est l’adresse de notre serveur de gestion centralisé qui collectera directement les données de journalisation. J’ai défini l’IP codée en dur car je n’ai pas effectué de modifications alternatives dans le fichier /etc/hosts et je n’ai pas utilisé de serveur DNS pour ce tutoriel. Pourtant, n’hésitez pas à utiliser le nom d’hôte du serveur de gestion si vous avez effectué des modifications alternatives.
Comme tout a été configuré selon le plan, lançons les services filebeat. Ci-dessous les étapes :
[root@mysql_db1 opt]# filebeat setup -e
2018-06-09T11:04:37.277Z INFO instance/beat.go:468 Chemin d'accueil : [/usr/share/filebeat] Chemin de configuration : [/etc/filebeat] Chemin de données : [/var/lib/filebeat] Chemin des journaux : [/var/log/filebeat]
2018-06-09T11:04:37.277Z INFO instance/beat.go:475 UUID du Beat : 98503460-035e-4476-8e4d-10470433dba5
2018-06-09T11:04:37.277Z INFO instance/beat.go:213 Configuration du Beat : filebeat; Version : 6.2.1
2018-06-09T11:04:37.277Z INFO pipeline/module.go:76 Nom du Beat : lara
2018-06-09T11:04:37.278Z ERROR instance/beat.go:667 Sortie : Chargement du modèle demandé mais la sortie Elasticsearch n'est pas configurée/activée
Sortie : Chargement du modèle demandé mais la sortie Elasticsearch n'est pas configurée/activée
[root@mysql_db1 opt]# filebeat -e &
[1] 22010
[root@mysql_db1 opt]# 2018-06-09T12:45:18.812Z INFO instance/beat.go:468 Chemin d'accueil : [/usr/share/filebeat] Chemin de configuration : [/etc/filebeat] Chemin de données : [/var/lib/filebeat] Chemin des journaux : [/var/log/filebeat]
2018-06-09T12:45:18.813Z INFO instance/beat.go:475 UUID du Beat : 98503460-035e-4476-8e4d-10470433dba5
2018-06-09T12:45:18.813Z INFO instance/beat.go:213 Configuration du Beat : filebeat; Version : 6.2.1
2018-06-09T12:45:18.813Z INFO pipeline/module.go:76 Nom du Beat : lara
2018-06-09T12:45:18.813Z INFO [monitoring] log/log.go:97 Démarrage de la journalisation des métriques toutes les 30s
2018-06-09T12:45:18.813Z INFO instance/beat.go:301 filebeat commence à s'exécuter.
2018-06-09T12:45:18.814Z INFO registrar/registrar.go:71 Aucun fichier de registre trouvé sous : /var/lib/filebeat/registry. Création d'un nouveau fichier de registre.
2018-06-09T12:45:18.819Z INFO registrar/registrar.go:108 Chargement des données du registraire à partir de /var/lib/filebeat/registry
2018-06-09T12:45:18.819Z INFO registrar/registrar.go:119 États chargés à partir du registraire : 0
2018-06-09T12:45:18.819Z WARN beater/filebeat.go:261 Filebeat est incapable de charger les pipelines Ingest Node pour les modules configurés car la sortie Elasticsearch n'est pas configurée/activée. Si vous avez déjà chargé les pipelines Ingest Node ou utilisez des pipelines Logstash, vous pouvez ignorer cet avertissement.
2018-06-09T12:45:18.820Z INFO crawler/crawler.go:48 Chargement des prospecteurs : 1
2018-06-09T12:45:18.821Z INFO log/prospector.go:111 Chemins configurés : [/var/lib/mysql/log-slow-queries.log*]
2018-06-09T12:45:18.822Z INFO log/prospector.go:111 Chemins configurés : [/var/lib/mysql/mysql-error.log*]
2018-06-09T12:45:18.822Z INFO crawler/crawler.go:82 Chargement et démarrage des prospecteurs terminés. Prospecteurs activés : 0
2018-06-09T12:45:18.822Z INFO cfgfile/reload.go:127 Rechargement de la configuration démarré
2018-06-09T12:45:18.840Z INFO log/prospector.go:111 Chemins configurés : [/var/lib/mysql/log-slow-queries.log*]
2018-06-09T12:45:18.840Z INFO log/prospector.go:111 Chemins configurés : [/var/lib/mysql/mysql-error.log*]
2018-06-09T12:45:18.840Z INFO cfgfile/reload.go:258 Démarrage de 1 coureur ...
2018-06-09T12:45:18.840Z INFO cfgfile/reload.go:219 Chargement des fichiers de configuration terminé.
2018-06-09T12:45:18.841Z INFO log/harvester.go:216 Le récolteur a démarré pour le fichier : /var/lib/mysql/mysql-error.log
2018-06-09T12:45:18.841Z INFO log/harvester.go:216 Le récolteur a démarré pour le fichier : /var/lib/mysql/log-slow-queries.log
2018-06-09T12:45:20.841Z ERROR pipeline/output.go:74 Échec de la connexion : dial tcp 172.17.0.6:5044 : getsockopt : connexion refusée
2018-06-09T12:45:22.842Z ERROR pipeline/output.go:74 Échec de la connexion : dial tcp 172.17.0.6:5044 : getsockopt : connexion refusée
2018-06-09T12:45:26.842Z ERROR pipeline/output.go:74 Échec de la connexion : dial tcp 172.17.0.6:5044 : getsockopt : connexion refusée
[root@mysql_db1 ~]# tail -f /var/log/filebeat/filebeat
2018-06-09T10:53:28.853Z INFO instance/beat.go:468 Chemin d'accueil : [/usr/share/filebeat] Chemin de configuration : [/etc/filebeat] Chemin de données : [/var/lib/filebeat] Chemin des journaux : [/var/log/filebeat]
2018-06-09T10:53:28.853Z INFO instance/beat.go:475 UUID du Beat : 98503460-035e-4476-8e4d-10470433dba5
Remarquez qu’une fois que vous démarrez le service filebeat, une erreur apparaît dans le journal. Cela est dû au fait que le serveur de gestion qui a été assigné n’était pas encore configuré. Pour la phase initiale, vous pouvez ignorer le journal d’erreurs car il se rétablira automatiquement une fois que notre serveur de gestion aura été configuré et commencé à collecter.
Comme la configuration pour le client est terminée, vous pouvez continuer à répliquer les étapes sur l’autre serveur MySQL qui agit également comme client.
En avançant, nous allons continuer avec la configuration du serveur de gestion lui-même.
3. Phase d’installation (côté serveur de gestion centralisé)
Maintenant que nous avons terminé la configuration pour la préparation côté client, lançons la configuration nécessaire pour le serveur de gestion lui-même. Comme mentionné brièvement, il y a 3 paquets principaux qui doivent être installés et configurés pour le serveur de gestion, à savoir ElasticSearch, LogStash et Kibana.
Pour cette phase, nous allons commencer par l’installation et la configuration nécessaires pour ElasticSearch, ci-dessous les étapes :
[root@elk_master ~]# cd /opt/
[root@elk_master opt]# ls
[root@elk_master opt]# wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-6.2.1.tar.gz
--2018-06-09 12:47:59-- https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-6.2.1.tar.gz
Résolution des artifacts.elastic.co (artifacts.elastic.co)... 107.21.237.188, 54.235.82.130, 107.21.253.15, ...
Connexion à artifacts.elastic.co (artifacts.elastic.co)|107.21.237.188|:443... connecté.
Requête HTTP envoyée, attente de réponse... 200 OK
Longueur : 29049089 (28M) [binary/octet-stream]
Enregistrement dans : ‘elasticsearch-6.2.1.tar.gz’
100%[==============================================================================>] 29,049,089 2.47MB/s dans 16s
2018-06-09 12:48:21 (1.76 MB/s) - ‘elasticsearch-6.2.1.tar.gz’ enregistré [29049089/29049089]
[root@elk_master opt]#
[root@elk_master opt]#
[root@elk_master opt]# tar -zxvf elasticsearch-6.2.1.tar.gz
[root@elk_master opt]# ln -s /opt/elasticsearch-6.2.1 /opt/elasticsearch
[root@elk_master opt]# ll
total 28372
lrwxrwxrwx 1 root root 24 Jun 9 12:49 elasticsearch -> /opt/elasticsearch-6.2.1
drwxr-xr-x 8 root root 143 Feb 7 19:36 elasticsearch-6.2.1
-rw-r--r-- 1 root root 29049089 May 15 04:56 elasticsearch-6.2.1.tar.gz
Une fois l’installation d’elasticsearch terminée, continuons la partie configuration. Pour la configuration, nous allons assigner le répertoire /data/data pour stocker les données de journalisation collectées qui ont été analysées. Le répertoire lui-même sera également utilisé pour stocker l’index qui sera utilisé par elasticSearch lui-même pour des requêtes plus rapides. Pour le répertoire /data/logs, il sera utilisé par elasticSearch lui-même pour ses propres besoins de journalisation. Ci-dessous les étapes :
[root@elk_master opt]# mkdir -p /data/data
[root@elk_master opt]# mkdir -p /data/logs
[root@elk_master opt]#
[root@elk_master opt]# cd elasticsearch
[root@elk_master elasticsearch]# ls
bin config lib LICENSE.txt logs modules NOTICE.txt plugins README.textile
[root@elk_master elasticsearch]# cd config/
[root@elk_master config]# vi elasticsearch.yml
# ---------------------------------- Cluster -----------------------------------
cluster.name: log_cluster
#
# ------------------------------------ Node ------------------------------------
#
node.name: elk_master
#
# ----------------------------------- Paths ------------------------------------
#
path.data: /data/data
path.logs: /data/logs
#
network.host: 172.17.0.6
Fait, pour qu’ElasticSearch fonctionne, il nécessite que Java soit configuré. Ci-dessous les étapes pour installer et configurer Java sur le serveur.
[root@elk_master config]# wget --no-cookies --no-check-certificate --header "Cookie: gpw_e24=http%3A%2F%2Fwww.oracle.com%2F; oraclelicense=accept-securebackup-cookie" "http://download.oracle.com/otn-pub/java/jdk/8u131-b11/d54c1d3a095b4ff2b6607d096fa80163/jdk-8u131-linux-x64.rpm"
--2018-06-09 12:57:05-- http://download.oracle.com/otn-pub/java/jdk/8u131-b11/d54c1d3a095b4ff2b6607d096fa80163/jdk-8u131-linux-x64.rpm
Résolution de download.oracle.com (download.oracle.com)... 23.49.16.62
Connexion à download.oracle.com (download.oracle.com)|23.49.16.62|:80... connecté.
Requête HTTP envoyée, attente de réponse... 302 Déplacé temporairement
Emplacement : https://edelivery.oracle.com/otn-pub/java/jdk/8u131-b11/d54c1d3a095b4ff2b6607d096fa80163/jdk-8u131-linux-x64.rpm [suivant]
--2018-06-09 12:57:10-- https://edelivery.oracle.com/otn-pub/java/jdk/8u131-b11/d54c1d3a095b4ff2b6607d096fa80163/jdk-8u131-linux-x64.rpm
Résolution de edelivery.oracle.com (edelivery.oracle.com)... 104.103.48.174, 2600:1417:58:181::2d3e, 2600:1417:58:188::2d3e
Connexion à edelivery.oracle.com (edelivery.oracle.com)|104.103.48.174|:443... connecté.
Requête HTTP envoyée, attente de réponse... 302 Déplacé temporairement
Emplacement : http://download.oracle.com/otn-pub/java/jdk/8u131-b11/d54c1d3a095b4ff2b6607d096fa80163/jdk-8u131-linux-x64.rpm?AuthParam=1528549151_b1fd01d854bc0423600a83c36240028e [suivant]
--2018-06-09 12:57:11-- http://download.oracle.com/otn-pub/java/jdk/8u131-b11/d54c1d3a095b4ff2b6607d096fa80163/jdk-8u131-linux-x64.rpm?AuthParam=1528549151_b1fd01d854bc0423600a83c36240028e
Connexion à download.oracle.com (download.oracle.com)|23.49.16.62|:80... connecté.
Requête HTTP envoyée, attente de réponse... 200 OK
Longueur : 169983496 (162M) [application/x-redhat-package-manager]
Enregistrement dans : ‘jdk-8u131-linux-x64.rpm’
100%[==============================================================================>] 169,983,496 2.56MB/s dans 64s
2018-06-09 12:58:15 (2.54 MB/s) - ‘jdk-8u131-linux-x64.rpm’ enregistré [169983496/169983496]
[root@elk_master config]# yum localinstall -y jdk-8u131-linux-x64.rpm
[root@elk_master config]# vi /root/.bash_profile
export JAVA_HOME=/usr/java/jdk1.8.0_131
PATH=$JAVA_HOME/bin:$PATH:$HOME/bin
export PATH
[root@elk_master config]# . /root/.bash_profile
[root@elk_master config]# java -version
java version "1.8.0_131"
Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mode mixte)
Fait, maintenant elasticSearch a été installé et configuré sur le serveur. Pourtant, en raison de certaines politiques de sécurité, elasticSearch est interdit d’être exécuté par l’utilisateur root, nous allons donc créer un utilisateur supplémentaire pour être le propriétaire du service elasticSearch et l’exécuter. Ci-dessous les étapes pour créer l’utilisateur dédié à cela :
[root@elk_master config]# useradd -s /bin/bash shahril
[root@elk_master config]# passwd shahril
Changement de mot de passe pour l'utilisateur shahril.
Nouveau mot de passe :
MOT DE PASSE FAIBLE : Le mot de passe échoue à la vérification du dictionnaire - il est trop simpliste/systématique
Retapez le nouveau mot de passe :
passwd : tous les jetons d'authentification mis à jour avec succès.
[root@elk_master config]# chown -R shahril:shahril /data/
[root@elk_master config]# sysctl -w vm.max_map_count=262144
vm.max_map_count = 262144
Une fois terminé, connectez-vous en tant qu’utilisateur et vous pouvez démarrer les services elasticSearch.
[root@elk_master config]# su - shahril
Dernière connexion : Sam Juin 9 13:03:07 UTC 2018 sur pts/1
[shahril@elk_master ~]$
[shahril@elk_master ~]$
[shahril@elk_master ~]$
[shahril@elk_master ~]$ /opt/elasticsearch/bin/elasticsearch &
[1] 7295
[shahril@elk_master ~]$ [2018-06-09T13:06:26,667][INFO ][o.e.n.Node ] [elk_master] initialisation ...
[2018-06-09T13:06:26,721][INFO ][o.e.e.NodeEnvironment ] [elk_master] utilisant [1] chemins de données, montages [[/ (rootfs)]], espace utilisable net [394.3 Go], espace total net [468.2 Go], types [rootfs]
[2018-06-09T13:06:26,722][INFO ][o.e.e.NodeEnvironment ] [elk_master] taille de tas [990.7 Mo], pointeurs d'objet ordinaires compressés [true]
[2018-06-09T13:06:26,723][INFO ][o.e.n.Node ] [elk_master] nom du nœud [elk_master], ID du nœud [xjNoA9mMSGiXYmFPRNlXBg]
[2018-06-09T13:06:26,723][INFO ][o.e.n.Node ] [elk_master] version[6.2.1], pid[7295], build[7299dc3/2018-02-07T19:34:26.990113Z], OS[Linux/3.10.0-693.17.1.el7.x86_64/amd64], JVM[Oracle Corporation/Java HotSpot(TM) 64-Bit Server VM/1.8.0_131/25.131-b11]
[2018-06-09T13:06:26,723][INFO ][o.e.n.Node ] [elk_master] arguments JVM [-Xms1g, -Xmx1g, -XX:+UseConcMarkSweepGC, -XX:CMSInitiatingOccupancyFraction=75, -XX:+UseCMSInitiatingOccupancyOnly, -XX:+AlwaysPreTouch, -Xss1m, -Djava.awt.headless=true, -Dfile.encoding=UTF-8, -Djna.nosys=true, -XX:-OmitStackTraceInFastThrow, -Dio.netty.noUnsafe=true, -Dio.netty.noKeySetOptimization=true, -Dio.netty.recycler.maxCapacityPerThread=0, -Dlog4j.shutdownHookEnabled=false, -Dlog4j2.disable.jmx=true, -Djava.io.tmpdir=/tmp/elasticsearch.U6ilAwt9, -XX:+HeapDumpOnOutOfMemoryError, -XX:+PrintGCDetails, -XX:+PrintGCDateStamps, -XX:+PrintTenuringDistribution, -XX:+PrintGCApplicationStoppedTime, -Xloggc:logs/gc.log, -XX:+UseGCLogFileRotation, -XX:NumberOfGCLogFiles=32, -XX:GCLogFileSize=64m, -Des.path.home=/opt/elasticsearch, -Des.path.conf=/opt/elasticsearch/config]
[2018-06-09T13:06:27,529][INFO ][o.e.p.PluginsService ] [elk_master] module chargé [aggs-matrix-stats]
[2018-06-09T13:06:27,529][INFO ][o.e.p.PluginsService ] [elk_master] module chargé [analysis-common]
[2018-06-09T13:06:27,529][INFO ][o.e.p.PluginsService ] [elk_master] module chargé [ingest-common]
[2018-06-09T13:06:27,530][INFO ][o.e.p.PluginsService ] [elk_master] module chargé [lang-expression]
[2018-06-09T13:06:27,530][INFO ][o.e.p.PluginsService ] [elk_master] module chargé [lang-mustache]
[2018-06-09T13:06:27,530][INFO ][o.e.p.PluginsService ] [elk_master] module chargé [lang-painless]
[2018-06-09T13:06:27,530][INFO ][o.e.p.PluginsService ] [elk_master] module chargé [mapper-extras]
[2018-06-09T13:06:27,530][INFO ][o.e.p.PluginsService ] [elk_master] module chargé [parent-join]
[2018-06-09T13:06:27,530][INFO ][o.e.p.PluginsService ] [elk_master] module chargé [percolator]
[2018-06-09T13:06:27,531][INFO ][o.e.p.PluginsService ] [elk_master] module chargé [rank-eval]
[2018-06-09T13:06:27,532][INFO ][o.e.p.PluginsService ] [elk_master] module chargé [reindex]
[2018-06-09T13:06:27,532][INFO ][o.e.p.PluginsService ] [elk_master] module chargé [repository-url]
[2018-06-09T13:06:27,533][INFO ][o.e.p.PluginsService ] [elk_master] module chargé [transport-netty4]
[2018-06-09T13:06:27,533][INFO ][o.e.p.PluginsService ] [elk_master] aucun plugin chargé
Excellent, maintenant elasticSearch est opérationnel sans aucun problème, vous remarquerez que des ports supplémentaires sont établis sur le serveur liés au service elasticSearch. Vous pouvez vérifier les ports listés comme suit :
[root@elk_master config]# netstat -apn|grep -i :9
tcp 0 0 172.17.0.6:9200 0.0.0.0:* LISTEN 7295/java
tcp 0 0 172.17.0.6:9300 0.0.0.0:* LISTEN 7295/java
Maintenant, passons à la configuration et à l’installation des services logstash. Ci-dessous les étapes nécessaires pour le processus d’installation :
[root@elk_master opt]# wget https://artifacts.elastic.co/downloads/logstash/logstash-6.2.1.rpm
--2018-06-09 13:07:51-- https://artifacts.elastic.co/downloads/logstash/logstash-6.2.1.rpm
Résolution des artifacts.elastic.co (artifacts.elastic.co)... 107.21.253.15, 23.21.67.46, 107.21.237.188, ...
Connexion à artifacts.elastic.co (artifacts.elastic.co)|107.21.253.15|:443... connecté.
Requête HTTP envoyée, attente de réponse... 200 OK
Longueur : 140430729 (134M) [binary/octet-stream]
Enregistrement dans : ‘logstash-6.2.1.rpm’
100%[==============================================================================>] 140,430,729 2.19MB/s dans 60s
2018-06-09 13:08:57 (2.24 MB/s) - ‘logstash-6.2.1.rpm’ enregistré [140430729/140430729]
[root@elk_master opt]# yum localinstall -y logstash-6.2.1.rpm
Plugins chargés : fastestmirror, ovl
Examen de logstash-6.2.1.rpm : 1:logstash-6.2.1-1.noarch
Marquage de logstash-6.2.1.rpm pour installation
Résolution des dépendances
--> Exécution de la vérification de transaction
---> Package logstash.noarch 1:6.2.1-1 sera installé
--> Résolution des dépendances terminée
Dépendances résolues
========================================================================================================================
Package Arch Version Repository Size
========================================================================================================================
Installation :
logstash noarch 1:6.2.1-1 /logstash-6.2.1 224 M
Résumé de la transaction
========================================================================================================================
Installer 1 package
Taille totale : 224 M
Taille installée : 224 M
Téléchargement des paquets :
Exécution de la vérification de transaction
Exécution du test de transaction
Test de transaction réussi
Exécution de la transaction
Installation : 1:logstash-6.2.1-1.noarch 1/1
Utilisation du fichier startup.options fourni : /etc/logstash/startup.options
Script de démarrage système créé avec succès pour Logstash
Vérification : 1:logstash-6.2.1-1.noarch 1/1
Installé :
logstash.noarch 1:6.2.1-1
Terminé !
Une fois l’installation terminée, appliquez la configuration nécessaire comme suit :
[root@elk_master opt]# vi /etc/logstash/conf.d/02-mysql-log.conf
input {
beats {
port => 5044
host => "0.0.0.0"
}
}
filter {
if [fileset][module] == "mysql" {
if [fileset][name] == "error" {
grok {
match => { "message" => ["%{LOCALDATETIME:[mysql][error][timestamp]} (\[%{DATA:[mysql][error][level]}\] )?%{GREEDYDATA:[mysql][error][message]}",
"%{TIMESTAMP_ISO8601:[mysql][error][timestamp]} %{NUMBER:[mysql][error][thread_id]} \[%{DATA:[mysql][error][level]}\] %{GREEDYDATA:[mysql][error][message1]}",
"%{GREEDYDATA:[mysql][error][message2]}"] }
pattern_definitions => {
"LOCALDATETIME" => "[0-9]+ %{TIME}"
}
remove_field => "message"
}
mutate {
rename => { "[mysql][error][message1]" => "[mysql][error][message]" }
}
mutate {
rename => { "[mysql][error][message2]" => "[mysql][error][message]" }
}
date {
match => [ "[mysql][error][timestamp]", "ISO8601", "YYMMdd H:m:s" ]
remove_field => "[mysql][error][time]"
}
}
else if [fileset][name] == "slowlog" {
grok {
match => { "message" => ["^# User@Host: %{USER:[mysql][slowlog][user]}(\[[^\]]+\])? @ %{HOSTNAME:[mysql][slowlog][host]} \[(IP:[mysql][slowlog][ip])?\](\s*Id:\s* %{NUMBER:[mysql][slowlog][id]})?\n# Query_time: %{NUMBER:[mysql][slowlog][query_time][sec]}\s* Lock_time: %{NUMBER:[mysql][slowlog][lock_time][sec]}\s* Rows_sent: %{NUMBER:[mysql][slowlog][rows_sent]}\s* Rows_examined: %{NUMBER:[mysql][slowlog][rows_examined]}\n(SET timestamp=%{NUMBER:[mysql][slowlog][timestamp]};\n)?%{GREEDYMULTILINE:[mysql][slowlog][query]}"] }
pattern_definitions => {
"GREEDYMULTILINE" => "(.|\n)*"
}
remove_field => "message"
}
date {
match => [ "[mysql][slowlog][timestamp]", "UNIX" ]
}
mutate {
gsub => ["[mysql][slowlog][query]", "\n# Time: [0-9]+ [0-9][0-9]:[0-9][0-9]:[0-9][0-9](\\.[0-9]+)?$", ""]
}
}
}
output {
elasticsearch {
hosts => "172.17.0.6"
manage_template => false
index => "%{[@metadata][beat]}-%{[@metadata][version]}-%{+YYYY.MM.dd}"
}
}
Notez que dans la configuration ci-dessus, nous avons défini l’entrée à être prise à partir du service filebeat côté client qui utilise le port 5044. Nous avons également défini une annotation appropriée pour logstash afin d’aligner les données brutes prises de chaque côté client. Cela est nécessaire afin qu’il soit plus facile d’être visualisé et analysé du côté d’elasticSearch.
Ensuite, nous devons installer le module filebeats pour logstash afin que logstash puisse capturer et explorer les données brutes du côté client.
[root@elk_master opt]# /usr/share/logstash/bin/logstash-plugin install logstash-input-beats
Validant logstash-input-beats
Installation réussie
Comme l’installation et la configuration nécessaires pour logstash sont terminées, nous pouvons démarrer les services directement. Ci-dessous les étapes :
[root@elk_master opt]# service logstash restart
Redirection vers /bin/systemctl restart logstash.service
[root@elk_master opt]# service logstash status
Redirection vers /bin/systemctl status logstash.service
? logstash.service - logstash
Chargé : chargé (/etc/systemd/system/logstash.service; désactivé; prédéfini du fournisseur : désactivé)
Actif : actif (en cours d'exécution) depuis Sam 2018-06-09 13:17:40 UTC; 5s ago
PID principal : 8106 (java)
CGroup: /docker/2daaf895e0efa67ef70dbabd87b56d53815e94ff70432f692385f527e2dc488b/system.slice/logstash.service
??8106 /bin/java -Xms256m -Xmx1g -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFracti...
Jun 09 13:17:40 elk_master systemd[1]: Démarré logstash.
Jun 09 13:17:40 elk_master systemd[1]: Démarrage de logstash...
[root@elk_master opt]#
[root@elk_master opt]# tail -f /var/log/logstash/logstash-plain.log
[2018-06-09T13:17:59,496][INFO ][logstash.outputs.elasticsearch] URLs de pool Elasticsearch mises à jour {:changes=>{:removed=>[], :added=>[http://172.17.0.6:9200/]}}
[2018-06-09T13:17:59,498][INFO ][logstash.outputs.elasticsearch] Exécution d'une vérification de santé pour voir si une connexion Elasticsearch fonctionne {:healthcheck_url=>http://172.17.0.6:9200/, :path=>"/"}
[2018-06-09T13:17:59,976][WARN ][logstash.outputs.elasticsearch] Connexion restaurée à l'instance ES {:url=>"http://172.17.0.6:9200/"}
[2018-06-09T13:18:00,083][INFO ][logstash.outputs.elasticsearch] Version de sortie ES déterminée {:es_version=>nil}
[2018-06-09T13:18:00,083][WARN ][logstash.outputs.elasticsearch] Cluster 6.x et supérieur détecté : le champ d'événement `type` ne sera pas utilisé pour déterminer le type de document {:es_version=>6}
[2018-06-09T13:18:00,095][INFO ][logstash.outputs.elasticsearch] Nouvelle sortie Elasticsearch {:class=>"LogStash::Outputs::ElasticSearch", :hosts=>["//172.17.0.6"]}
[2018-06-09T13:18:00,599][INFO ][logstash.inputs.beats ] Entrées Beats : Démarrage de l'écouteur d'entrée {:address=>"0.0.0.0:5044"}
[2018-06-09T13:18:00,652][INFO ][logstash.pipeline ] Pipeline démarré avec succès {:pipeline_id=>"main", :thread=>"#"}
[2018-06-09T13:18:00,663][INFO ][org.logstash.beats.Server] Démarrage du serveur sur le port : 5044
[2018-06-09T13:18:00,660][INFO ][logstash.agent ] Pipelines en cours d'exécution {:count=>1, :pipelines=>["main"]}
[2018-06-09T13:18:24,060][INFO ][o.e.c.m.MetaDataCreateIndexService] [elk_master] [filebeat-6.2.1-2018.06.04] création d'index, cause [auto(bulk api)], templates [], shards [5]/[1], mappings []
[2018-06-09T13:18:24,189][INFO ][o.e.c.m.MetaDataCreateIndexService] [elk_master] [filebeat-6.2.1-2018.06.09] création d'index, cause [auto(bulk api)], templates [], shards [5]/[1], mappings []
[2018-06-09T13:18:24,288][INFO ][o.e.c.m.MetaDataCreateIndexService] [elk_master] [filebeat-6.2.1-2018.06.08] création d'index, cause [auto(bulk api)], templates [], shards [5]/[1], mappings []
[2018-06-09T13:18:24,591][INFO ][o.e.c.m.MetaDataMappingService] [elk_master] [filebeat-6.2.1-2018.06.04/yPD91Ww0SD2ei4YI-FgLgQ] create_mapping [doc]
[2018-06-09T13:18:24,781][INFO ][o.e.c.m.MetaDataMappingService] [elk_master] [filebeat-6.2.1-2018.06.08/Qnv0gplFTgW0z1C6haZESg] create_mapping [doc]
[2018-06-09T13:18:24,882][INFO ][o.e.c.m.MetaDataMappingService] [elk_master] [filebeat-6.2.1-2018.06.09/dihjTJw3SjGncXYln2MXbA] create_mapping [doc]
[2018-06-09T13:18:24,996][INFO ][o.e.c.m.MetaDataMappingService] [elk_master] [filebeat-6.2.1-2018.06.09/dihjTJw3SjGncXYln2MXbA] update_mapping [doc]
Comme vous pouvez le voir, maintenant le service logstash a démarré avec succès et commence à collecter les données de chaque côté client. En alternative, vous pouvez utiliser la commande curl pour voir l’état et les mises à jour du côté logstash. Ci-dessous les exemples :
[root@elk_master opt]# curl -kL http://172.17.0.6:9200/_cat/indices?v
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
yellow open filebeat-6.2.1-2018.06.09 dihjTJw3SjGncXYln2MXbA 5 1 6 0 35.2kb 35.2kb
yellow open filebeat-6.2.1-2018.06.04 yPD91Ww0SD2ei4YI-FgLgQ 5 1 350 0 186.4kb 186.4kb
yellow open filebeat-6.2.1-2018.06.08 Qnv0gplFTgW0z1C6haZESg 5 1 97 0 89.4kb 89.4kb
Dernier point mais non des moindres, nous devrons configurer et installer les services kibana pour compléter le serveur de gestion centralisé. Juste une note, comme kibana est utilisé pour faciliter le processus de collecte et d’analyse des données via la visualisation, ce n’est pas un paquet aussi important qu’elasticSearch ou logstash si vous configurez le serveur sous une machine plus petite. Pourtant, pour continuer, ci-dessous les étapes d’installation et de configuration :
[root@elk_master opt]# wget https://artifacts.elastic.co/downloads/kibana/kibana-6.2.1-linux-x86_64.tar.gz
--2018-06-09 13:21:41-- https://artifacts.elastic.co/downloads/kibana/kibana-6.2.1-linux-x86_64.tar.gz
Résolution des artifacts.elastic.co (artifacts.elastic.co)... 107.21.237.188, 107.21.237.95, 107.21.253.15, ...
Connexion à artifacts.elastic.co (artifacts.elastic.co)|107.21.237.188|:443... connecté.
Requête HTTP envoyée, attente de réponse... 200 OK
Longueur : 83465500 (80M) [binary/octet-stream]
Enregistrement dans : ‘kibana-6.2.1-linux-x86_64.tar.gz’
100%[==============================================================================>] 83,465,500 2.76MB/s dans 41s
2018-06-09 13:22:28 (1.94 MB/s) - ‘kibana-6.2.1-linux-x86_64.tar.gz’ enregistré [83465500/83465500]
[root@elk_master opt]# tar -zxvf kibana-6.2.1-linux-x86_64.tar.gz
[root@elk_master opt]# ln -s /opt/kibana-6.2.1-linux-x86_64 /opt/kibana
[root@elk_master opt]# vi kibana/config/kibana.yml
server.host: "172.17.0.6"
server.port: 5601
elasticsearch.url: "http://172.17.0.6:9200"
Notez ci-dessus que j’ai lié kibana avec notre service ElasticSearch à l’intérieur de la configuration et assigné un port qui sera utilisé par le service Kibana une fois démarré. Maintenant que tout est déjà en place, nous pouvons démarrer les services finaux. Ci-dessous les étapes :
[root@elk_master opt]# /opt/kibana/bin/kibana --version
6.2.1
[root@elk_master opt]# /opt/kibana/bin/kibana &
[1] 8640
[root@elk_master opt]# log [13:26:20.034] [info][status][plugin:[email protected]] Statut changé de non initialisé à vert - Prêt
log [13:26:20.073] [info][status][plugin:[email protected]] Statut changé de non initialisé à jaune - En attente d'Elasticsearch
log [13:26:20.193] [info][status][plugin:[email protected]] Statut changé de non initialisé à vert - Prêt
log [13:26:20.200] [info][status][plugin:[email protected]] Statut changé de non initialisé à vert - Prêt
log [13:26:20.212] [info][status][plugin:[email protected]] Statut changé de non initialisé à vert - Prêt
log [13:26:20.233] [info][listening] Serveur en cours d'exécution à http://172.17.0.6:5601
log [13:26:20.276] [info][status][plugin:[email protected]] Statut changé de jaune à vert - Prêt
[root@elk_master opt]# netstat -apn|grep -i :5601
tcp 0 0 172.17.0.6:5601 0.0.0.0:* LISTEN 8640/node
Super, maintenant tout est opérationnel comme montré ci-dessus en utilisant la commande netstat. Maintenant, voyons le tableau de bord de Kibana et faisons la configuration. Allez à l’URL http://172.17.0.6:5601/app, vous verrez que le tableau de bord sera affiché comme ci-dessous.
Ensuite, sur le tableau de bord, cliquez sur l’onglet Gestion, puis définissez le modèle d’index, pour notre cas, le modèle d’index est défini comme notre nom de fichier de journal généré. Tapez les informations puis cliquez sur suivant.
Après cela, tapez les variables qui seront utilisées comme séries temporelles. Une fois terminé, cliquez sur Créer le modèle d’index. Ci-dessous un exemple :
Excellent, maintenant le serveur de gestion est prêt à être utilisé. Passons à l’étape de test.
4. Phase de test
Avant de commencer le test, faisons l’hypothèse des résultats finaux attendus. Pour ce test, nous allons essayer d’exécuter une requête de base de données qui dépassera le temps de requête longue assigné du côté client qui est le serveur MySQL. Une fois que nous exécutons, notre serveur de gestion centralisé devrait automatiquement afficher le résultat des informations de requête lente sous forme de graphique via le tableau de bord Kibana. Maintenant que tout est clair, commençons le test, ci-dessous les étapes :
Connectez-vous à l’un des serveurs clients et exécutez la requête SQL lente comme ci-dessous :
[root@mysql_db1 ~]# mysql --login-path=root -P 3306 --prompt='TEST>'
Bienvenue dans le moniteur MySQL. Les commandes se terminent par ; ou \g.
Votre ID de connexion MySQL est 193
Version du serveur : 5.7.21-log Serveur communautaire MySQL (GPL)
Copyright (c) 2000, 2018, Oracle et/ou ses filiales. Tous droits réservés.
Oracle est une marque déposée d'Oracle Corporation et/ou de ses
filiales. D'autres noms peuvent être des marques de leurs propriétaires respectifs.
Tapez 'help;' ou '\h' pour obtenir de l'aide. Tapez '\c' pour effacer l'instruction d'entrée actuelle.
TEST>select sleep(5);
+----------+
| sleep(5) |
+----------+
| 0 |
+----------+
1 ligne dans l'ensemble (5.01 sec)
TEST>select sleep(6);
+----------+
| sleep(6) |
+----------+
| 0 |
+----------+
1 ligne dans l'ensemble (6.00 sec)
TEST>select sleep(10) 'exécuter pendant 10 secondes';
+--------------------+
| exécuter pendant 10 secondes |
+--------------------+
| 0 |
+--------------------+
1 ligne dans l'ensemble (10.00 sec)
TEST>select sleep(3) 'tester à nouveau';
+------------+
| tester à nouveau |
+------------+
| 0 |
+------------+
1 ligne dans l'ensemble (3.00 sec)
TEST>exit
Au revoir
Comme indiqué ci-dessus, nous avons réussi à produire certaines requêtes lentes qui ont été automatiquement consignées dans chaque journal de requêtes lentes du client. Maintenant, allons sur le tableau de bord et voyons si les informations de données ont été correctement collectées par le serveur centralisé et converties en graphique de visualisation.
Super, comme indiqué ci-dessus, il y a une liste d’informations de journal qui ont été correctement collectées et visualisées via le tableau de bord kibana. Vous pouvez utiliser l’onglet gauche pour filtrer quel type de colonne vous souhaitez afficher ou masquer, ci-dessous un exemple :-
En utilisant le champ de texte en haut du tableau de bord, vous pouvez taper une requête SQL liée pour afficher certaines informations ou parties des données nécessaires.
Excellent, comme montré ci-dessus, la requête SQL lente que nous avons produite initialement à partir de l’un de nos serveurs clients est automatiquement affichée sous notre tableau de bord Kibana comme prévu.
Recevez de nouveaux articles dans votre boîte de réception.
Aucun spam. Désabonnez-vous à tout moment.