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.

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.

Type == “test” && Severity == 6

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.