La suite avec varnish: web access log logstash redis elasticsearch kibana

Cette note est la suite de : Le début: web access log, logstash redis lastichsearch kibana

Gérer et monitorer les web access log avec logstash redis elasticsearch et kibana.

Après la configuration de access log apache et de leur routage  nous continuons en faisant la même chose avec les reverses proxys varnish

Acte 2 scène 1: Le défi des web access log avec varnish

Varnish est parfaitement capable de généré des access log de la même façon que apache, il à même un outil pour cela : varnishncsa

Le défis à relever est d’émettre des access log  de même format que ceux généré précédemment par apache, puis de les router via syslog sans transiter par les disques.

Pour le format on part sur du JSON comme précédemment. Le soucis est avec varnishncsa dont l’option « -D Daemonize » impose d’écrire dans un fichier. Or j’ai besoin que varnishncsa crache les log sur STDOUT afin de le brancher sur un pipe vers le bout de perl utilisant Sys::Syslog que nous avons vu précédemment

J’ai donc fais le choix enregistrer le lancement de  varnishncsa pour varnish 3 avec format JSON souhaité dans un script bash

/usr/bin/varnishncsa -P /var/run/varnishncsa/varnishncsa.pid -F "{ \"@timestamp\": \"%{%Y-%m-%dT%H:%M:%S%z}t\", \
\"@version\": \"1\", \
\"vips\":\"%{host}i\", \
\"tags\":[\"varnish\"], \
\"message\": \"%h %l %u %t \\\"%r\\\" %s %b\", \
\"clientip\": \"%h\", \
\"duration\": %D, \
\"status\": \"%s\", \
\"request\": \"%U%q\", \
\"urlpath\": \"%U\", \
\"urlquery\": \"%q\", \
\"bytes\": %b, \
\"method\": \"%m\", \
\"referer\": \"%{Referer}i\", \
\"useragent\": \"%{User-agent}i\" }" | /usr/local/bin/to_rsyslog.pl cs-proxy2 local0.notice

Notez que :

  1. Le champs tags indiquant le type de la source est toujours présent mais cette fois configuré sur varnish
  2. Le champs clientip prend les ip d’origine de la requête
  3. Que la duré de réponse est toujours fourni par le champs duration
  4. Que le volume de donnée en bytes de la réponse est fourni
  5. La aussi le perl passe la trame log à syslog avec les local0 en priorité et notice en gravité tout comme pour les log généré par apache.

La syntaxe de la configuration de varnishncsa est évidement différente de celle des log apache. Mais la trame de log en résultat est syntaxiquement strictement identité. On va voir que cela facilite le travail.

Acte 2 scène 2: le lancement varnishncsa

Comme il n’est pas possible de compter sur l’option « -D Daemonize » de varnishncsa j’ai créé un script init basé sur screen

#!/bin/sh
# Start/stop the varnishncsa daemon.
#
### BEGIN INIT INFO
# Provides: varnishncsa
# Required-Start: $remote_fs $syslog $time
# Required-Stop: $remote_fs $syslog $time
# Should-Start: $network $named
# Should-Stop: $network $named
# Default-Start: 2 3 4 5
# Default-Stop:
# Short-Description: varnishncsa service
# Description: varnishncsa service
### END INIT INFO
 
PATH=/bin:/usr/bin:/sbin:/usr/sbin
DESC="varnihsncsa daemon"
NAME=varnihsncsa
DAEMON=/usr/local/bin/varnishncsa/VarnishncsaToSyslog.sh
PIDFILE=/var/run/varnishncsa/varnishncsa.pid
SCRIPTNAME=/etc/init.d/"$NAME"
 
test -f $DAEMON || exit 0
 
. /lib/lsb/init-functions
 
case "$1" in
start) log_daemon_msg "Satarting VarnishncsaToSyslog" "varnishncsa"
 su - root -c "(screen -d -m -S varnishncsa -s /usr/local/bin/varnishncsa/VarnishncsaToSyslog.sh )"
 log_end_msg $?
 ;;
stop) log_daemon_msg "Stopping VarnishncsaToSyslog" "varnishncsa"
 killproc -p $PIDFILE $DAEMON
 RETVAL=$?
 [ $RETVAL -eq 0 ] && [ -e "$PIDFILE" ] && rm -f $PIDFILE
 log_end_msg $RETVAL
 ;;
restart) log_daemon_msg "Restarting VarnishncsaToSyslog" "varnishncsa"
 $0 stop
 $0 start
 ;;
reload|force-reload) log_daemon_msg "Not doing anything" "varnishncsa"
 log_end_msg 0
 ;;
status)
 status_of_proc -p $PIDFILE $DAEMON $NAME && exit 0 || exit $?
 ;;
*) log_action_msg "Usage: /etc/init.d/InitVarnishncsaToSyslog {start|stop|status|restart|reload|force-reload}"
 exit 2
 ;;
esac
exit 0

C’est sale et gras (le gras c’est la vie) mais cela est en production sur closermag.fr depuis plusieurs mois sans aucun soucis d’aucune sorte.

Acte 2 scène 3: Le routage syslog

Encore une fois dans la configuration rsyslog on précise que tout ce qui porte l’étiquette local0.notice est à envoyé à un serveur logmaster.

local0.notice @logmaster:514
& stop

Je précise, de nouveau, que après l’envois au serveur logmaster le message syslog ne doit pas poursuivre et traverser les autres règles de traitement avec l’instruction & stop . Attention cette syntaxe est pour la version 8 de rsyslog que j’utilise. Comme la trame ne passe pas au travers des autres règles elle n’est pas enregistré dans un fichier, localement, sur disque.

2 réflexions sur “ La suite avec varnish: web access log logstash redis elasticsearch kibana ”

  1. Il y a un bug dans l’init c’est indiqué solr. Pour inforlationq les systèmes a bases de debian possèdent l’outil start-stop-daemon qui permet de réaliser cela de façon plus élégante qu’un screen qui tourne en root

  2. Corrigé, cela n’allais pas bugger bien loin 🙂
    Je ne doute pas qu’il puisse être possible de faire mieux, avec start-stop-daemon par exemple. Je t’en pris ne bride pas ta créativité lance toi.

Laisser un commentaire