Metricbeat on Zwindler's Reflection

ElasticStack : Collecter et exploiter des métriques provenant de nginx

Tue, 10 Oct 2017 11:30:49 +0000

Comment collecter ? Les agents Beats à la rescousse

Dans l’article précédent, je vous ai donné la marche à suivre pour déployer ELK très simplement sur un même serveur. Je vous avais aussi expliqué la nouvelle architecture d’ElasticStack et notamment l’ajout des agents Beats, moins gourmands et plus spécialisés que Logstash.

Dans cet article je vais donc continuer où nous nous étions arrêté et faire un focus sur les agents Beats pour les intégrer à notre plateforme ELK existante.

Qui sont-ils ? Quels sont leurs réseaux ?

Et oui parce qu’il y en a plusieurs. Si vous avez lu précédent, vous savez qu’il existe pour la collecte de données, en plus de Logstash, des modules plus légers dont la fonction n’est que de récupérer les informations sur les noeuds que vous voulez surveiller (et rien de plus).

On a donc :

Filebeat, pour les fichiers de logs (texte)
Metricbeat, qui collecte tout un tas de métriques, notamment système, mais aussi provenant de Docker
Packetbeat, qui remonte des informations réseaux. Attention je parle d’informations très poussées sur les échanges réseaux, à la transaction près ! On peut faire de superbes graphiques et des analyses très poussées de flux réseaux intermachines… mais au prix d’un développement des dashboard assez complexe !
Winlogbeat, la même chose que Filebeat, mais sous Windows
Heartbeat, pour l’uptime (à quoi ça sert un module rien que pour ça et qui plus est pour l’afficher dans ELK… mystère?)

Vous trouverez plus d’informations sur le site officiel.

Collecte de données dans des fichiers plats avec Filebeat

Pour faire un exemple simple, on va commencer par utiliser Filebeat, le module dédié à la collecte de logs (documentation).

Filebeat (et les autres modules Beats) utilise des fichiers YAML pour savoir quoi faire. Là encore, je vous met à disposition mon playbook Ansible permettant d’installer simplement.

[A NOTER] Toute la configuration qui va suivre va être générée par le playbook ansible. Vous n’avez « rien » à faire mais je vous explique quand même ce que je fais histoire que vous puissiez reproduire vous même dans d’autre contexte. Le fameux poisson à pêcher proverbial, en somme.

mkdir -p /etc/ansible/roles && cd /etc/ansible/roles
git clone https://github.com/zwindler/ansible-deploy-filebeat-nginx

cd /etc/ansible
cat deploy_filebeat_for_nginx.yml
---
- name: Install filebeat for nginx
hosts: @ip_ou_hostname_du_serveur_nginx
vars:
- elk_server: @ip_de_votre_serveur_elk
roles:
- { role: ansible-deploy-filebeat-nginx }
ansible-playbook deploy_filebeat_for_nginx.yml

Le principe du playbook est de :

déployer sur un serveur avec nginx un collecteur filebeat
qui va remonter les informations au logstash qu’on a installé sur notre serveur ELK
qui sera lui même configuré pour traiter les données nginx
et les réinjecter dans elasticsearch

Tout ça en un ligne de commande. Elle est pas belle la vie ?

Logstash en coupure…

Mais pourquoi s’embêter et passer par Logstash quand Filebeat envoie les logs et pas directement alimenter Elastisearch (sur la même machine) ?
C’est effectivement possible mais je préfère ne pas le faire pour plusieurs raisons.

D’abord, l’empreinte mémoire est bien moins importante. Là où Logstash consomme par défaut entre 512 et 1024 Mo, Filebeat ne consomme que quelques dizaines de Mo, 100 grand maximum. Un réel gain sur une infrastructure, quelle soit petite ou grande (chez moi, chaque Go compte !).

Ensuite, pour des raisons de sécurité, je n’ai autorisé que les connexions provenant de localhost sur Elasticsearch. Ainsi, seul Logstash (situé sur la même machine pourra y accéder), ce qui simplifie les autorisations au niveau du firewall et les flux de connexion. Les mauvaises langues diront « oui mais là tout le monde se connecte à Logstash, qui est sur la même machine, c’est pareil ».

Certes. Mais rien ne vous oblige à tout héberger sur la même machine et vous pouvez sécuriser vous même un peu mieux la plateforme. Toujours est-il que seul mon unique logstash peut alimenter la base et c’est quand même mieux, conceptuellement parlant.

Et enfin, Logstash dispose de plusieurs fonctionnalités pour trier et traiter les logs AVANT de les envoyer dans Elasticsearch, option que vous n’aurez pas si vous envoyez directement vos logs (ou toute autre information) directement depuis Beat vers Elasticsearch.

Configuration de Filebeat

Côté Beats, le template de configuration au format YAML est assez simple :
Ici, on donne 2 fichiers à manger, qu’on type tous les deux comme des « log » (purement informatif), puis un hôte et un port pour le Logstash de destination.

cat /etc/filebeat/filebeat.yml
filebeat.prospectors:
- type: log
paths:
- /var/log/nginx/access.log
document_type: nginx-access
- type: log
paths:
- /var/log/nginx/error.log
document_type: nginx-error
output.logstash:
hosts: mon_serveur_elk:5044

Configuration côté nginx

Je ne vais pas insister longuement là dessus, mais j’utilise une modification de l’output du logs pour disposer d’une information supplémentaire pas indiquée par défaut : l’hôte dont provient la requête.

En effet lorsque vous avez un serveur nginx, il ne vous indique pas dans le log l’URL exacte d’où vient la requête. Si comme moi, vous avez plusieurs « Virtual Hosts », pointant vers plusieurs serveurs, c’est très pratique pour débuguer en cas de mauvaises redirections.

Rien ne vous oblige à utiliser « mon » log_format, mais il faudra bien entendu modifier ce qui va suivre dans ce cas là…

cat /etc/nginx/conf.d/default_main_log_format.conf
#add host in default logging format
log_format main '$remote_addr - $remote_user [$time_local] "$host" '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent"';
# '$request_time';
access_log /var/log/nginx/access.log main;

Configuration de logstash

Nécessairement, puisque je passe par Logstash, je suis obligé de configurer Logstash (logique). C’est un mal pour un bien puisque ça me permet de traiter les lignes des fichiers de logs avant qu’ils soient intégrés dans Elasticsearch, comme je l’ai déjà dit.

Du coup le fichier de configuration côté Logstash est forcément plus complexe.

input {
beats {
port => "5044"
}
}
filter {
#/var/log/nginx/access.log
if [type] == "nginx-access" {
grok {
match => {
"message" => '%{IPORHOST:remote_ip} - %{DATA:user_name} \[%{HTTPDATE:time}\] "%{DATA:target_host}" "%{WORD:request_action} %{DATA:request} HTTP/%{NUMBER:http_version}" %{NUMBER:response} %{NUMBER:bytes} "%{DATA:referrer}" "%{DATA:agent}"'
}
}
date {
match => [ "time", "dd/MMM/YYYY:HH:mm:ss Z" ]
locale => en
}
geoip {
source => "remote_ip"
target => "geoip"
}
useragent {
source => "agent"
target => "user_agent"
}
}
#/var/log/nginx/error.log
if [type] == "nginx-error" {
grok {
match => {
"message" => '(?<time>%{YEAR}[./]%{MONTHNUM}[./]%{MONTHDAY} %{TIME}) \[%{LOGLEVEL:severity}\] %{POSINT:pid}.%{NUMBER}: %{DATA:errormessage}, client: %{IP:remote_ip}, server: %{IPORHOST:server}, request: "%{WORD:request_action} %{DATA:request} HTTP/%{NUMBER:http_version}", host: "%{DATA:target_host}"'
}
}
geoip {
source => "remote_ip"
target => "geoip"
}
}
}
output {
elasticsearch {
hosts => [ "mon_serveur_elk:9200" ]
index => "logstash-%{+YYYY.MM.dd}"
}
}

Là on comprend qu’on va un peu plus en baver. Mais je vais y aller par étapes.

Le plus facile

On va commencer par le plus facile : les balises input et output. En théorie, elles sont même auto-siffisantes. Si on ne met que ça, Logstash fera simplement office de passe plat.

input {
beats {
port => "5044"
}
}
[...]
output {
elasticsearch {
hosts => [ "mon_serveur_elk:9200" ]
index => "logstash-%{+YYYY.MM.dd}"
}
}

Pour faire clair, ici, on indique à Logstash de se mettre en écoute sur le 5044 pour des contenus provenant de beats, puis d’envoyer le résultat au serveur ELK dans l’index Logstash daté du jour. Trivial.

filter

Et là on arrive dans le vif du sujet. Si j’ouvre un log /var/log/nginx/access, voici ce que je pourrais y trouver :

1.1.1.1 - - [02/Oct/2017:03:44:27 +0200] "blog.zwindler.fr" "GET /2015/02/11/irl-redhat-virtualise-et-haute-dispo-rhcs-vmdk-partage-vs-vsphere-replication/ HTTP/1.1" 200 18219 "-" "Mozilla/5.0 (compatible; Yahoo! Slurp; http://help.yahoo.com/help/us/ysearch/slurp)"

Mon but ici, clairement, c’est de trouver comment débiter mon log en morceaux.

Petite note moins anglophiles d’entre vous, log en anglais, ça veut dire journal mais aussi rondin (de bois). D’où le petit jeu de mot/analogie avec Logstash (un abris bois) où l’on stocke les rondins après les avoir tronçonnés. Ça explique aussi l’ancien logo :

Comment ça on s’en fiche ? Moi ça me fait sourire ;-)

access.log

Si vous avez bien suivi plus haut, nous avons récolté et différencié 2 logs via l’attribut « document_type » : access.log et error.log. Je ne vais en décrire qu’un car le principe est similaire.

filter {
#/var/log/nginx/access.log
if [type] == "nginx-access" {
grok {
match => {
"message" => '%{IPORHOST:remote_ip} - %{DATA:user_name} \[%{HTTPDATE:time}\] "%{DATA:target_host}" "%{WORD:request_action} %{DATA:request} HTTP/%{NUMBER:http_version}" %{NUMBER:response} %{NUMBER:bytes} "%{DATA:referrer}" "%{DATA:agent}"'
}
}
[...]

Ici, une fois ma balise ouverte, je commence par ajouter une clause « if » qui va me permet de filtrer le log en fonction du document_type du log dont il s’agit.

Ensuite, je lui indique que je souhaite utiliser « grok », un module pour parser mes données brutes. Grok utilise ensuite la fonction match sur l’attribut « message » (ma ligne de log, rappelez vous) sur lequel je vais appliquer une sorte d’expression régulière qui va devoir matcher votre ligne de log à tous les coups !

Et quand on a dit ça, on a tout dit. Préparez vous à des tonnes de fun !

Alors bien entendu, si vous êtes chanceux, vous trouverez toujours une bonne âme qui partagera avec l’Internet le bon pattern qui correspond au bon output de votre log pour votre application. Mais sachez que des fois, il n’y a d’autres choix que de tester à la main… et c’est long !

La méthode bourrin pour vérifier que votre pattern est la suivante :

modifier la configuration dans logstash
redémarrer logstash
attendre un peu pour que des logs soient générés et vérifier dans kibana que ça fonctionne correctement

grokparsefailure ==> dommage vous pouvez recommencer

Heureusement au fil de mes recherches, je suis tombé sur un outil qui vous aide à tester sans devoir dérouler ce fastidieux processus… Vous pouvez simuler sur cette page web vos pattern grok sur des bouts de logs.

Ça change la vie !

Le mot de la fin

Voilà, vous avez maintenant des logs qui remontent dans nginx et qui contiennent pléthore d’informations sur les requêtes entrantes et les utilisateurs. De quoi s’amuser pendant des heures pour créer des graphiques puis des dashboard.

Je ferai rapidement un prochain article sur la partie utilisation de Kibana car pour l’instant vous ne pouvez pas faire grand chose avec ça ;-).

J’ai également développé d’autres playbook pour déployer les autres modules Beats, je ferai également un article là dessus.

En attendant : have fun !

Pour aller plus loin

ElasticStack : Déployer Kibana, Elasticsearch, Logstash & Beats avec Ansible

Tue, 03 Oct 2017 11:30:03 +0000

ElasticStack

Il y a quelques temps, je me suis mis à tester ElasticStack et j’avais préparé des playbooks Ansible et un tutoriel pour vous en parler. m4vr0x (qui a déjà écrit quelques articles sur le blog) était super intéressé et je lui ai dit « t’inquiètes, j’écris un article bientôt sur le sujet ».

La bonne blague : c’était en juillet (ce qui n’est pas si loin quand je regarde mes plus vieux brouillons :-p ).

Présentation de la solution

Trêve de plaisanterie ! Plus connu sous son ancien acronyme (ELK), ElasticStack est une suite logicielle développée par elastic.co. Le cœur de l’application est basée sur les logiciels :

Elasticsearch
Logstash
Kibana

Historiquement ces 3 produits étaient développés de manière indépendante (même si leur utilisation conjointe était conseillée). Courant 2016, elastic.co a décidé de refondre ces solutions et harmoniser les développements et les versions (tous les produits sont passés en version 5) pour proposer un ensemble complet cohérent.

Un bon article pour parler de ce renommage peut être consulté sur le site monitoring-fr.

La nouvelle architecture « classique » de la suite ElasticStack est la suivante :

Elasticsearch

Elasticsearch est un moteur de recherche et d’analyse RESTful distribué. C’est le cœur de la solution ElasticStack. Dans ce logiciel que sera stocké toutes les données qui seront collectés sur l’infrastructure. Les points forts de la solutions :

la résilience et l’architecture hautement disponible
la performance des requêtes grâce à l’indexation, particulièrement adapté à la recherche rapide de données de type métriques ou journaux

Paradoxalement, c’est la couche avec laquelle on interagit le moins au début, puisqu’on passe surtout du temps à configurer en amont la collecte des logs au niveau Beats et Logstash, puis en aval avec la visualisation dans Kibana.

Beats

La (relative) nouveauté. Introduit depuis le renommage et la version 5 de la suite logicielle, Beats regroupe un ensemble de modules logiciels de type « agents » à déposer sur les serveurs à surveiller.
Ce sont ces agents, adaptés pour chaque contexte, qui récoltent les données brutes et les transmettent à la brique suivante. Actuellement, il existe les agents suivants :

Metricbeat
Packetbeat
Logbeat
Winbeat

On peut directement collecter les données dans Elasticsearch, la couche Logstash étant optionnelle, mais on perd de nombreuses fonctionnalités et il est préférable de garder Logstash.

Logstash

Logstash est le module de collecte « historique ». C’est lui qui était chargé de récolter logs et métriques pour les transmettre à Elasticsearch.

Aujourd’hui, Logstash étant plus gourmand en ressources que les agents Beats, il peut être préférable de ne plus l’utiliser pour la collecte en elle même.

Cependant, à l’inverse, les agents Beats n’ont pas la capacité, contrairement à Logstash, de traiter les données récoltées. Il est donc intéressant de conserver Logstash en coupure entre les agents Beats et ElasticSearch pour réaliser des traitements sur les données collectées.

Un bon exemple est la collecte des logs. Par défaut, les données collectées par Filebeat contiennent les informations suivantes :

un timestamp correspondant au moment de la collecte (attention, pas identique au moment où le log a été écrit!!!)
le serveur source
le fichier de log source
la version de filebeat (super :/)
la ligne complète collectée dans le log

Cependant, il est complexe d’exploiter les données ainsi collectées puisque les messages des logs contiennent souvent des informations multiples sur une même ligne. Par exemple dans /var/log/messages, on a les informations suivantes :

Date Heure Hostname Processus[PIDXXX]: le message

Avec Logstash, il est possible de « tronçonner » via une regexp cette ligne en plusieurs champs :

Date et heure de l’événement journalisé (réelle cette fois, pas l’heure de collecte)
Nom d’hôte
Nom du processus concerné
PID
Le message réel

A partir de ces informations et associées aux informations récoltées par Beats, on peut donc gérer de manière beaucoup plus simple nos recherches et les consolider dans des graphiques avec Kibana.

Kibana

Kibana est une interface web qui permet d’explorer/de visualiser des informations provenant d’Elasticsearch et de les afficher sous formes de graphiques. On peut ensuite consolider les graphiques en tableaux de bords (dashboards).

Quelques exemples de dashboards qu’on peut créer :

Consommation des containers Docker sur une machine

Dashboard d’analyse des logs d’un serveur nginx

Un gros point positif de la solution est la possibilité de filtrer en temps réel sur une sous catégorie des données, soit via une barre de recherche, soit en cliquant directement sur les graphiques, en mode « drill down« .

Par exemple, si je veux obtenir plus de détails sur les code retours 404, il me suffit de cliquer sur le code 404 dans le camembert, et Kibana filtrera les données de TOUS les graphiques du dashboard pour ne m’afficher que les données correspondantes :

Déploiement d’ElasticStack via Docker

Vous y avez cru ? Je ne vais pas vous donner les étapes pour installer ElasticStack via l’usage des containers Docker officiels.

Pourquoi ? Ce n’est pas parce que je n’utilise pas Docker. J’ai déjà massivement adopté cette techno. aussi bien dans le contexte pro que perso.
Mais tout simplement parce que c’est assez bien documenté sur le site et que c’est vraiment simple. Si l’article a vraiment beaucoup d’engouement et que c’est demandé gentiment, je ferai un effort ;-) .

Installation d’ElasticStack sur un serveur via Ansible

C’est un peu plus compliqué si vous ne voulez PAS déployer ElasticStack via Docker. La documentation indique d’autres méthodes, dont l’installation classique via des RPMs.

Au moment où j’avais écris les premières lignes du tutoriel, j’avais remarqué qu’il y avait aussi une méthode automatisée via Ansible et comme j’adore Ansible j’ai voulu l’utiliser.

Sauf qu’elle n’existait que pour Elasticsearch et en plus pour la version 2.3.X (version d’avant le grand renommage de 2016 dont je parle plus haut) !

Je me suis donc attelé à la tâche de développer mes propres playbooks pour automatiser tout ça. Et comme je suis sympa, je vous les met à disposition.

Installer la base, ELK

Le code suivant va vous permettre de déployer via Ansible les 3 logiciels ElasticSearch, Kibana et Logstash sur une seule et même machine. Mais comme les rôles ont été découpés en 3 playbooks, il est tout à fait envisageable d’installer ces rôles sur des machines différentes (ou juste une partie).

Les seuls prérequis sont d’avoir une machine CentOS 7 (ou RHEL ou équivalent) qui dispose d’Ansible et de git d’installé.

mkdir -p /etc/ansible/roles && cd /etc/ansible/roles
git clone https://github.com/zwindler/ansible-deploy-elasticsearch
git clone https://github.com/zwindler/ansible-deploy-kibana
git clone https://github.com/zwindler/ansible-deploy-logstash

A partir de là, vous n’avez plus qu’à créer un playbook qui va tirer parti de ces rôles :

cd /etc/ansible
cat deploy_kibana_elasticsearch_logstash.yml
---
- name: Install elastic stack
hosts: localhost
roles:
- { role: ansible-deploy-kibana, tags: 'kibana' }
- { role: ansible-deploy-elasticsearch, tags: 'elasticsearch' }
- { role: ansible-deploy-logstash, tags: 'logstash' }

Et à lancer l’installation d’ELK sur l’hôte, affectueusement nommé « mon_serveur_elk » dans cet exemple, de la façon suivante :

ansible-playbook -l mon_serveur_elk deploy_kibana_elasticsearch_logstash.yml
ansible-playbook deploy_kibana_elasticsearch_logstash.yml
PLAY [Install elastic stack] ********************************************************************************************************************************
TASK [Gathering Facts] **************************************************************************************************************************************
ok: [mon_serveur_elk]
TASK [ansible-deploy-kibana : Add elasticsearch repository] ****************************************************************************************
changed: [mon_serveur_elk]
[...]
PLAY RECAP **************************************************************************************************************************************************
mon_serveur_elk : ok=4 changed=21 unreachable=0 failed=0

A partir de là, on peut commencer à tester les composants uns par uns et vérifier que tout fonctionne.

Tester une config Logstash

On peut vérifier que Logstash fonctionne comme il le doit grâce à la fonction « config.test_and_exit ». Juste pour les besoins du test, je vais donc créer un fichier logstash qui va lire le dmesg présent sur la machine. Ça n’a pas forcément d’intérêt mais comme ça on verra s’il n’y a pas de lézards.

cd /etc/logstash/conf.d
cat > test.conf << EOF
input {
file {
path => "/var/log/dmesg"
start_position => "beginning"
}
}
output {
elasticsearch {
hosts => [ "localhost:9200" ]
}
}
EOF
/usr/share/logstash/bin/logstash -f test.conf --config.test_and_exit
WARNING: Could not find logstash.yml which is typically located in $LS_HOME/config or /etc/logstash. You can specify the path using --path.settings. Continuing using the defaults
Could not find log4j2 configuration at path /usr/share/logstash/config/log4j2.properties. Using default config which logs errors to the console
Configuration OK

On peut ignorer les warning ci dessus dans un premier temps. Tout fonctionne ! Si on le souhaite, on peut démarrer Logstash à la main et avec cette configuration avec la commande suivante :

/usr/share/logstash/bin/logstash -f test.conf --config.reload.automatic

Pour aller plus loin avec Logstash, je vous conseille de lire la documentation qui est assez progressive dans la difficulté. Les configurations de Logstash ne sont pas toujours évidentes et il peut y avoir pas mal de débuging les premières fois.

Requêter Elasticsearch

Il est tout à fait possible de requêter à la main ElasticSearch, directement via l’API. Un moyen simple de s’en convaincre est de réaliser un simple « curl » sur la base mais vous pouvez bien entendu faire beaucoup plus complexe avec des outils prévu pour explorer les APIs.

Par exemple, on peut afficher les informations de la base comme ceci :

curl -XGET 'localhost:9200/'
{
"name" : "anXc9nn",
"cluster_name" : "elasticsearch",
"cluster_uuid" : "5P9XdOMJRZOPIy38NegdnQ",
"version" : {
"number" : "5.5.0",
"build_hash" : "260387d",
"build_date" : "2017-06-30T23:16:05.735Z",
"build_snapshot" : false,
"lucene_version" : "6.6.0"
},
"tagline" : "You Know, for Search"
}

Autres commandes sympas, vous pouvez afficher l’état de santé de vos nœuds Elasticsearch. Ici je n’en ai qu’un et c’est donc considéré comme dangereux (car pas de redondance), d’où l’état « yellow » et pas « green » :

curl -XGET 'localhost:9200/_cat/health?v&pretty'
epoch timestamp cluster status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1506795865 20:24:25 elasticsearch yellow 1 1 516 516 0 0 516 0 - 50.0%
curl -XGET 'localhost:9200/_cat/nodes?v&pretty'
ip heap.percent ram.percent cpu load_1m load_5m load_15m node.role master name
x.x.x.x 43 89 1 0.09 0.16 0.30 mdi * anXc9nn

Vous pouvez afficher la liste des fichiers correspondant à vos données avec cette commande :

curl 'localhost:9200/_cat/indices?v'
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
yellow open filebeat-2017.06.19 w7tmj4L3ToqEdiHYmvHS8Q 5 1 981 0 270kb 270kb
yellow open .kibana YFYjR5hFSGualaX-ahL_9g 1 1 2 0 23.5kb 23.5kb

Par défaut (et pour des questions de performance), on a pour habitude de segmenter les données dans Elasticsearch par jours. Au fil des jours de nouveaux fichiers seront créés et viendront remplir votre filesystem. Il ne faudra donc pas oublier de jeter un œil de temps et en temps et purger tout ça !

Et Kibana ?

Normalement, Kibana est accessible à l’adresse http://@IP_de_mon_serveur_elk:5601/

Et maintenant, on collecte quoi ?

C’est bien gentil tout ça, mais pour l’instant on a rien du tout… Au delà de la simple connexion à Kibana, vous arriverez sur un écran de configuration qui cherchera, sans succès, des données dans elasticsearch.

Unable to fetch mapping

Peine perdue, ces données n’existent pas encore puisqu’on ne collecte rien pour l’instant !

Vous trouverez probablement de nombreux tuto sur Internet expliquant comment collecter des données provenant de fichiers depuis Logstash. Cependant, comme je l’ai indiqué en début d’article, la méthode conseillée est maintenant d’utiliser plutôt les agents Beats, qui envoient les données à Logstash lorsqu’un traitement est nécessaire.

Et là encore, je vous ai préparé des playbooks tout fait pour installer et configurer à la fois les modules Beats sur les serveurs supervisés ET le logstash côté serveur ELK. Plus rien à faire donc, juste à attendre le 2ème article !

Haaan, quel suspense ! A la semaine prochaine ;-)

[Edit]Les deux articles suivants sont là :

[/Edit]

Ressources complémentaires

Installer ELK sous Ubuntu 16.04 (Digital Ocean, encore eux)
Sécurisation d’ElasticStack officielle avec les X-Pack : attention c’est payants !
Comment sécuriser une plateforme Elasticsearch et Kibana (EN) (lien mort, j’utilise Internet Archive)