James Turnbull a montré un cas intéressant d'utilisation de LogStash pour la centralisation de logs en expliquant les détails d'implémentation de LogStash dans le cadre d'un projet de logging. Le livre cible aussi bien les petites que les grandes entreprises à travers deux cas d'usage, chacun pour le faible coup d'entrée et la scalabilité. James a parlé du livre sur Hangops en février de cette année, "Il est conçu pour les personnes qui n'ont jamais vu LogStash auparavant, administrateurs système, développeurs, devops, opérationnels. J'attends de vous que vous vous y connaissiez un petit peu à propos d'Unix ou de Linux". Il continue, "De plus, le livre assume que vous n'ayez aucune connaissance préalable de LogStash".

Le Problème de la Sur-Simplification de la Gestion de Logs

James vient avec son expérience de l'administration système et sécurité. Il explique comment l'environnement informatique a fait évoluer la gestion des logs dans un sens qui ne scale pas.

Il partage ce qui sort généralement d'un process évolutif, en commençant avec les logs qui deviennent plus importants, c’est-à-dire quand les problèmes arrivent. À ce moment-là, les nouveaux administrateurs vont commencer par examiner les logs avec les outils classiques tels que cat, tail, sed, awk, perl et grep. Cette pratique permet de développer un bon ensemble de compétences autour des outils utiles, pourtant, ça ne va pas plus loin que quelques machines et types de fichiers. Quand on s'aperçoit d'un problème de scalabilité, les équipes changent en utilisant du log centralisé avec des outils tels que rsyslog et syslog-ng.

Bien que cela commence à gérer le problème de mise à l'échelle, James partage le fait que ça ne résout pas vraiment le problème de gestion des logs parce que maintenant, il y a une explosion des différents types de logs, différents formats, différents fuseaux horaires et un manque de contexte facilement compréhensible. Enfin, une équipe peut moderniser son environnement informatique avec des technologies de logging qui peuvent gérer de grands volumes de stockage, de recherche, de filtrage. À la fin, malheureusement, cette approche inclut un vaste gâchis et à un prix relativement élevé. LogStash économise des jours en répondant au besoin d'un faible coup d'entrée comme les outils classiques d'administrateurs systèmes, mais il est architecturé pour s'adapter à un déploiement de site web à grande échelle.

Aperçu de l'Architecture de LogStash

LogStash fournit une architecture pour collecter, parser et garder des logs. En outre, l'un des cas d'utilisation transverse pour une mise en oeuvre de LogStash est de voir/rechercher dans les logs. James recommande le projet open source Kibana pour chercher dans ceux-ci. Plus tôt ce mois-ci, Jordan Sissel, le créateur de LogStash, a tweeté que "la dernière version de logstash est livrée avec kibana3 : java -jar logstash.jar kibana". James et Jordan écrivent sur Kibana car il fournit une interface utilisateur simple pour faire de la recherche qui est intégrée avec Elasticstorage, le moteur de stockage pour LogStash. La capture d'écran suivante de Kibana vient du chapitre 3 du livre de LogStash, vous pouvez essayer une démo en ligne :

Derrière la possibilité de voir les logs, il y a une architecture de composants qui gère le flux de logs depuis différents serveurs en passant par un broker, puis en les stockant. James emporte les lecteurs à travers une exploration de chaque composant de la configuration par défaut de LogStash, qui utilise Redis, une base clé-valeur, pour mettre à la suite les logs en vue d'être indexés. LogStash utilise aussi Elasticsearch pour le stockage des logs et comme backend du système de visualisation. Le diagramme suivant du chapitre 3 montre distinctement les types de composants de l'architecture incluant : le fournisseur, le broker, l'indexateur et le visualisateur :

Dans le livre, James rentre dans les trois fonctions principales d'une instance LogStash : recevoir des événements en entrée, filtrer les données de ces événements, et sortir ces événements. Ces trois fonctions de LogStash sont effectuées en se basant sur l'information de configuration enregistrée dans un fichier facilement compréhensible de type ".conf". Le fichier de type ".conf" possède des sections pour trois différents types de plugins que LogStash utilise : input (entrée), filter (filtrage), et output (sortie). Chaque instance de LogStash est personnalisée pour jouer son rôle dans l'architecture globale. Par exemple, cette configuration pour un fournisseur (contenant une entrée et deux sorties) qui est présente dans le chapitre 3 :

input {
        redis {
                host => "10.0.0.1"
                type => "redis-input"
                data_type => "list"
                key => "logstash"
        }
}
output {
        stdout {
                debug => true
        }
        elasticsearch {
                cluster => "logstash"
        }
}

Le Projet Open Source LogStash rentre dans la Culture DevOps

LogStash est un outil open source qui a été construit pour fonctionner dans un écosystème open source, ce qui rend logique que James ait écrit un livre à propos de LogStash, notamment puisqu'il se proclame lui-même comme étant un "Geek Open Source". Tous les outils de l'écosystème de LogStash peuvent être installés, configurés et gérés depuis la ligne de commande, ce qui est idéal pour l'automatisation. Tout au long du livre, James rend évident qu'utiliser un système de gestion de configuration automatique pour contrôler l'installation/configuration de chaque composant de LogStash est l'idéal. Cependant, ce sujet est hors du scope du livre, donc le point suivant abordé est la manière dont les composants logiciels sont installés et configurés. L'automatisation rend la construction de différents environnements fluide. C'est alors gratuit de monter/détruire des environnements pour différentes phases d'un projet, questions-réponses, résolution des problèmes, et en support de l'intégration continue.

Installation de Java, LogStash, Redis et Elasticsearch

James montre étape par étape comment il est facile d'installer LogStash et ses dépendances ; ce qui soutient la philosophie principale du projet, pensée par Jordan Sissel : "Communauté : si un débutant passe un mauvais moment, c'est un bug". LogStash dépend de Java, donc installer au moins OpenJDK est nécessaire pour lancer LogStash. La plupart des distributions Linux ont rendu OpenJDK disponible directement à partir de leurs systèmes de gestion de package. Par exemple, sur Debian/Ubuntu, la commande est "sudo apt-get install openjdk-7-jdk" pour l'installer. Sur Red Hat/Centos, la commande est "sudo yum install java-1.7.0-openjdk". Jordan Sissel distribue LogStash dans un seul fichier Jar qui peut être téléchargé depuis le site LogStash.net. Le fichier Jar et un fichier de configuration spécifié dans la ligne de commande sont les seules choses nécessaires pour lancer LogStash avec OpenJDK. Redis est facilement installable via les gestionnaires de paquets. Tout comme avec OpenJDK, la commande sous Debian/Ubuntu est : "sudo apt-get install redis-server". Sur Red Hat/Centos, c'est "sudo yum install redis". Redis peut commencer à traiter des événements après avoir modifié quelques options de configuration du fichier "/etc/redis/redis.conf" et après avoir démarré Redis en tant que service. ElasticSearch, comme LogStash, n'a besoin que de Java. ElasticSeach peut être téléchargé comme un paquet ".deb" pour les distributions Debian/Ubuntu Linux, et comme un paquet ".rpm" pour les linux Red Hat/Centos. Il y a un petit peu de configuration au niveau du fichier"/etc/elasticsearch/elasticsearch.yml" à faire et vous serez alors prêts.

Les Composants de LogStash : Fournisseur (Shipper), Broker, Indexateur (Indexer)

Le livre couvre les trois types de plugins de LogStash dans leurs contextes d'utilisation pour le fournisseur et l'indexateur. James montre comment utiliser ces plugins d'entrée suivants : file, stdin, syslog, lumberjack et redis. Pour les environnements où LogStash ne peut être installé, il y a d'autres options pour envoyer des événements qui s'intègrent avec LogStash : syslog, Lumberjack, Beaver et Woodchuck. Il y a recouvrement entre les plugins d'entrée et de sortie dans LogStash, par exemple il y un plugin d'entrée et de sortie pour Redis. En plus des deux types de sorties principales, Redis et ElasticsSarch, James couvre aussi d'autres types de sortie pour d'autres systèmes incluant : Nagios, alerte par email, messages instantanés et StatsD/Graphite. Les filtres couverts dans le livre incluent : grok, data, grep et le multiligne. James montre comment le plugin peut être utilisé efficacement pour traiter des logs venant de postfix et d'applications java. Dans certains cas, les logs peuvent être filtrés avant que LogStash ne les utilise comme entrée. Par exemple, Apache Logging a un format spécial permettant de logguer dans le format JSON que LogStash peut facilement traiter sans le filtre interne. Le broker, que l'on a spécifié comme étant Redis, est pour la gestion du flux d'événements, LogStash supporte ces différentes technologies de système de queue pour ce rôle de broker : AMPQ et ZeroMQ. L'instance d'indexateur de LogStash effectue le routage pour la recherche/stockage.

Mise à l'Echelle de LogStash

Scaler LogStash accomplit trois de ces principaux buts : résilience, performance et intégrité. Le diagramme suivant provient du chapitre 7 du livre. Il illustre la scalabilité de Redis, LogStash et Elasticsearch :

LogStash ne dépend pas de Redis pour gérer la reprise sur erreur. À la place, LogStash envoie les événements à une des deux instances de Redis configurées. Alors si l'instance de Redis sélectionnée devient indisponible, LogStash va commencer à envoyer à l'autre instance de Redis préalablement configurée. En tant qu'indexateur, LogStash est facilement scalable en créant de multiples instances qui continueront à aller chercher l'information auprès des différents brokers disponibles et sortir le tout pour Elasticsearch. Avec cette représentation, les événements ne passent que par un broker, et donc il n'y aura pas d'événements dupliqués qui passeront de l'indexateur à Elasticsearch. Elasticsearch est facile à mettre en cluster et à configurer pour avoir des options de configuration communes. Elasticsearch utilise le multicast, l'unicast, ou un plugin EC2 pour se mettre en cluster, en se basant sur la configuration de chaque instance individuelle. Tant que le réseau permet aux différentes instances de communiquer, elles vont se mettre d'elles-mêmes en cluster et commencer à se partager les données. Le partage des données est fait automatiquement pour fournir de la résilience et de la performance.

InfoQ s'est également entretenu avec James Turnbull à propos de LogStash.

InfoQ : Quels sont les bénéfices et les coûts, d'après vous, d'un exemple réussi d'application d'un système de logs centralisé basé sur LogStash ?

James : Le bénéfice de LogStash est typique de la plupart des outils de gestion de système open source : faible coût du logiciel, open source et par conséquent extensible, développement et correction de bugs rapides, communauté incroyable développant des solutions et s'entraidant, tout en ayant l'habilité de vous montrer la route pour résoudre vos problèmes. Le coût est aussi proche de la plupart des outils open source : pas de support commercial, pas aussi complet que les alternatives commerciales, et peut avoir un coût d'entrée plus cher, que ce soit pour le niveau nécessaire et la documentation disponible (bien que maintenant vous ayez un super livre !) pour l'implémentation.

InfoQ : Pourquoi un DevOps d'une équipe orientée sur les technologies choisirait un outil open source du système de LogStash plutôt qu'un outil commercial comme Splunk ?

James : le premier facteur pour ce choix, pour une équipe DevOps, serait le coût. Tandis que LogStash (et son tableau de bord Kibana) ne rivalise pas (pour l'instant) avec les capacités de Splunk, ils sont gratuits et gagnent rapidement en fonctionnalités. Tandis que Splunk vient avec un prix considérable que la plupart des petites organisations ne peuvent pas se permettre. Bien sûr, il est important de noter que bien que le logiciel soit gratuit, il y a toujours un coût d'implémentation qui peut être, ou ne pas être, similaire en comparaison à un outil commercial.

InfoQ : Quels sont les cas d'utilisation les plus facilement compréhensibles et les plus utiles de logging ? S'ils sont divergents pour différents rôles dans une entreprise, pourriez-vous décrire en quoi ?

James : Les meilleurs cas d'utilisation pour le logging sont les problèmes et le monitoring. Les données de logs de vos applications sont souvent la meilleure source d'information quand vous avez un problème dans votre infrastructure. Ils représentent également une excellente source de données pour contrôler l'état et les événements dans votre infrastructure et pour construire des métriques qui montrent comment vos applications se comportent. Ceci étant dit, différentes équipes en entreprise s'inquiètent de différents aspects de ces cas d'utilisation. Par exemple, les équipes opérationnelles vont se focaliser sur les logs de problème et de performance. Les développeurs d'applications seront plutôt intéressés à utiliser les logs pour les aider à trouver et corriger des bugs. Les équipes sécurité vont se focaliser sur l'identification de vulnérabilité et des incidents de sécurité que les logs peuvent mettre en lumière.

A propos de l'Auteur du Livre :

James Turnbull est l'auteur de six livres techniques sur le sujet du logiciel open source et un vieux membre de la communauté open source. James est l'auteur du premier (et du second !) livre sur Puppets et travaille pour Puppet Labs gérant le service "Operations and Professional Services". James parle régulièrement lors de conférences telles que OSCON, Linux.conf.au, FOSDEM, OpenSourceBridge, DevOpsDays et autres. Il est l'ancien président de Linux Australia, un ancien membre du comité de Linux Victoria, était trésorier pour Linux.conf.au 2008, et oeuvre au sein du programme du comité de Linux.conf.au et OSCON.