Archives pour la catégorie Sysadmin

ElasticSearch, Logstash et Kibana, de la centralisation au traitement des logs. (2/2)

La suite ELK : Logstash

Logstash est un outil disponible sur le site https://www.elastic.co/products/logstash, il permet une centralisation des processus data, une normalisation des schémas de données pour la destination de son choix et une personnalisation du format des logs.

Dans notre cas de figure, c’est lui qui va faire le lien entre syslog-ng et elasticsearch. Son installation nécessite quelques pré-requis comme OpenJDK et des sources sur lesquelles on peut s’appuyer, ici les sources importées de syslog-ng.

L’installation en elle-même et après avoir configuré les bonnes sources, s’effectue via notre utilitaire de paquet préféré. La configuration de logstash se découpe en 3 partie, « input », « filter », « output ».

  • INPUT correspond à la configuration des fichiers en entrée, typiquement ceux stockées par syslog-ng et ainsi lui spécifier un type.
  • FILTER permet d’appliquer des règles comme un reformatage des logs par exemple en fonction du type qu’on lui aura défini.
  • OUTPUT spécifie avec quel procotole et vers quel hôte envoyer les logs une fois reformatés.
input { # Block Input
 file { # Block file
 path => [ "/my/path/to/log/app.log" ] # Chemin vers le fichier de logs
 type => "application-logger-serv100" # Le type qu'on lui attribue et qui sera affiché dans Elasticsearch
 codec => "json" # Spécifie le format à l'entrée des logs dans Logstash
 }
 }
 filter { # Block Filter
 if [type] == "application-logger-serv100" { # Condition par rapport au type
 grok { # Block permettant de parser
 match => [ "message", "(.*?)\[(?<date>(.*?))\] (?<channel>(.*?)).(?<level>(DEBUG|INFO|NOTICE|WARNING|ERROR|CRITICAL|ALERT|EMERGENCY)): (?<logmessage>(.*?)) (?<context>\{\"(.*?)\"\:\"(.*?)\}) \{\"(.*?)\"\:\"(?<session_id>(.*?))-(?<uniq_id>(.*?))\"" ]} # Expression regulière
 }
 }
 output { # Block Output
 elasticsearch_http { # Type de destination sur la quelle on envoi les logs une fois parsés
 host => "127.0.0.1" # Destination sur laquelle on envoi les logs une fois parsés} }

 

Il y aura toujours un seul block input, filter et output.
En revanche, il est possible :

  • D’additionner les fichiers en entrée pour la partie input en dupliquant le block « file »
  • De multiplier les conditions avec le « if »

Il est possible pour Logstash de stocker ses propres patterns pour les filtres, basés sur des expressions régulières que nous pouvons utiliser dans le block « filter »

Exemple de pattern stocké dans le répertoire de configuration de logstash :

 USERNAME [a-zA-Z0-9._-]+
 USER %{USERNAME}
 INT (?:[+-]?(?:[0-9]+))
 BASE10NUM (?<![0-9.+-])(?>[+-]?(?:(?:[0-9]+(?:\.[0-9]+)?)|(?:\.[0-9]+)))
 NUMBER (?:%{BASE10NUM})

L’appel d’un pattern s’effectue de cette manière : « %{MYPATTERN} » comme une sorte de variable et va l’interpréter.

Dans la mesure où Logstash s’appui sur une JVM, il est important de régler la quantité de mémoire utilisée dans /etc/default/logstash

Toute modification implique de redémarrer Logstash.

La suite ELK : Elasticsearch

Elasticsearch fait aussi partie de la suite ELK et est disponible sur https://www.elastic.co/fr/.
Elasticsearch permet entre autres de disposer de données en temps réel, d’une scalabilité horizontale, d’une haute disponibilité, de stockage de documents en Json et dispose d’une API RESTful.
Il dispose des mêmes pré-requis que Logstash, notamment de la JVM.

Son installation est décrite sur le site offciel : https://www.elastic.co/guide/en/elasticsearch/reference/current/setup-repositories.html et une fois les sources ajoutées, s’effectue via notre utilitaire de gestion des paquets préféré.

Au même titre que Logstash, il est important de fixer la mémoire utilisée et cette configuration se fait cette fois dans /etc/default/elasticsearch, le paramètre à modifier est : ES_HEAP_SIZE et s’exprime en Giga. (g)

Concernant la gestion et la visualisation des données, il existe un plugin intéressant permettant de naviguer, de passer des requêtes à la volée. Ce plugin se nomme « plugin Head » et s’installe de cette manière :

 cd /usr/share/ && elasticsearch/bin/plugin -install mobz/elasticsearch-head

 

L’URL d’accès : my.url.com:9200/_plugin/head/

Spécifiquement dans notre projet, cette brique permet à la fois de stocker les dashboards Kibana et également les données récupérées depuis le serveur de log et en format Json.

A ce stade, nous n’avons pas d’autres étapes à réaliser pour notre stack ELK.

syslog_indexex
Les données arrivent en temps réel et sont visibles directement via le plugin dans la partie « navigateur ».

Un redémarrage du service Elasticsearch est requis pour pouvoir fonctionner avec les nouvelles modifications.

La suite ELK : Kibana

Kibana est une interface permettant d’interpréter les données json stockées dans Elasticsearch

Il suffit de télécharger l’archive sur le site https://www.elastic.co/downloads/kibana et de suivre les instructions donné sur le site.

La configuration est assez simple et se limite à la modification de ces 3 lignes dans le fichier config.js du dossier extrait, petites explications :

elasticsearch : "http://syslog.bazarchic.com:9200", /* Spécifie le serveur Elasticsearch sur le port 9200 */
default_route : '/dashboard/file/default.json', /* Spécifie le chemin du dashboard par défaut */
kibana_index: "kibana-int", /* Spécifie Le nom des dashboards stockées dans Elasticsearch */

Il est possible de configurer apache2 et un virtualhost pour accéder à Kibana

<VirtualHost *:80>
 ServerName monurl.domaine.com
DocumentRoot /var/www/kibana
 <Directory "/var/www/kibana">
 Order allow,deny
 Allow from all
 Options -Indexes FollowSymLinks MultiViews
AuthType Basic
 AuthUserFile "/etc/apache2/.htpasswd"
 AuthName "Authentication required"
 require valid-user
</Directory>
 ErrorLog /var/log/apache2/kibana/error.log
 CustomLog /var/log/apache2/kibana/access.log combined
</VirtualHost>

 

Pensez à prendre en compte la configuration de Apache2 (/etc/init.d/apache2 reload). Vous pouvez maintenant accéder à Kibana. A la première connexion, un message sur l’interface indique qu’il n’arrive pas à récupérer de dashboard. Il faudra simplement en créer un et l’enregistrer.

Si vous ne voyez pas de message d’erreur alors vous pouvez retrouver votre dashboard sur l’interface « head » d’Elasticsearch.

En revanche, si l’enregistrement du dashboard a échoué, vous vous êtes trompé dans la configuration de Kibana dans le fichier config.js.

Pensez à vérifier que tous les services tournent en regardant dans la liste des processus lancés.

Nicolas Blattmann

ElasticSearch, Logstash et Kibana, de la centralisation au traitement des logs. (1/2)

Pour cet article sur le blog technique de Bazarchic, nous allons nous intéresser à un sujet que nous n’abordons pas souvent, la gestion et la centralisation de nos logs.

En effet, nous avons l’habitude de laisser gérer nos démons préférés comme rsyslog, mais on comprend vite que lorsque nous voulons répondre à davantage de problématique, comme la centralisation et l’organisation des logs au sein d’un centre de données, de l’application de filtres complexes ou encore une représentation visuelle de ces derniers, ces outils deviennent inadaptés.

Nous avons alors choisi ces différents outils :

  • Rsyslog
  • Syslog-ng
  • Elasticsearch
  • Logstash
  • Kibana

Avant de vous les présenter et leur manière de s’interfacer entre eux, nous aimerions vous expliquer la raison de ce choix.

La problématique était la suivante :

Nous avions besoin d’un outil, une interface web de préférence, où nous pourrions consulter nos logs à la fois systèmes et applicatifs, où nous pourrions les organiser comme nous voulons sous forme de filtres applicables « à la volée » et où nous pourrions les visualiser sous forme de graphes et/ou de statistiques, le tout en temps réel.

Après quelques recherches et aux vues des expériences passées, nous avons rapidement opté pour la « suite ELK » (Elasticsearch-Logstash-Kibana) à laquelle nous avons ajouté des composants.

Comment s’interfacent-ils entre eux ?

syslog_archi_final

 

Intéressons nous maintenant à la mise en place de ces outils.

1°) Syslog-NG et Rsyslog

Syslog-ng s’installe directement via les dépôts officiels de Debian.

Dans les 4 sections principales de syslog-ng qui sont, la source, la destination, les filtres et logs, il est préférable pour chaque nouvelle « source » de créer un fichier dans le sous répertoire prévu à cet effet /etc/syslog-ng/conf.d/ pour plus de clarté.

Exemple de source :

source s_clients {
             tcp(ip(0.0.0.0) port("514") max-connections(100) );
};

Petit exemple pour centraliser les logs apache :

template t_template_name {
	template("$MSG\n");
    template_escape(no);
};

destination d_apache {
	file("/path/to/file/$HOST/$YEAR/$MONTH/error.apache.log" template(t_template_name));
};

filter f_apache {
	level(err);
};
log {
	source(s_clients); filter(f_apache); destination(d_apache);
};

Dans cet exemple, nous filtrons les logs apache, nous les stockons dans /path/to/file/$HOST/$YEAR/$MONTH/ et le nommons error.apache.log.
La partie filtre ici permet de ne garder que les logs d’une criticité égal ou supérieure à « Error »
La partie « template » ici est un peu plus spécifique et permet de retirer le timestamp ajouté par rsyslog lors de son envoi vers le serveur de logs principal.

Une prise en compte de la configuration est nécessaire, c’est à dire un redémarrage du service.

Partie client, au niveau de rsyslog, il est déjà installé par défaut sur les environnements Debian.
Les clients n’ont maintenant plus qu’à paramétrer leur gestionnaire de logs local comme rsyslog sur le port 514 par défaut.

$ModLoad imfile
$InputFileName /var/log/apache2/error.log
$InputFileTag apache-error
$InputFileStateFile stat-apache-error
$InputFileSeverity error
$InputFileFacility local6
$InputRunFileMonitor

local6.* @@123.123.123.123:514

$ActionResumeInterval 10
$ActionQueueSize 100000
$ActionQueueDiscardMark 97500
$ActionQueueHighWaterMark 80000
$ActionQueueType LinkedList
$ActionQueueFileName myqueue
$ActionQueueCheckpointInterval 100
$ActionQueueMaxDiskSpace 2g
$ActionResumeRetryCount -1
$ActionQueueSaveOnShutdown on
$ActionQueueTimeoutEnqueue 10
$ActionQueueDiscardSeverity 0

Les paramètres importants ici sont :

  • InputFileName qui définit quel fichier doit être traité
  • InputFileTag qui met une étiquette sur le fichier
  • InputFileSeverity qui détermine le niveau de criticité du log à traiter
  • InputFileFacility qui détermine le canal de communication à utiliser

Le reste de la configuration dans l’exemple permet d’affiner quelques paramètres comme la taille de la file d’attente.

Une prise en compte de la configuration est nécessaire aussi à ce niveau.

D’ores et déjà, lorsqu’une entrée est ajoutée dans le fichier /var/log/apache2/errog.log sur le serveur client, une entrée devrait également s’écrire dans le fichier /path/to/file/$HOST/$YEAR/$MONTH/error.apache.log sur le serveur de logs.

S’il n’y a pas d’écriture dans les logs, vous pouvez vous aider de tcpdump pour vérifier la bonne réception des paquets entre vos serveurs par exemple.

Nicolas Blattmann