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

Laisser un commentaire