L'analyse de logs
Les logs sont l'une des informations les plus précieuses en matière de
gestion et de surveillance des systèmes informatiques. Comme ils
enregistrent toutes les actions qui ont eu lieu sur une machine, ils
fournissent des informations dont vous avez besoin pour repérer les
problèmes susceptibles d'avoir un impact sur les performances,
la conformité et la sécurité des éléments de votre infrastructure. C'est
pourquoi la gestion des logs devrait faire partie de toute infrastructure de
surveillance.
Lorsqu'on parle d'analyse de logs, le plus important défi consiste à
regrouper, normaliser, visualiser et analyser vos logs dans un emplacement
unique et accessible, d'où l'utilisation de la suite ELK.
Qu'est-ce que l'analyse des logs?
L'analyse de logs est le processus consistant à donner du sens aux
messages de logs générés par votre système dans le but d'utiliser ces
données pour améliorer ou résoudre des problèmes de performances au
sein d'une application ou d'une infrastructure. Dans une vue d'ensemble,
les entreprises analysent les logs pour atténuer les risques de manière
proactive et réactive, se conformer aux politiques de sécurité, aux audits et
aux réglementations, et permet également de mieux comprendre le
comportement de vos utilisateurs utilisant vos applications.
Pourquoi l'analyse des logs est-elle
importante?
La plupart des entreprises sont tenues responsable d'effectuer l'archivage
et l'analyse des logs dans le cadre de leurs réglementations de conformité.
Ils doivent régulièrement surveiller et analyser les logs des systèmes pour
rechercher des erreurs, des anomalies ou des activités suspectes ou non
autorisées qui s'écartent de la norme. Cela leur permet de recréer la chaîne
d'événements qui a conduit à un problème et de le résoudre efficacement.
Par exemple, vous pourrez rechercher des erreurs HTTP et comprendre où
et pourquoi elles se sont produites ou détecter si les utilisateurs ne
reçoivent pas les informations recherchées ou si le chargement de leurs
demandes prend trop de temps, ou si certains microservices rencontrent
des problèmes, etc ...
Lorsque vous tirez parti de l'analyse des logs, vous pouvez détecter les
problèmes avant ou lorsqu'ils surviennent et éviter le gaspillage de temps,
les retards inutiles et les coûts supplémentaires qui vont avec. Ainsi, les
équipes peuvent intervenir et résoudre les problèmes plus rapidement,
leurs permettant ainsi de se concentrer davantage sur l'amélioration des
fonctionnalités existantes et sur l'ajout de nouvelles fonctionnalités aux
produits et services qu'ils créent au lieu de passer du temps à dépanner
manuellement. Cela, à son tour, augmente la valeur des logiciels qu'ils
construisent et conduit à des versions plus fréquentes (DevOps) et
augmente la valeur globale pour l'entreprise.
Meilleures pratiques d'analyse des
logs
L'analyse des logs est un processus complexe qui doit suivre les bonnes
pratiques suivantes :
La détection et la reconnaissance des patterns : cela fait référence au
filtrage des messages entrants sur la base d'un pattern souvent combiné
avec l'utilisation des expressions régulières. Elle fait partie intégrante de
l'analyse des logs car elle permet de détecter plus rapidement les
anomalies.
La normalisation des logs : ce sont le processus de conversion des
éléments de logs tels que les adresses IP ou les horodatages, dans un
format commun pour toutes vos équipes.
La classification et le balisage : ce sont le processus de balisage (tag)
des messages avec des mots-clés et de leur catégorisation en classes. Cela
vous permet de filtrer et de personnaliser la façon dont vous visualisez les
données.
L'analyse de corrélation : fait référence à la collecte de données
provenant de différentes sources et à la recherche de messages
appartenant à un événement spécifique. Par exemple, en cas d'activité
malveillante, il vous permet de filtrer et de corréler les logs provenant de
vos périphériques réseaux, pare-feu, serveurs et autres sources afin de très
rapidement détecter la source du problème.
Alerte : L'analyse de corrélation est généralement associée aux systèmes
d'alerte, en fonction du pattern que vous avez identifié, vous pouvez créer
des alertes lorsque votre analyseur de logs détecte une activité anormale.
ELK
La stack ELK est un ensemble de trois outils open source qui sont souvent utilisés
ensemble pour collecter, analyser et visualiser des données de logs en temps réel.
Ces outils sont Elasticsearch, Logstash et Kibana.
Elasticsearch est un moteur de recherche open source qui permet de stocker,
indexer et rechercher rapidement de grandes quantités de données structurées ou
non structurées.
Logstash est un outil de collecte de données qui peut être utilisé pour lire des
fichiers de logs, extraire des informations et les envoyer à Elasticsearch pour
stockage et indexation.
Kibana est une interface de visualisation de données qui permet de créer des
tableaux de bord et des visualisations à partir des données stockées dans
Elasticsearch. Vous pouvez utiliser Kibana pour explorer vos données de logs, trouver
des tendances et identifier des problèmes.
La stack ELK est souvent utilisée pour l’analyse de logs de serveurs, d’applications et
de réseaux, mais elle peut également être utilisée pour analyser tout type de
données structurées ou non structurées.
il existe plusieurs façons de le déployer :
La première option consiste à installer chacun des composants ELK individuellement sur votre hôte
avec toutes leurs dépendances et exigences (nginx, jre, etc.), puis à configurer tous les composants
pour qu'ils communiquent entre eux. Cette méthode offre plus de flexibilité lorsqu'il s'agit de
configurer votre logiciel. mais peut être très compliqué à mettre en place au départ et peut
nécessiter l'intervention d'experts pour garantir la fiabilité et la sécurité de votre déploiement.
La deuxième option consiste à installer chaque composant séparément mais en utilisant des images
Docker : cette méthode est relativement plus simple que la première option mais nécessite tout de
même beaucoup de configuration pour répondre aux besoins de votre entreprise et pour rendre
votre déploiement fiable et sécurisé.
La troisième option consiste à utiliser une image Docker préconfigurée contenant les trois
composants (Elasticsearch, Logstach et Kibana), celle-ci est très facile à déployer et ne nécessite
presque aucune configuration, cette méthode est recommandée uniquement pour les Tps.
Installation et configuration de la stack
ELK
La stack ELK peut être installée à l'aide d'une variété de méthodes et
sur un large éventail de systèmes d'exploitation et
d'environnements différents. Vous pouvez installer ELK localement,
sur le cloud, à l'aide de Docker et de systèmes de gestion de configuration
comme Ansible, Puppet et Chef. La pile peut être également installée à
l'aide de votre gestionnaire de paquets ou manuellement depuis les
binaires officiels. Voici le lien pour la page officielle des multiples méthodes
d'installation d'ELK.
De nombreuses étapes d'installation sont similaires d'un environnement à
l'autre et comme nous ne pouvons pas couvrir tous les différents scénarios,
je vais vous fournir un exemple d' installation de tous les composants
de la pile Elasticsearch, Logstash, Kibana sous une seule machine
Linux à l'aide du gestionnaire de paquets APT et UUM afin de posséder et
de gérer les dernières versions des composants.
Information
Pour ceux travaillant sur une machine Windows, veuillez créer une machine
virtuelle afin de poursuivre du mieux ce cours.
À savoir
Lors de l'installation d'ELK, vous devez utiliser la même version sur
l'ensemble de la pile. Par exemple, si vous utilisez Elasticsearch 7.8.0 alors
Kibana doit être aussi sous sa version 7.8.0 et même pour pour Logstash en
version 7.8.0.
Si vous mettez à niveau une installation existante, consultez la page
officielle de Mise à niveau de la pile ELK.
Ordre d'installation
Pour installer les produits ELK il est recommandé de respecter l'ordre
suivant afin de garantir que les composants dont chaque produit dépend
sont résolus :
1. Elasticsearch
2. Kibana
3. Logstash
Installation
Elasticsearch
Installation
Tout d'abord, vous devez ajouter la clé de signature d'Elastic pour que le
package téléchargé puisse être vérifié (ignorez cette étape si vous avez
déjà installé des packages d'Elastic):
Sous la famille debian :
wget -qO - [Link] |
sudo apt-key add -Copier
Sous la famille redhat :
rpm --import [Link]
elasticsearchCopier
Si vous êtes sur une machine de la famille de Debian, vous devez installer
le paquet apt-transport-https :
sudo apt-get install apt-transport-httpsCopier
L'étape suivante consiste à ajouter le dépôt Elasticsearch sur votre système
:
Sous la famille debian :
echo "deb [Link] stable
main" | sudo tee -a /etc/apt/[Link].d/elastic-
[Link]
Sous la famille redhat, créez un fichier et nommé le par
exemple [Link] dans le répertoire /etc/[Link].d/, contenant:
[elasticsearch]
name=Elasticsearch repository for 7.x packages
baseurl=[Link]
gpgcheck=1
gpgkey=[Link]
enabled=0
autorefresh=1
type=rpm-mdCopier
Il ne vous reste plus qu'à mettre à jour vos référentiels et installer
Elasticsearch:
Sous la famille debian :
sudo apt-get update -y && sudo apt-get install
elasticsearchCopier
Sous la famille redhat :
sudo yum install --enablerepo=elasticsearch elasticsearchCopier
Configuration
Par défaut à son lancement Elasticsearch consomme 1go de mémoire de la
JVM (machine virtuelle java), si votre machine n'est pas assez puissante
vous pouvez modifier les valeurs Xms et Xmx situé dans le
fichier /etc/elasticsearch/[Link] pour une consommation réduite:
# Avant (1go)
-Xms1g
-Xmx1g
# Après (512 mo)
-Xms512mo
-Xmx512moCopier
Les configurations Elasticsearch sont effectuées à l'aide du fichier de
configuration /etc/elasticsearch/[Link] qui vous permet de
configurer les paramètres généraux comme par exemple le nom du nœud,
ainsi que les paramètres réseau comme par exemple l'hôte et le port,
l'emplacement des données stockées, la mémoire, les fichiers de logs, etc...
Pour ce cours nous laisserons la configuration par défaut.
Lancement et test
Pour exécuter Elasticsearch, utilisez la commande suivante (l'initialisation
peut prendre un peu de temps) :
sudo systemctl start elasticsearchCopier
Si jamais vous rencontrez des problèmes d'initialisation, veuillez vérifier les
logs du service elasticsearch à l'aide de la commande suivante :
sudo journalctl -f -u elasticsearchCopier
Pour confirmer que tout fonctionne comme prévu, pointez votre commande
curl ou votre navigateur sur l'adresse [Link] et vous devriez
voir quelque chose comme la sortie suivante :
curl localhost:9200Copier
Résultat :
"name" : "hatim-linux",
"cluster_name" : "elasticsearch",
"cluster_uuid" : "U1zH_yFqTUmdMRckR1gHLQ",
"version" : {
"number" : "7.8.0",
"build_flavor" : "default",
"build_type" : "deb",
"build_hash" : "757314695644ea9a1dc2fecd26d1a43856725e65",
"build_date" : "2020-06-14T[Link].234439Z",
"build_snapshot" : false,
"lucene_version" : "8.5.1",
"minimum_wire_compatibility_version" : "6.8.0",
"minimum_index_compatibility_version" : "6.0.0-beta1"
},
"tagline" : "You Know, for Search"
Pour initialiser le service à chaque démarrage de la machine, lancez la
commande suivante :
sudo systemctl enable elasticsearchCopier
kibana
Installation
Puisque nous avons déjà défini le dépôt dans le système, tout ce que nous
avons à faire pour installer kibana est d'exécuter la commande suivante:
Sous la famille debian :
sudo apt-get install kibanaCopier
Sous la famille redhat :
sudo yum install kibanaCopier
configuration
Le fichier de configuration de kibana se retrouve
dans /etc/kibana/[Link] . Si jamais vous avez modifié avec ce fichier,
assurez-vous juste que la configuration kibana possède les bonnes
informations pour communiquer avec Elasticsearch :
[Link]: ["[Link]
Lancement et test
Voici la commande pour démarrer Kibana :
sudo systemctl start kibanaCopier
Si jamais vous rencontrez des problèmes d'initialisation, veuillez vérifier les
logs du service kibana comme suit :
sudo journalctl -f -u kibanaCopier
Pour tester Kibana, ouvrez dans votre navigateur
l'url [Link] afin de voir la page d'accueil Kibana :
Pour initialiser le service Kibana à chaque démarrage de la machine, lancez
la commande suivante :
sudo systemctl enable kibanaCopier
Logstash
Installation
Logstash nécessite au minimum la version 8 de java pour fonctionner, nous
allons donc commencer le processus de configuration de Logstash avec:
Sous la famille debian :
sudo apt-get install default-jreCopier
Sous la famille redhat, java 8 :
yum install java-11-openjdk.x86_64
# ou java 8
yum install java-1.8.0-openjdk.x86_64Copier
Enfin, vérifiez que java est installé:
java -versionCopier
Résultat :
openjdk version "11.0.7" 2020-04-14
...
Comme pour kibana, puisque nous avons déjà défini le dépôt dans le
système, tout ce que nous avons à faire pour installer Logstash est
d'exécuter:
Sous la famille debian :
sudo apt-get install logstashCopier
Sous la famille redhat :
sudo yum install logstashCopier
Configuration
Le fichier de configuration de Logstash est le
suivant : /etc/logstash/[Link] et permet de configurer des paramètres
généraux comme par exemple le nom du nœud, le port, le niveau des logs
etc... Pour ce cours nous laisserons la configuration par défaut.
Lancement et test
Voici la commande pour démarrer logstash :
sudo systemctl start logstashCopier
Si jamais vous rencontrez des problèmes d'initialisation, vérifiez les logs du
service Logstash comme suit :
sudo journalctl -f -u logstashCopier
Pour initialiser le service à chaque démarrage de la machine, lancez la
commande suivante :
sudo systemctl enable logstashCopier
Pour tester votre installation Logstash, vous devez configurer un pipeline de
données.
Utilisation de la stack ELK sur les logs
Apache
Prérequis
Pour bien suivre cet article, vous devez au préalable installer et démarrer le
package d'Apache sur votre machine ELK. Pour cela, lancez les commandes
suivantes :
Pour la famille Debian :
sudo apt-get install -y apache2Copier
Pour la famille Redhat :
sudo yum install -y httpdCopier
Utilisez l'outil systemctl pour démarrer le service Apache :
Pour la famille Debian :
sudo systemctl start apache2Copier
Pour la famille Redhat :
sudo systemctl start httpdCopier
Enfin, très important, n'oubliez pas de rajouter l'utilisateur logstash au
groupe adm :
sudo usermod -aG adm logstashCopier
Information
Le groupe d'utilisateurs adm est utilisé pour permettre à ses membres de
lire le contenu des fichiers de logs.
Logstash
La première étape à effectuer est le traitement des logs sous forme d'un ou
plusieurs pipelines avec l'outil Logstash.
Comment fonctionne de Logstash ? Il est capable d'extraire des
données de presque n'importe quelle source de données à l'aide des
plugins d'entrée, et d'appliquer une grande variété de transformations et
d'améliorations de données à l'aide de plugins de filtre et enfin d'expédier
ces données vers un grand nombre de destinations à l'aide de plugins de
sortie. Vous comprendrez alors que Logstash joue un rôle très important
dans la pile en récupérant, filtrant et expédiant vos données afin de les
utiliser plus facilement sur le reste des composants.
Pour utiliser Logstash, il faut créer des fichiers de configuration qui
contiendront trois sections principales que nous allons par passer en revue
ci-dessous. À savoir que chacune de ces sections est responsable de
différentes fonctions et utilisant différents plugins Logstash.
Commencez déjà par créer un fichier [Link] dans le dossier de
configuration Logstash situé dans /etc/logstash/conf.d/ et rajoutez-y les trois
sections de configuration principales qui seront pour le moment vide :
input {}
filter {}
output {}Copier
Entrées Logstash
Les points de départ de toute configuration Logstash sont vos entrées. Les
entrées sont des plugins Logstash responsables de la récupération des
données de différentes sources de données. Vous trouverez l'intégralité des
plugins d'entrée ici. Pour notre exemple, nous avons besoin de récupérer
les données depuis un fichier donc nous utiliserons le plugin d'entrée file ,
comme suit :
Pour la famille debian :
input {
file { path => "/var/log/apache2/[Link]" }
...Copier
Pour la famille redhat :
input {
file { path => "/var/log/[Link]" }
...Copier
En regardant la documentation du plugin d'entrée file , vous remarquerez
que vous pouvez utiliser différents paramètres pour cette entrée. Comme
par exemple, le paramètre start_position qui permet de choisir où
Logstash doit commencer sa lecture initiale des fichiers, soit au début ou à
la fin. La valeur par défaut est end qui traite les fichiers comme des flux
direct en temps réel (comme la commande tail -f) et comme son nom
l'indique, la lecture débutera à partir de la fin du fichier, mais si vous
souhaitez lire un fichier depuis le début, forcez alors la valeur à beginning :
input {
file {
path => "/var/log/apache2/[Link]"
start_position => "beginning"
sincedb_path => "/dev/null"
...Copier
Par défaut, logstash écrit la dernière position de lecture dans un fichier log
qui réside généralement dans $HOME/.sincedb ou dans le
dossier /var/lib/logstash/plugins/inputs/file/. Afin de forcer la relecture
complète d'un fichier à chaque exécution de logstash, il faut changer le
chemin du fichier de logs de position en
valorisant sincedb_path à /dev/null. Ou sinon vous pouvez supprimer
uniquement la ligne correspondante de votre fichier .sincedb et redémarrez
le service logstash.
Filtres Logstash
Les filtres sont des modules qui vont traiter les données récupérées depuis
l'input en s'aidant lui aussi de différents plugins de filtrage. Pour notre
exemple, nous utiliserons le plugin grok qui vous permet d'analyser
facilement des données de logs non structurées en quelque chose de plus
exploitable en utilisant des expressions régulières. Cet outil est parfait pour
tout format de logs généralement écrit pour les humains comme les logs
applicatifs (ex: mysql, apache, nginx, etc ...).
La syntaxe d'un pattern grok est la suivante :
%{SYNTAX:SEMANTIC}
SYNTAX : nom du pattern qui correspond à un filtre prédéfini, comme par
exemple le pattern NUMBER qui prend en compte des nombres tel quel 3 ou
3.55 ou le pattern IP qui correspond à une IP comme [Link].
SEMANTIC est l'identifiant de la valeur récupérée par votre SYNTAX.
Par exemple pour traiter la ligne de log suivante :
[Link] GET /[Link] 15824 0.043
Le pattern grok sera le suivant :
filter {
grok {
match => { "message" => "%{IP:client} %{WORD:method} %
{URIPATHPARAM:request} %{NUMBER:bytes} %{NUMBER:duration}" }
}Copier
Après traitement du filtre grok, nous obtiendrons les champs suivants :
client: [Link]
method: GET
request: /[Link]
bytes: 15824
duration: 0.043
Pour notre besoin, nous allons plutôt découvrir et utiliser des patterns
APACHE grok pré-configurés. Vous pouvez utiliser soit le
pattern COMMONAPACHELOG qui récupère des informations de base (IP source,
code HTTP, etc ...) ou le pattern COMBINEDAPACHELOG qui récupère des
informations supplémentaires comme le user-agent.
Information
Pour les plus curieux d'entre vous qui souhaitent connaître le pattern
complet de COMMONAPACHELOG et COMBINEDAPACHELOG , regardez la ligne sous
le commentaire "# Log formats" sur les sources de l'APACHE pattern.
Pour tester vos patterns, vous pouvez soit utiliser un plugin de sortie que
nous verrons dans la section suivante, ou bien utilisez un débogueur grok
en ligne, comme grokdebug. Pour utiliser l'exactitude d'exécution de votre
pattern sur votre débogueur, vous n'avez qu'à copier quelques lignes de
vos logs apaches :
# famille Debian
tail /var/log/apache2/[Link]
# famille Redhat
tail /var/log/[Link]
Résultat :
::1 - - [30/Jun/[Link] +0200] "GET / HTTP/1.1" 200 422
"-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/83.0.4103.116 Safari/537.36"
::1 - - [30/Jun/[Link] +0200] "GET / HTTP/1.1" 200 423
"-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/83.0.4103.116 Safari/537.36"
Une fois vos lignes de logs copiées, collez les dans votre débogueur avec
votre pattern du plugin grok (sans les doubles guillemets), exemple :
Vous obtiendrez ainsi le résultat suivant :
Cool notre pattern grok fonctionne! Revenons alors maintenant sur notre
fichier [Link] et complétons la section filtre, comme suit :
input {
file { path => "/var/log/apache2/[Link]" }
filter {
grok {
match => { "message" => "%{COMBINEDAPACHELOG}" }
date {
match => [ "timestamp" , "dd/MMM/yyyy:HH:mm:ss Z" ]
mutate {
convert => {
"response" => "integer"
"bytes" => "integer"
}Copier
J'ai fait exprès de rajouter deux nouveaux filtre date et mutate, car ils nous
serviront plus tard pour nos visualisations sur Kibana :
Par défaut, logstash basera son horodatage sur l'heure à laquelle l'entrée
du fichier de log a été lue et non sur l'horodatage fourni par le fichier de
logs Apache. D'où l'utilisation du filtre de date qui basera son horodatage
sur les dates des champs filtrés par grok, soit l'horodatage réel fourni par le
fichier de log Apache.
J'utilise également le filtre mutate avec l'action convert afin de convertir la
réponse HTTP et la taille de la requête qui sont par défaut en type string
vers le type entier, car en effet, Kibana gère ses visualisations
différemment selon le type de données que vous lui envoyez.
Sorties Logstash
Les points d'arrivée de toute configuration Logstash sont vos sorties, lui-
même utilise différents plugins de sortie qui envoient les données traitées
par la phase de filtrage à une destination particulière (ex: elasticsearch).
Par ailleurs, les sorties sont la dernière étape du pipeline Logstash.
Pour cet article, je vais vous dévoiler comment récupérer les
événements sur la sortie standard avec le plugin de sortie stdout avant
de les envoyer plus tard à elasticsearch. Le plugin stdout propose différents
formats de sortie, dans notre exemple nous utiliserons le format rubydebug,
comme ceci :
input {
file { path => "/var/log/apache2/[Link]" }
filter {
grok {
match => { "message" => "%{COMBINEDAPACHELOG}" }
date {
match => [ "timestamp" , "dd/MMM/yyyy:HH:mm:ss Z" ]
mutate {
convert => {
"response" => "integer"
"bytes" => "integer"
output {
stdout { codec => rubydebug }
}Copier
Debug
Dans cette partie je souhaite vous montrer comment vous pouvez debug
votre pipeline Logstash afin d'utiliser du mieux ce plugin, pour cela il faut
commencer par stopper le service logstash :
sudo systemctl stop logstashCopier
Ensuite, nous allons vérifier la syntaxe de notre code Logstash avec le
binaire logstash situé dans /usr/share/logstash/bin/logstash en utilisant
l'option -t ou l'option --config.test_and_exit :
Attention
Selon le type d'installation que vous avez choisi, le binaire logstash peut se
trouver dans un autre dossier.
sudo /usr/share/logstash/bin/logstash --[Link]
/etc/logstash -f /etc/logstash/conf.d/[Link] -tCopier
Résultat :
...
Configuration OK
[2020-06-30T[Link],834][INFO ][[Link]] ... Config
Validation Result: OK. Exiting Logstash
Information
Les différents options du binaire logstash sont disponibles ici.
Une fois la syntaxe validée, relancez la commande sans l'option -t mais
avec l'option --debug:
sudo /usr/share/logstash/bin/logstash --debug --
[Link] /etc/logstash -f
/etc/logstash/conf.d/[Link]
Visitez ensuite depuis votre navigateur la page d'accueil [Link] et
revenez sur la sortie standard de votre logstash pour observer le résultat
suivant :
"host" => "hatim-linux",
"ident" => "-",
"message" => "::1 - - [30/Jun/[Link] +0200] \"GET /
HTTP/1.1\" 200 423 \"-\" \"Mozilla/5.0 (X11; Linux x86_64)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.116
Safari/537.36\"",
"bytes" => "423",
"agent" => "\"Mozilla/5.0 (X11; Linux x86_64)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.116
Safari/537.36\"",
"response" => "200",
"timestamp" => "30/Jun/[Link] +0200",
"referrer" => "\"-\"",
"request" => "/",
"verb" => "GET",
"path" => "/var/log/apache2/[Link]",
"@timestamp" => 2020-06-30T[Link].000Z,
"clientip" => "::1",
"auth" => "-",
"httpversion" => "1.1",
"@version" => "1"
Passons maintenant à la communication avec elasticsearch.
ElasticSearch
Modifions ensuite notre fichier [Link] pour communiquer avec
elasticsearch :
input {
file { path => "/var/log/apache2/[Link]" }
filter {
grok {
match => { "message" => "%{COMBINEDAPACHELOG}" }
date {
match => [ "timestamp", "dd/MMM/yyyy:HH:mm:ss Z" ]
mutate {
convert => {
"response" => "integer"
"bytes" => "integer"
output {
elasticsearch {
hosts => "localhost:9200"
index => "apache-%{+[Link]}"
}Copier
Vous remarquerez que j'utilise un index dans le bloc de code de
sortie elasticsearch car c'est le moyen pour elasticsearch de structurer
ses données et de les gérer plus rapidement. Le nommage utilisé dans
notre index actuel est dynamique grâce au pattern %{+[Link]}, ce qui
aura pour effet de créer un index par jour, permettant à l'administrateur de
facilement s'y retrouver en affichant par exemple que les logs d'une date
précise dans Kibana, supprimer que les indexs d'une plage de dates , etc ...
N'oubliez pas de démarrer votre service logstash avec la commande
suivante :
sudo systemctl start logstashCopier
Après démarrage de votre service, logstash va lancer votre pipeline.
Ensuite vous pouvez vérifier si l'index s'est correctement créé, pour cela
appelez l'API REST fournie par elasticsearch, comme suit :
curl "localhost:9200/_cat/indices?v"Copier
Résultat :
yellow open apache-2020.06.30
Kibana
Index Patterns
Rendez-vous ensuite sur Kibana depuis l'url [Link] Pour
visualiser notre index, allez sur le menu à gauche et cliquez sur "Stack
Management" :
Par la suite, vous devez ajouter un pattern index dans kibana afin de
prendre en considération vos indexs quotidiens Apache récupérés par
elasticsearch. Cliquez sur "Index Patterns" sur le volet à gauche et cliquez
sur le bouton "Create index pattern" :
Dans notre cas le préfix de nos indexs apache est "apache-", donc le
pattern index à créer dans kibana sera apache-* :
Cliquez ensuite sur "Next Step". Ensuite il nous demande par quel moyen il
doit gérer le filtre temporel (timestamp). Ce filtre est utile pour filtrer et
affiner nos données par plage horaire. Nous avions prévu le coup sur notre
configuration logstash en créant un champ @timestamp, et c'est celui là
qu'on sélectionnera :
Enfin, cliquez sur le bouton "Create index pattern" et vous verrez apparaître
tous vos champs :
>
Découvrir vos logs
Pour découvrir vos logs, sur le menu à gauche cliquez sur Discover :
Ensuite, Faites quelques visites depuis votre navigateur sur la page
d'accueil d'apache [Link] et revenez sur la page de discover :
Vous avez également la possibilité de filtrer vos logs par champ depuis la
barre de recherche du Discover :
Exemple : "response : 404" pour n'afficher que les requêtes en erreur 404.
Dashboard
L'étape suivante est de créer un tableau de bord afin de visualiser
une collection de visualisations en temps réel. Pour commencer,
ouvrez le menu, accédez à Dashboard , puis cliquez sur "Create dashboard"
:
>
Pour ajouter des éléments à votre dashboard vous devez créer des
visualisations Kibana que vous pouvez déplacer et redimensionner dans
votre dashboard. Vous pouvez ajouter des visualisations à partir de
plusieurs indexs patterns et la même visualisation peut apparaître dans
plusieurs tableaux de bord.
Dans notre exemple nous allons commencer par créer une visualisation qui
permet d'afficher le nombre total d'utilisateurs unique. Pour ce faire, créez
une visualisation en cliquant sur "Create new" et dans la fenêtre de "New
visualisation" nous allons choisir le type de visualisation "Metric" :
Pour information, voici la liste des types de visualisations Kibana les
plus fréquemment utilisées :
Line, area, et bar charts : compare différentes métriques sur l'axe X et Y.
Pie chart : graphique circulaire.
Data table : données en format de tableau.
Metric : affiche une seule métrique.
Goal and gauge : affiche un nombre avec des indicateurs de progression.
Tag cloud : affiche les mots dans un nuage, où la taille du mot correspond
à son importance.
On vous demande ensuite de paramétrer votre visualisation, vous
devez choisir d'abord votre agrégation qui correspond aux métriques
extraient pour générer des valeurs de données. Voici les valeurs les plus
communes :
Average : valeur moyenne.
Count : nombre total de documents correspondant à une requête.
Max : la valeur la plus élevée.
Median : médiane.
Min : la valeur la plus basse.
Sum : La valeur totale.
Unique Count : nombre unique d'une métrique.
Information
Dans le langage Elasticsearch, un document correspond aux données JSON
sérialisées.
Dans notre cas, nous utiliserons l'agrégation Unique Count en utilisant le
champ host :
Cliquez ensuite sur "Save" et choisissez le nom de votre visualisation.
Rajoutons un autre graphique qui permet d'afficher la taille moyenne des
requêtes temporellement. Pour ce type de besoin nous aurons besoin d'une
visualisation de type "area". Pour l'axe Y nous allons utiliser une agrégation
de type "Average" sur le champ byte :
Pour l'axe X ça sera un peu différent car nous utiliserons les Bucket
aggregations qui trient les documents en compartiments selon le contenu
du document. Voici les valeurs les plus communes :
Date histogram : fractionne un champ de date en compartiments par
intervalle.
Date range : valeurs comprises dans une plage de dates que vous
spécifiez.
Filter : filtre les données récupérées (ex : traiter que les erreurs 404).
IPv4 range : plages d'adresses IPv4.
Range : plages de valeurs pour un champ numérique.
Terms : Spécifiez le nombre d'éléments supérieurs ou inférieurs d'un champ
donné à afficher, classés par nombre ou par une métrique personnalisée.
Pour notre cas nous utiliserons le type "Date histogram" :
Un dernier graphique avant de clôturer cet article. Nous allons cette fois-ci
afficher le top des requêtes en erreur sous forme d'un tableau. Créez une
nouvelle visualisation de type "Data table" avec comme configuration une
agrégation de type "Count" (par défaut) et une Bucket aggregation de type
"Terms" sur le champ "request" et trier par ordre décroissant par
l'agrégation "Count", ce qui nous affichera pour le moment que les pages
web les plus visitées. Cette partie de la configuration ressemblera à ceci :
Ensuite pour récupérer que les requêtes en erreur, nous filtrerons ces
requêtes si elles ont une réponse différente au code HTTP 200. Pour cela,
vous devez cliquer sur le bouton situé en haut à gauche nommée "+ Add
filter" et ajouter le filtre suivant :
Lorsque vous avez terminé d'ajouter et d'organiser les panneaux,
enregistrez le tableau de bord. Dans la barre d'outils Kibana, cliquez sur
"Save" et saisissez ensuite le titre du tableau de bord et la description
facultative , puis enregistrez votre tableau de bord.
Le dashboard final ressemble à ceci :
Conclusion
Dans ce chapitre nous avons appris à utiliser plus en profondeur la suite
ELK en partant d'un simple fichier de logs Apache à des données visuelles
graphiques en temps réels que vous pouvez manipuler comme vous le
souhaitez démontrant la puissance d'ELK et l'utilité d'une solution de
centralisation de journalisation.
