Le début: web access log logstash redis elasticsearch kibana

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

 

Voila une belle série de buzz word non ? Trêve de plaisanterie ! Je vais dans une série de note expliquer la création d’une pile applicative ELK (logstash elasticsearch kibana) que j’ai monté pour surveiller et navigué dans le flux des access log sur site www.closermag.fr

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

A l’origine sont les access log de plusieurs serveurs apaches ainsi que de plusieurs serveur varnish. Plusieurs défis sont à relever  :

  1. Généré des access log complet dans un format facilitant leur utilisation par la chaîne applicative souhaité
  2. La plupart des serveurs étant des machines virtuelles il est nécessaire de ne pas écrire sur disque. Le disque est le sous système le plus lent d’un serveur. Dans le cas d’une machine virtuelle, quelques soit l’approche ou la technologie, c’est encore pire.
  3. Le routage des flux de log apache comme varnish et leur concaténation dans un ensemble unique.

Acte 1 scène 2 : Les apaches

Pour les serveurs apaches la gestion de log et de leur format est un chose parfaitement documenté, je ne vais pas revenir dessus. Les access log devant être finalement enregistré dans elasticsearch dont la structure de stockage et sa hiérarchie étant basé sur le format JSON pour quoi ne pas les générer directement dans ce format et les router tel quel ?

Voici dont le format de log apache créé sur cette base et utilisé. Plusieurs itération et correction ont été intégré.

LogFormat "{ \
 \"@timestamp\": \"%{%Y-%m-%dT%H:%M:%S%z}t\", \
 \"@version\": \"1\", \
 \"vips\":\"%v\", \
 \"tags\":[\"apache\"], \
 \"message\": \"%h %l %u %t \\\"%r\\\" %>s %b\", \
 \"clientip\": \"%{X-Forwarded-For}i\", \
 \"duration\": %D, \
 \"status\": %>s, \
 \"request\": \"%U%q\", \
 \"urlpath\": \"%U\", \
 \"urlquery\": \"%q\", \
 \"bytes\": %B, \
 \"method\": \"%m\", \
 \"referer\": \"%{Referer}i\", \
 \"useragent\": \"%{User-agent}i\" \
 }" log_apache_json

Notez que :

  1. Le champs tags indiquant le type de la source
  2. Le champs clientip prend les ip d’origine de la requête et non ceux des lodbalancers ou reverse proxy en amont
  3. Que la duré de réponse est fourni via le champs duration
  4. Que le volume de donnée de la réponse est fourni par le champ bytes

Nous générons donc les access log directement dans un format facilitant leur utilisation par la chaîne d’application souhaité.

Acte 1 scène 3 : Le routage

Pour ne pas toucher aux disques le mieux est encore de transmettre directement les logs au démon syslog. Avec nginx c’est facile avec apache un peu moins.

Il est possible de transmettre les log apache à syslog avec l’utilitaire logger. Seulement logger à quelque limitation et comme une trame de log au format JSON est longue et dépasse parfois 1024 bits … logger la coupe en deux et envois deux trames syslog pour une trame access log. Il faut donc trouver autre chose.

Perl

Dans l’échange sur serverfault concernant les limitations de logger la solution est donné : Sys::Syslog. Il suffit de créé soit même un nouvel utilitaire capable de prendre en charge un trame dépassant les 1024 bits.

#!/usr/bin/perl
use Sys::Syslog qw (:DEFAULT setlogsock);
 
setlogsock('unix');
 
$ident = $ARGV[0];
@facilityandpriority = split(/\./, $ARGV[1]);
$facility = @facilityandpriority[0];
$priority = @facilityandpriority[1];
 
# open our log socket
openlog($ident, '', $facility);
 
# log all our input
while () {
 syslog($priority, $_);
}
 
# close the log socket
closelog;

Vhost et rsyslog

Nous avons le format de log et l’utilitaire de couplage avec syslog. Il reste à coller les bout ensemble.

Dans le vhost ont appel le format de log créé et on l’envois vers l’utilitaire. On fait le choix d’une catégorie et d’un priorité syslog, ici local0 et notice

CustomLog "||/usr/local/bin/to_rsyslog.pl closermag.fr local0.notice" log_apache_json

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 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.

La quadrature du net à besoin de vous !

La Quadrature du Net agit au quotidien pour la défense de nos libertés fondamentales !

Soutenez La Quadrature du Net

 

L’année dernière j’avais fais un don modeste de 25€ à la quadrature du net. Cette année j’ai fais le choix, tout aussi modeste, de faire un don mensuel et donc de verser 5€ chaque mois pour la duré de l’année 2015.

La quadrature prend position, débat, alerte, mobilise, pour qu’Internet reste un espace de liberté et de partage accessible à tous.

  • Pour une vraie protection de la neutralité du Net et la non-discrimination des données ;
  • Pour la protection du droit à la vie privée contre la surveillance des États et des entreprises ;
  • Pour l’adaptation du droit d’auteur aux pratiques culturelles actuelles et la légalisation du partage non marchand des œuvres numériques entre individus ;
  • Pour la liberté d’expression contre la censure ;
  • Pour l’exclusion des dispositions mettant en danger nos droits fondamentaux des accords internationaux (TAFTA, CETA, TISA, ACTA, etc) ;
  • Pour la participation de tous à la vie démocratique et au débat public ;
  • Pour la défense de l’Internet que nous aimons et qui nous respecte <3

Ce travail de la quadrature à protégé nos droits fondamentaux est un chose importante pour moi en tant que citoyen.

Mes règles règle de travail et peut être dev / ops

Mes propres règles de travail et peut être dev / ops . Et plus largement de salubrité dans le travail.

  • Ne pas construite sa productivité au détriment de celle des autres
  • Les personnes compétentes ont de l’empathie et sont généreuse
  • L’état de l’art n’est que ce qui est partagé et compris par la majorité
  • On ne déplace pas la merde on la nettoie
  • Utilise l’interface graphique que si tu maîtrises déjà  la ligne de commande.
  • Un carnet et un feutre seront toujours de loin les outils les plus robustes et résiliant de l’informaticien.
  • Raconter une histoire est le B.A.BA de la pédagogie technique.
  • Une bourde expliquée est toujours plus bénéfique qu’un coupable pendu.
  • Un outils n’est jamais la solution à un problème d’organisation ou de management.
  • La dictature technique est une option face à l’anarchie. Au moins Il y en à un qui décide et assume.
  • Faute de dialogue, travailler à l’oreille est une option.

Aperotech Oxalide : Dev/Ops

J’ai participé le 8 octobre à un Apérotech Oxalide sur le thème : Culture DevOps et retours d’expérience.

Un chouette moment dans un cadre sympathique ou j’ai partagé mon expérience chez Mondadori au coté de personne du Monde, de Ekino et de Sagem. Voici la bande annonce de Oxalide pour promouvoir ces rencontres.

Vous trouverez un compte rendu de nos témoignage complet chez Oxalide . Vous y trouvez également des enregistrements sonores montés de façon à pouvoir accéder séparément à chaque question de l’animateur et aux réponses formulées.

Je vous livre ici la sélection de mes propos faite par Oxalide érigé ici en aphorismes :

  • « Chez Mondadori, DevOps participe à la vélocité de mise en production des sites du groupe.»
  • « Nous sommes ainsi en mesure de répondre aux nouvelles idées lancées par les métiers le plus vite possible et actualiser nos sites web en continu.»
  • « La culture DevOps hérite de celle du logiciel libre.»
  • « DevOps, c’est ainsi beaucoup de générosité, de solidarité et d’empathie, autant de qualités propres aux communautés de l’open source. Ces traits culturels sont essentiels dans le décloisonnement des Devs et des Ops, ils vont faciliter le partage du premier objectif commun à atteindre : satisfaire le business.»
  • « Nos Devs étaient un peu rétifs au début. Je me suis alors mis à côté d’eux avec mon portable, et j’ai créé un outil de déploiement maison qui répond à leurs attentes. C’est devenu un outil emblématique de l’équipe IT. Nous utilisons aussi l’outil de monitoring Zabbix qui permet de superviser tout type d’indicateur, et de produire des tableaux de bord.»
  • « Tous sont équipés d’ordinateurs portables et donc pas figés à leur bureau, les Devs et les Ops se réunissent autour de ces dashboards en cas d’incident pour en comprendre l’origine. C’est un bon moyen de faire collaborer ces deux populations. »

Je pense sincèrement que l’approche Dev / Ops est l’enfant de la culture open source. Ce n’est pas une création managérial ou une méthode organisationnelle créé ex nihilo par un manager mais une émanation conjointe de Développeur et d’Administrateur Système reconnaissant réciproquement leurs compétences. Et dans la culture du logiciel libre on ouvre toujours la porte à la compétence, mais si elle vous fait sentir moins bon ou du moins non compétent.

Note: Je n’ai aucun contact professionnel avec Oxalide, je ne suis ni client, ni fournisseur. Mon frère travail pour eux mais je ne suis pas encore sur que cela soit à leur bénéfice ^_^

Run linux since 1994 and this web site since 2002