BT

Interview et critique du livre : The LogStash Book, la gestion des logs rendu facile

Écrit par Aslan Brooke , traduit par David Wursteisen le 13 août 2013 |

James Tumbull a montré un cas intéressant d'utilisation de LogStash pour la centralisation de log 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'usages, 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 y connaissiez un petit peu à propos d'Unix ou de Linux." Il continue, "De plus, le livre assume que vous n'aviez aucune connaissance préalable de LogStash."

Le problème de la sur-simplification de la gestion de log

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 ça gère un début du 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 grand volume de stockage, de recherche, de filtrage. À la fin, malheureusement, cette approche inclue 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 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 les logs. Plus tôt ce mois-ci, Jordan Sissel, le créateur de LogStash, a tweeté sur Twitter que "la dernière version de logstash est livré avec kibana3 : java -jar logstash.jar kibana". James et Jordan écrivent sur Kibana parce qu'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 :

Cliquez pour l'aggrandir

Derrière la possibilité de voir les logs, il y a une architecture de composant 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é. 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 composant de l'architecture incluant : le fournisseur, le broker, l'indexateur, et le visualisateur :

Cliquez pour l'aggrandir

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 les informations 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) présent 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 éco système open source, ce qui rend logique que James ait écrit un livre à propos de LogStash, notamment parce qu'il se proclame lui même comme étant un "Geek Open Source". Tous les outils de l'écosystème de LogStash sont installables, configurables, et gérables depuis la ligne de commande, ce qui est idéal pour l'automatisation. Tout le 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, et donc le sujet suivant est l'explication de comment les composants logiciels sont installés et configurés. L'automatisation rend la construction de différents environnements fluides. C'est alors gratuit de monter/détruire des environnements pour différentes phrases d'un projet, assurance qualité, et 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 ces dépendances. De même, la philosophie principale du projet, pensé 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 et 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 paquet, tout comme avec OpenJDK, la commande sous Debian/Ubuntu est : "sudo apt-get install redis-server" et 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êt.

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 suivant : 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'application 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énement, 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'échelle de LogStash

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

Cliquez pour l'aggrandir

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ée. Alors si l'instance de Redis sélectionné devient indisponible, LogStash va commencer à envoyer à l'autre instance de Redis préalablement configuré. En tant qu'indexeur, 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'indexeur à Elasticsearch. Elasticsearch est facile à mettre en cluster et à configurer pour avoir des options de configurations 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 log 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 rapide, communauté incroyable développant des solutions et s'entre aidant, 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 avez 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 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'utilisations les plus facilement compréhensibles et les plus utiles de logging ? Si ils sont différents 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 log 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 monitorer l'état et les événements dans votre infrastructure et pour construire des métriques qui montre comment vos applications se comportent. Ceci étant dit, différentes équipes en entreprises s'inquiètent de différents aspects de ces cas d'utilisations. Par exemple, les équipes opérationelles vont se focaliser sur les logs de problème et de performance. Les développeurs d'applications seront plutôt intéressés pour 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

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 travail pour Puppet Labs gérant le service "Operations and Professional Services". James parle régulièrement en conférence incluent OSCON, Linux.conf.au, FOSDEM, OpenSourceBridge, DevOpsDays et d'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.

Bonjour étranger!

Vous devez créer un compte InfoQ ou cliquez sur pour déposer des commentaires. Mais il y a bien d'autres avantages à s'enregistrer.

Tirez le meilleur d'InfoQ

Donnez-nous votre avis

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet
Commentaires de la Communauté

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet

Discuter

Contenu Éducatif

Rien ne serait possible sans le soutien et la confiance de nos Sponsors Fondateurs:

AppDynamics   CloudBees   Microsoft   Zenika
Feedback Général
Bugs
Publicité
Éditorial
InfoQ.com et tous les contenus sont copyright © 2006-2014 C4Media Inc. InfoQ.com est hébergé chez Contegix, le meilleur ISP avec lequel nous ayons travaillé.
Politique de confidentialité
BT