On continue avec syslog : web access log logstash redis elasticsearch kibana

Après la génération des access log au format JSON avec apache, puis la génération des acces log au format JSON avec varnish on  continue avec syslog : web access log logstash redis elasticsearch kibana

On continue avec syslog : web access log logstash redis elasticsearch kibana

 

Acte 3 scène 1: Rsyslog

Bien, donc sur le logmaster arrive donc plusieurs flux d’access log au format JSON. Ceux des serveurs apache (entre deux et six en fonction de l’activité) plus celui des serveurs varnish (un varnish pour le silo html un autre pour les static). On va cuisiner cela avec les lignes de configuration syslog sur le serveur logmaster.

# Apache access Logi & varnshs access log
$template MsgOnlyFormat,"%msg:::drop-last-lf%\n"
$template AppacheAccessFile,"/mnt/LogDataStore/apache2.json/%app-name%.json.access.log"
$template VarnishAccessFile,"/mnt/LogDataStore/varnish.json/%hostname%.varnish.json.access.log"
if $syslogfacility-text == 'local0' and $syslogseverity-text == 'notice' then @localhost:10514;MsgOnlyFormat

Alors la trame de log est d’abord nettoyer en supprimant le retour à la ligne en passant dans le template MsgOnlyFormat et envoyé en local sur le port 10514

Acte 3 scène 1: Logstash et Redis

Logstash

Sur le port 10514 un logstash écoute pour prendre en charge la trame de log. On va écouter beaucoup, filtrer par mal et enregistrer tout autant.

Voici le bout de configuration logstash en jeu

input {
 udp {
 port => 10514
 codec => "json"
 type => "access-log"
 }
}
filter {
 if [vips] !~ "closermag.fr" {
 drop {}
 }
}
output {
 #stdout { codec => rubydebug }
 redis {
   host => "localhost"
   data_type => "list"
   key => "logstash"
   codec => json
 }
}
  • Le logstash écoute donc en UDP sur un port qui n’entre pas en concurence avec rsyslog qui écoute lui aussi en UDP sur le même serveur mais sur le port 514.
  • Le logstash balance salement à la poubelle tout ce qui ne concerne pas closermag.fr (host au sens varnish ou ServerName au sens apache). Cela évite bien des parasitages quand les serveurs varnish sont mutualisé ce qui est le cas pour la distribution des statics.
  • Logstash  balance le tout dans un redis qui est la pour offrir une temporisation. En effet parfois un pic d’audience le midi ou le soir engendrais un engorgement plus loin dans la chaîne de traitement.

Redis

Le redis est configuré avec 2Go de mémoire pour stocker les trame de log et il écoute sur localhost comme sur la carte réseau disponible. Pour le reste, rien : pas d’esclave, pas de dump sur le disque.

4 réflexions sur “ On continue avec syslog : web access log logstash redis elasticsearch kibana ”

  1. La réponse à ma question viendra surement dans le prochain billet mais… Pourquoi passer par un Redis dans l’ouput et pas directement dans l’eslasticsearch ?

    Volumes trop important pour aller directement dans l’ES ?

  2. Redis est là pour offrir un buffer avant l’enregistrement dans eslasticsearch.

    Durant les pic d’audience propre a une journée normal sur le site, le volume de log est trop important pour être directement injecté dans eslasticsearch. Durant quelques minute logstash patine, le load cpu du serveur monte monte, les disques grattes comme des fous. Les logs étant envoyé en udp sont perdu car aucun processus logstash n’est disponible. Impossible de lancer plus de processus car le serveur est au taquet. Il y’a un blanc vide d’information le temps que tout cela reprenne son souffle avant de s’engorger a nouveau. Au final j’avais des graphique en peigne, avec pic et blanc d’info alterné toute les 3 a 4 minutes.

    L’enregistrement dans redis est rapide car sans traitement et sans écriture disque, le tout sur un serveur au ressources sous utilisé.

    Le logstash chargé de l’intégration (que nous allons voir dans un autre billet) intègre à son rythme, sans rien perdre, sans engorgement. Au final il peux il avoir un retard à l’affichage car les données les plus fraîche présentable date de 10 à 15 min mais sans perte. Au moment ou l’audience deviens plus calme (après 21h par exemple) le retard est rattrapé. Le monitoring en temps réel en soufre mais pas le data mining

    Karles

  3. Salut, merci pour le tuto,
    Est-il intéressant aussi de mettre Redis en amont (avant logstash) ? ou est-ce que cela va faire doublon, merci, benny

Laisser un commentaire