- OCTO talks ! - http://blog.octo.com/ -

Introduction à Flume NG

Tweet [1]

[2]

Flume est une solution de collecte, aggrégation et transfert de gros volumes de logs. Il a été pensé pour gérer des débits importants avec une fonctionnalité native d’écriture dans HDFS au fil de l’eau. Pour gérer ces gros volumes/débits, il se doit d’être très scalable, et donc distribué. L’outil fait partie de l’écosystème Big Data open source Hadoop. Pour vous aider à le situer, ses alternatives sont Scribe [3] et Chukwa [4] pour les plus connus, et également Kafka [5] même si ce dernier répond à d’autres problématiques de par sa nature (messagerie publish/subscribe).

Flume a récemment subit un lifting profond. Il aura fallu 1 an pour refondre son architecture depuis Août 2011 et réécrire certains de ses composants coeurs. Aujourd’hui, 6 mois après la première release stable, Flume NG (version 1.x) est fiable, performant, définitivement prêt pour la production. Bref il est temps de s’y pencher sérieusement. Je vous propose donc de brosser un tableau de la solution à travers ce billet, en regardant de près ses forces, mais aussi ses faiblesses…

Pourquoi NG ?

Flume a été développé au départ chez Cloudera (éditeur Hadoop) en open source sous license Apache. La première release stable de ce qu’on appelle aujourd’hui la version Flume OG (Old Generation, version 0.9.x) date de début 2010.

Flume OG a subit un refactoring profond pour plusieurs raisons, les principales sont les suivantes :

Flume NG (Next Generation) remplace donc Flume OG pour apporter une réponse à ces limitations, avec notamment une simplification de l’architecture, maintenant composée d’agents « pairs » distribués : plus besoin de master et de cluster Zookeeper.

Flume NG est devenu Top Level Apache project depuis Juillet 2012.

Une architecture composée d’agents distribués

[6]

La figure ci-dessus représente une architecture typique d’agents Flume :

L’anatomie d’un agent : route = source+channel+sink

[7]

Chaque agent exécute des « routes ». Comme illustré dans la figure ci-dessus, une route est constituée de :

Pour aller plus loin…

Point intéressant, il est possible d’implémenter des sources, channels et sinks customs pour étendre les fonctionnalités disponibles par défaut. Il suffit d’implémenter les interfaces Java dédiées, et de déclarer ces classes dans le fichier de configuration Flume.

[11]

Comme le montre la figure précédente, il existe d’autres composants permettant de rendre le flux de données plus intelligent avec d’autres types de composants :

Installation, configuration et exploitation simplissimes!

L’installation est relativement simple : installer un JDK, définir la variable d’environnement JAVA_HOME, télécharger et dézipper Flume et c’est parti! Bon OK, il faudra aussi ajouter le script de démarrage du service dans /etc/init.d, créer les répertoires /var/run/flume et /var/log/flume avec les bons droits… mais rien d’exotique dans tout ça. Vous trouverez une recette Puppet sur mon GitHub [12] si ça vous intéresse. Enfin n’oubliez pas d’installer les libs Hadoop sur la machine si l’agent doit écrire dans HDFS.

Pour démarrer l’agent, il faut exécuter la commande « flume-ng » avec quelques paramètres, par exemple :

flume-ng agent -n agent1 -f /usr/local/lib/flume-ng/conf/flume.conf -c /usr/local/lib/flume-ng/conf

La configuration est également triviale, il suffit d’éditer un fichier properties avec des paramètres explicites. En voici un exemple :

agent1.channels = memoryChannel
agent1.channels.memoryChannel.type = memory
agent1.channels.memoryChannel.capacity = 100000
agent1.channels.memoryChannel.transactionCapacity = 1000

agent1.sources = tailSource
agent1.sources.tailSource.channels = memoryChannel
agent1.sources.tailSource.type = exec
agent1.sources.tailSource.command = /usr/local/flume-tools/bin/xtail-custom -d /app/logs
agent1.sources.tailSource.batchSize = 100
agent1.sources.tailSource.interceptors = timestampInterceptor
agent1.sources.tailSource.interceptors.timestampInterceptor.type = timestamp

agent1.sinks = hdfsSink
agent1.sinks.hdfsSink.channel = memoryChannel
agent1.sinks.hdfsSink.type = hdfs
agent1.sinks.hdfsSink.hdfs.rollInterval = 360
agent1.sinks.hdfsSink.hdfs.rollCount = 0
agent1.sinks.hdfsSink.hdfs.rollSize = 0
agent1.sinks.hdfsSink.hdfs.batchSize = 1000
agent1.sinks.hdfsSink.hdfs.txnEventMax = 1000
agent1.sinks.hdfsSink.hdfs.codeC = snappyCodec
agent1.sinks.hdfsSink.hdfs.fileType = SequenceFile
agent1.sinks.hdfsSink.hdfs.path = hdfs://namenode:8020/user/hdfs/data/importFlume/dt=%Y%m%d/

Le fichier de configuration ci-dessus permet de configurer une route avec :

Côté exploitation, Flume dispose comme Hadoop d’une fonctionnalité d’export des métriques dans Ganglia grâce à l’ajout de deux paramètres de lancement :

flume-ng agent ... -Dflume.monitoring.type=ganglia -Dflume.monitoring.hosts=com.example:1234

On peut également exposer les métriques en JSON de la même manière :

flume-ng agent ... -Dflume.monitoring.type=http -Dflume.monitoring.port=34545

Les logs sont propres et les messages d’erreur plutôt clairs et explicites.

A noter également que les éditeurs travaillent d’arrache pied pour offrir des outils clés en main (ex: Cloudera Manager, HortonWorks Data PLatform, …) pour industrialiser tous ces processus : installer et configurer Flume en quelques clics, superviser les agents (même si ça reste moins poussé que dans Ganglia), etc.

Forces et faiblesses de la solution

Forces :

Faiblesses :