Journal présentation de fuse_kafka, un agent de logging pour kafka fondé sur FUSE

Cher journal,

Je voudrais te présenter le logiciel que je développe en ce moment, à savoir fuse_kafka.
Il s'agit d'un agent de logging: il a pour but de permettre la centralisation de logs hétérogènes.
Il se fonde sur FUSE pour récupérer les écritures dans des fichiers dans des répertoires surveillés
et envoyer ces dernières dans la file de message kafka, dans un format fondé sur celui du système de gestion de log logstash.

Démo

Voici une session terminal (ttyrec) montrant le système en fonctionnement:

• Télécharger la session (à lire avec ttyplay dans un terminal de 24 lignes et 70 colonnes).
• Lire la session dans un player web (playterm.org).

Les dépendances

Kafka

Kafka permet de mettre en place des files de messages distribuées à fort débit.
Il écrit les messages de manière séquentielle sur disque et profite donc des optimisations du pagecache de l'OS.
Il utilise aussi sendfile pour copier directement le contenu du pagecache vers des sockets
(évitant ainsi des copies et commutations espace utilisateur / espace noyau inutiles).

FUSE

FUSE permet d'écrire ses propres systèmes de fichiers pour Linux, et ce dans un processus en espace utilisateur.
Voici le détail de son fonctionnement.

Logstash

Logstash permet de centraliser et de traiter des logs.
Il est facilement installable et extensible grace à jruby.
Ce n'est pas une dépendance directe de fuse_kafka,
mais ce dernier enregistre dans kafka les logs dans un format proche de celui de logstash.

Fonctionnement

Voici un graphique qui résume le fonctionnement global:

Grâce à FUSE, le logiciel écoute les appels au système de fichier sur des répertoires bien définis.
fuse_kafka fonctionne en overlay, c'est à dire que le driver FUSE retransmet les appels au
système de fichier sous-jacent: quand vous accédez à des fichiers dans un répertoire géré,
vous accédez aussi vraiment au disque.
Les appels systèmes d'écriture, quand à eux sont transmis à kafka, avec des méta-données.

Exemple d'événement écrit dans kafka

Le événements sont écrits dans kafka sous format JSON/logstash, par exemple:

    { /* chemin du fichier où l'écriture a eu lieu */
     "path": "/var/log/redis_6380.log", 
     /* identifiant du processus ayant fait l'écriture */
     "pid": 1262,
     /* identifiants utilisateurs et groupes effectifs ayant fait l'écriture */
     "uid": 0, "gid": 0,
     /* contenu de l'écriture en base64, ici "hello world" */
     "@message": "aGVsbG8gd29ybGQ=",
     /* date de l'écriture */
     "@timestamp": "2014-09-11T14:19:09.000+0000",
     /* utilisateurs et groupes effectifs ayant fait l'écriture */
     "user": "root", "group": "root",
     /* commande ayant fait l'écriture */
     "command": "L3Vzci9sb2NhbC9iaW4vcmVkaXMtc2VydmVyIC",
     /* version de l'agent de logging */
     "@version": "0.1.3",
     /* champs définis lors du lancement de fuse kafka permettant
       de rajouter des meta données */
     "@fields": {
         "first_field": "first_value",
         "second_field": "second_value" },
     /* tags définis au lancement de fuse kafka permettant
       de rajouter des méta données */
     "@tags": ["mytag"]
    }

Système de quota

Il est possible de définir un quota (nombre d'octet par seconde) tel que si ce dernier est dépassé par un fichier,
L'écriture n'est pas transmise à kafka.
Cela permet de ne pas transférer des grosses écritures telles que faites sur
des fichiers comme des core dumps ou des rotations de logs.

Performances

L'écriture dans kafka est faite de manière asynchrone grace à librdkafka.
Néanmoins, FUSE ajoute nombre de commutations entre espace utilisateur et espace kernel,
ce qui ralenti les appels systèmes d'accès disques,
voilà pourquoi ce système ne devrait pas être utilisé pour les applications nécessitant un fort débit.
Des benchmarks sont disponibles ici.

Intérêts

Je vois plusieurs intérêts à cette approche:

• Ce système permet de récupérer les traces de logiciels différents, n'utilisant pas le même système de logging, (tant que leurs logs se retrouvent dans des fichiers).
• Il permet de récupérer des métadonnées intéressantes, telles que l'utilisateur, la ligne de commande ayant produit la trace.
• les événements générés contiennent la date d'écriture effective, le système de centralisation de logs n'a donc pas à parser les logs à la recherche de cette information.
• Le fait d'utiliser un format de type logstash permet de pouvoir profiter des nombreuses fonctionnalités de ce dernier.