Heka : Présentation et premières impressions
Heka, dont j’avais parlé brièvement dans ce précédent billet, est un logiciel de traitement de flux Open Source développé par Mozilla. Le développement avance bon train puisque nous en sommes déjà à la 0.9.1 au moment d’écrire ces lignes.
Heka se veut être le couteau suisse de la collecte et du traitement de données, utile pour une grande variété de tâches différentes, parmi lesquelles il est possible de citer :
- Chargement et analyse des fichiers journaux à partir d’un système de fichiers.
- Accepter les données en entrée au « format » statsd et les transmettre vers des bases de données de séries chronologiques Graphite ou InfluxDB.
- Lancement de processus externes pour recueillir les données et métriques du système local.
- Analyse en temps réel et détection d’anomalies sur les données circulant à travers le pipeline Heka.
- Envoi de données d’un endroit à un autre par l’intermédiaire d’un transport extérieur (comme AMQP) ou directement (via TCP).
- Fourniture de données traitées à un ou plusieurs puits de données persistantes.
Heka est écrit en langage Go, qui est reconnu comme bien adapté à la construction d’un pipeline de données à la fois souple et rapide. Les tests initiaux montre qu’une simple instance de Heka est capable de recevoir et de router plus de 10 gigabits de messages par seconde ! Ces chiffres impressionnants sont fournis par les développeurs de Heka.
Heka possède un tableau de bord qui présente la particularité d’être mis à jour en temps réel et ça c’est la classe ! Les données arrivent, elles sont affichées, pas de navigateur à recharger, y compris pour les graphiques.
Cette courte vidéo montre un graphique Heka représentant les entrées-sorties disque. Dès que l’on écrit sur le disque, le graphe se met à jour en temps réel.
Tout est plugin
Il y a six types de plugins différents dans Heka plus un type un peu particulier appelé « Sandbox ». Ce type offre un environnement d’exécution dynamique et confiné pour l’analyse et la transformation des données.
Entrées
Les plugins de type entrée permettent d’acquérir des données et de les injecter dans le pipeline Heka. Ils peuvent le faire en lisant les fichiers d’un système local, en activant des connexions réseau sur des serveurs distants, en écoutant sur une socket réseau, en lançant des processus sur le système local ou toute autre mécanisme.
Splitters
Les plugins de type splitter reçoivent les données qui sont en cours d’acquisition par un plugin d’entrée et les découpe dans des enregistrements séparés.
Décodeurs
Les plugins de type décodeur permettent de convertir les données entrant par les plugins d’entrée. Ils sont utiles pour l’analyse, la désérialisation ou l’extraction de la structure à partir de données non structurées.
Filtres
Les plugins de type filtre sont les moteurs de traitement de Heka. Ils sont configurés pour recevoir des messages correspondant à certaines caractéristiques spécifiques et sont en mesure d’effectuer l’agrégation et/ou le traitement des données. Les filtres sont également en mesure de générer de nouveaux messages qui peuvent être réinjectés dans le pipeline Heka, tels que les messages de synthèse contenant les données agrégées, les messages de notification dans les cas où des anomalies sont détectées.
Encodeurs
Les plugins de type encodeur sont l’inverse des décodeurs. Ils gèrent donc la sérialisation et le formatage de la sortie avant envoi vers des logiciels tiers.
Sorties
Les plugins de type sortie envoient des données vers une destination externe. Ils gèrent tous les détails de l’interaction avec le réseau, le système de fichiers ou toute autre ressource externe. Ils sont, comme les filtres, configurés à l’aide du « Message Matcher » qui permet de ne transmettre que les messages correspondant à certaines caractéristiques.
Tout est message
Toutes les données sont traitées par Heka sous forme de messages structurés comme suit :
- uuid (requis) : Un identifiant unique.
- timestamp (requis) : Nombre de nanosecondes écoulées depuis epoch UNIX.
- type (optionnel) : Type de message ex. “WebLog”.
- logger (optionnel) : Source de données ex. “Apache”, “TCPInput”, “/var/log/test.log”.
- severity (optionnel) : Niveau de sévérité Syslog.
- payload (optionnel) : Données textuelles ex. ligne de log, nom de fichier.
- env_version (optionnel) : Version sémantique du contenu du message.
- pid (optionnel) : ID du processus qui a généré le message.
- hostname (optionnel) : Nom de l’hôte qui a généré le message.
- fields (optionnel): Tableau contenant des structures de données.
Routage des messages
Heka fait appel à un mécanisme de Message Matcher pour router les messages vers les filtres adéquats en fonction de leur contenu. En voici un exemple simple :
Type == “test” && Severity == 6Chaque filtre vers lequel le message est routé reçoit alors une copie de ce message.
Installation
L’installation est simple puisque Heka est packagé pour Linux type Debian et Redhat ainsi que pour OS X. Sur mon ubuntu, un simple dpkg -i suffit donc pour installer la chose.
Une fois installé, vous disposez de 6 nouveaux binaires sur votre système :
- heka-cat
- hekad
- heka-flood
- heka-inject
- heka-logstreamer
- heka-sbmgr
Le plus important est bien sûr hekad qui est le démon responsable de la collecte et du traitement des données. Les autres binaires sont essentiellement des utilitaires qui facilitent la configuration et permettent de la tester.
A ce stade, n’essayez pas de démarrer hekad, le démon principal car il ne se passera rien. Aucun fichier de configuration n’est fourni par défaut. Il faut donc écrire un fichier minimum de configuration pour ce faire. Un fichier minimal de configuration type « Hello World » pourrait ressembler à ceci :
[LogfileInput]
logfile = "/tmp/input"
[FileOutput]
message_matcher = "Type =~ /.*/"
path = "/tmp/output"Cette configuration permet simplement de lire le fichier /tmp/input ligne par ligne pour les recracher dans /tmp/output. Aucun traitement n’est appliqué. Lisez ce billet en anglais d’où est tiré cet exemple pour en savoir plus.
Principes de configuration
Heka utilise une syntaxe TOML pour sa configuration. Celle-ci peut être éclatée en autant de fichiers que nécessaires à condition que ceux-ci se trouve dans le même dossier et qu’ils finissent par le suffixe .toml.
Les fichiers sont alors chargés par ordre alphabétique, et en cas de conflit pour un réglage, c’est le dernier précisé qui gagne.
La configuration est éclatée en sections qui représente chacune l’instanciation unique d’un plugin. Voici un exemple de section décrivant la configuration du plugin tcp:5565 :
[tcp:5565]
type = "TcpInput"
decoder = "ProtobufDecoder"
address = ":5565"Même si la configuration fait un peu mal au crâne au début, le temps de comprendre chacune des étapes que traverse une données dans le pipeline Heka, il ne m’aura pas fallu plus d’une heure pour réussir à collecter les données de charge de mon serveur, les envoyer dans InfluxDb et les grapher avec Grafana. Rien d’impossible donc même si ce début est très basique !
Je ne vais pas entrer dans le détail de la configuration de Heka dans ce billet car je suis malgré tout loin d’être au point. Ce sera pour un ou plusieurs autres articles en fonction de l’intérêt que vous portez à celui-ci et de vos commentaires… Alors faîtes du bruit !
Premiers sentiments
Si vous êtes comme moi un vieux routier de Nagios ou de solutions similaires, Heka va vous « secouer » sérieusement; au moins au départ. Sommes-nous en présence d’un « clone » de Logstash, un super Collectd ou est-ce un peu tout ça à la fois ? La comparaison la plus proche pourrait être Riemann qui fonctionne aussi sur le principe de pipeline de traitement de données.
J’ai commencé à tester le potentiel de Heka dans un setup plutôt classique pour moi désormais.
- Un serveur Elasticsearch pour stocker les messages type log.
- Un serveur InfluxDB pour stocker les métriques.
- Un serveur Kibana/Grafana pour la visualisation de ces différents types de données.
Les deux pièces de mon puzzle habituel qui sont remplacées sont Logstash et Collectd. Pas sûr cependant de pouvoir complètement remplacer Collectd mais nous n’en sommes pas encore au bilan.
Dans tous les cas, c’est un bien bel engin que nous met à disposition la fondation Mozilla. Complet puisque capable à la fois de collecter, filtrer, en/décoder, alerter, détecter des anomalies, il ne prétend pas tout faire et laisse toute la partie stockage et restitution des données à d’autres logiciels prévus pour ça.
J’apprécie la discrétion et la légéreté de Heka à la fois en terme de CPU et de mémoire. Même en envoyant des métriques toutes les secondes vers InfluxdDB, la charge ne bouge pas de 0 ! On est très loin de la goinfrerie de Logstash à ce niveau. Et c’est tant mieux pour ceux qui fonctionnent avec des VPS souvent légers en RAM… Si on veut rester dans une gamme de prix raisonnable bien sûr.
Et même si les plugins sont moins nombreux que Logstash, il y en a quelques uns comme le Docker Log Input ou le Nginx Access Log Decoder qui vont démanger les nombreux aficionados de ces technos.
Écrire des extensions ou des plugins pour Heka ne se fait pas aussi simplement que pour Nagios puisqu’il faut écrire tout ça en Go ou Lua. Pas forcément les langages de programmation les plus pratiqués par des profils admin système.
Sur ce je vous laisse, je retourne à la configuration de mon Heka. J’ai encore du boulot avant de pouvoir envoyer mes logs + métriques provenant de Nginx, php5-fpm et autres MySQL vers InfluxDB et Elasticsearch.
