Un grand nombre de systèmes de journalisation sont présentés sur le marché - à la fois ouverts et propriétaires. Chacun d'eux a sa propre fonctionnalité, ses propres avantages et inconvénients.
Aujourd'hui, nous avons décidé de partager notre expérience dans le choix d'un système de journalisation et de nous dire pourquoi nous nous sommes arrêtés à ELK dans
1cloud .
/ Pixabay / picupyourphoto / PDThéorie des minutes
Lors du passage à la production, les applications se transforment en une sorte de "boîtes noires". Leur travail doit être surveillé en permanence pour prévenir les situations d'urgence potentielles et y répondre, pour éviter les goulots d'étranglement.
Les systèmes d'enregistrement sont un outil indispensable qui ne peut être évité dans ce processus. En effectuant une analyse détaillée des données collectées, il est possible d'identifier les «intrusions» dans le réseau, d'identifier les équipements mal configurés et de prendre des mesures rapides. En outre, la journalisation est une exigence obligatoire lors de la réussite de divers types de certifications, telles que PCI DSS.
Il existe des cadres spéciaux pour l'automatisation des processus de journalisation: log4j, log4net, Retrace, Logback, Logstash et autres - ils sont nombreux. Leurs outils de journalisation ont des outils de développement séparés, par exemple JDK -
il y a java.util.logging . Bien entendu, les fonctionnalités des différents outils de journalisation sont différentes et l'ensemble de fonctions nécessaire doit être sélectionné en fonction des besoins de l'entreprise. Cependant, il convient de noter un certain nombre de points généraux lors du choix d'un système d'analyse des journaux.
Facilité d'utilisation et taille de la communauté
La simplicité est l'un des éléments clés lors du choix d'un système de journalisation. Tous les développeurs de l'équipe travaillent avec des cadres de journalisation, donc l'expérience de l'utilisation de cet outil doit être positive et ne pas transformer l'analyse des journaux en cauchemar. L'API du framework doit être intuitive pour que tous ceux qui n'ont pas travaillé avec le système auparavant puissent rapidement comprendre comment il est organisé et configuré.
Si nous considérons le système de journalisation open source, il est logique d'évaluer la communauté qui s'est formée autour de lui. Pour ce faire, vous pouvez étudier la fréquence à laquelle il est mentionné sur les plateformes spécialisées (
Stack Overflow ), ainsi que dans les threads spécialisés,
par exemple, sur Reddit . En option, regardez la popularité du projet sur GitHub (le nombre d'étoiles) et voyez combien de fois il est entré dans diverses collections d'outils sur le réseau (
comme celles-ci ). Évidemment, plus la communauté est grande, plus il y a de chances que vous soyez aidé en cas de difficultés imprévues.
Quant au choix des systèmes de journalisation propriétaires, il convient tout d'abord de s'intéresser à la rapidité des réponses et à l'adéquation du service support de la solution choisie, ainsi que son prix.
La possibilité de collecter des journaux "divers"
Toutes les plateformes de journalisation ne sont pas capables de traiter une grande quantité de données et de fournir des informations complètes sur les systèmes utilisés.
Avant de choisir une solution, il convient de décider quels journaux vous prévoyez de collecter: journaux HTTP (aideront à comprendre le comportement des utilisateurs sur le site), journaux d'API (permettront d'évaluer quels services sont le plus souvent demandés par l'API), journaux d'erreurs et simplement enregistrer les modifications apportées à système (indiquer les goulots d'étranglement, le cas échéant).
Évolutivité
L'outil de journalisation doit collecter les journaux de chaque composant du système et leur donner accès en un seul endroit. Si le système n'est pas adapté à la mise à l'échelle, la qualité de l'analyse du journal diminuera.
Dans 1cloud, nous avons initialement utilisé MS SQL pour la journalisation. Cependant, avec une augmentation du nombre de clients et de services (par exemple, plus récemment,
nous avons déployé des équipements dans le centre de données de Minsk et
ajouté la prise en charge IPv6 ), nous avions des composants d'infrastructure géographiquement dispersés qui n'avaient pas accès à la base de données. Et l'une de nos tâches principales était de maintenir la capacité d'analyser les journaux à partir d'un seul endroit.
Système d'enregistrement 1cloud
Comme nous l'avons déjà noté, MS SQL a été utilisé pour stocker les journaux dans 1cloud, et log4net a été utilisé pour les enregistrer. Et cela a commencé à nous créer certaines difficultés. En raison de composants géographiquement dispersés, il est devenu impossible de maintenir la connectivité réseau avec la base de données et de fournir un point unique pour l'analyse.
Dans le même temps, un grand volume de journaux et l'impossibilité de construire des index sur tous les champs que nous devons rechercher ont conduit à une simplification excessive de l'analyse des journaux - nous avons dû abandonner les fonctionnalités pour des raisons de performances.
Pour résoudre ce problème et fournir une évolutivité, nous avons introduit un nouveau système de journalisation. Au total, nous avons étudié plus de cinquante solutions différentes et identifié quatre qui répondent pleinement à nos exigences:
- un seul endroit pour stocker les journaux;
- mise à l'échelle horizontale du système si nécessaire;
- traiter de grandes quantités de données;
- puissant système d'analyse des journaux.
Ces quatre solutions sont: Fluentd, Graylog, Logalyse et Logstash.
La solution a 9,2 mille étoiles sur
GitHub . Logstash est sous licence Apache 2.0 et fait partie de la pile ELK. Il a un grand nombre de plugins (
il y en a environ 250 sur GitHub). Il fonctionne sous Windows et Linux et a des performances élevées, qui sont pratiquement indépendantes des volumes de données.
Le système
vous permet de consulter et d'analyser rapidement les événements des postes de travail, des pare-feu, des routeurs et des commutateurs. Cela est dû au fait qu'il n'y a pas besoin de "normalisation" des événements.
Cependant, il faut comprendre qu'il s'agit d'un moteur «nu», car il ne fournit pas de visualisations toutes faites. Entre autres lacunes, nous notons la nécessité d'installer Java sur tous les serveurs, puisque Logstash est écrit en Ruby (JRuby).
La solution a une communauté assez large: il y a un
canal IRC et un
forum séparé. Il existe des exemples sur le réseau pour la
configuration de l'ensemble du système et de l'
API .
Les organisations suivantes
utilisent Logstash: CERN Control Center, GitHub, SoundCloud.
6,6 mille étoiles sur
GitHub . Distribué sous licence Apache 2.0 par la
CNCF (Cloud Native Computing Foundation) - il a été
fondé par Google et The Linux Foundation pour promouvoir la technologie des conteneurs.
Fluentd fonctionne sur Linux, Windows et Mac et est écrit en Ruby (CRuby). Fluentd a un
système de plugin flexible qui étend ses fonctionnalités.
La solution a un format de journalisation unifié: Fluentd essaie de convertir les données reçues au format JSON. Pour assurer un fonctionnement fiable, des solutions tierces ne sont pas nécessaires, cependant, pour cela, il est nécessaire d'effectuer une configuration supplémentaire. Il est également déconseillé de l'installer sur des serveurs générant des journaux.
La communauté est grande: il y a une
chaîne dans Slack , ainsi qu'un
fil dans Google Groupes . Sur le site officiel du projet,
il y a des exemples de configurations et d'
API . Des entreprises comme Microsoft, Amazon, change.org et Nintendo utilisent Fluentd.
4,3 mille étoiles sur
GitHub . Distribué sous la licence GNU GPL v3. Cela ne fonctionne que sous Linux. Un
écosystème centralisé
de plugins et un système de tampon personnalisé. Pour plus de commodité, il permet au mot clé de combiner les messages entrants en flux et de regrouper ces flux à partir de différents hôtes.
Le système utilise les fonctions Elasticsearch, mais malgré les mises à jour fréquentes de Graylog et de la communauté développée (il y a un
forum , un
canal IRC ,
il y a des exemples de configurations et d'
API sur le site officiel du projet), l'intégration des versions actuelles d'Elasticsearch dans le projet prend beaucoup de temps. Par exemple, l'année dernière, une situation s'est produite où Graylog 2.2.1 (le dernier à l'époque)
ne fonctionnait qu'avec Elasticsearch version 2.4.4, qui était considérée comme obsolète.
Dans son travail, Graylog
utilise l' Agence européenne pour l'environnement, Dial Once, Stockopedia et autres.
Il fonctionne sous Linux et Windows. Le système a de hautes performances et peut générer des rapports détaillés sur les mots clés. Il y a un sérieux inconvénient: LOGalyze collecte les journaux dans sa base de données de fichiers, où il les indexe, occupant ainsi une quantité importante d'espace disque.
Les développeurs de LOGalyze
ont leur propre blog et la discussion de la solution a lieu dans des
groupes Google . Il existe un guide
pour la configuration du système et la
migration des données, ainsi que la
CLI .
Après avoir évalué ces quatre options, nous avons opté pour Logstash et avons décidé d'organiser une pile ELK (ElasticSearch, Logstash, Kibana). Parmi ceux-ci, Elasticsearch est un moteur de recherche, Logstash est un mécanisme de collecte et d'analyse des journaux, et Kibana est engagé dans l'analyse et la visualisation des données.
Nous avons choisi ELK, car les trois composants sont développés par un "fabricant", ils s'intègrent donc bien les uns aux autres. Si nécessaire, nous pouvons utiliser chacun de ces outils individuellement pour résoudre d'autres problèmes.
Cette approche rend le produit flexible et polyvalent. Tout cela permettra un traitement plus efficace des volumes de données existants et une mise en œuvre plus rapide de nouveaux services - il sera plus facile de se connecter.
L'environnement de test est maintenant prêt. Il «couvre» tous les services dont nous analyserons les journaux. Nous terminons les derniers processus de débogage et prévoyons un lancement à part entière de la solution dans un avenir proche.
Soit dit en passant, malgré le fait que nous ayons analysé en détail diverses options et choisi la meilleure pour nos besoins, ce n'était finalement pas sans une mouche dans la pommade. Lors du test de la solution, nous avons été confrontés à une situation où Kibana a abandonné Elasticsearch sur demande - ce qui est considéré comme un cas extrêmement rare et dégénéré. Au cours de l '"assemblage" du système, un certain nombre de questions se sont posées, principalement liées à la sécurité. Dans la version de base, Elasticsearch n'est protégé par rien - il était nécessaire d'adapter un logiciel tiers à ces fins.
Après le lancement, nous mettrons en place des systèmes de surveillance pour répondre le plus rapidement possible aux pannes du service de journalisation. Nous espérons que la nouvelle pile technologique améliorera l'expérience utilisateur de nos clients et développera nos services plus rapidement.
Documents de notre blog d'entreprise: