Notre chemin vers un stockage centralisé des journaux

Salutations à tous! Je travaille comme ingénieur système chez Onlanta . Dans l'un de nos projets, j'ai participé à la mise en œuvre et à la maintenance d'Elastic Stack. Nous sommes passés de la collecte des journaux virtuellement à la main à un processus centralisé et automatisé. Depuis deux ans maintenant, nous n'avons pratiquement pas changé l'architecture de la solution et prévoyons d'utiliser un outil pratique dans d'autres projets. Je partage avec vous notre historique de sa mise en œuvre, ainsi que certaines forces et faiblesses de ce billet.

Source

Au début de 2016, les journaux de nos administrateurs et développeurs étaient, pour ainsi dire, «à portée de main», c'est-à-dire un ingénieur pour travailler avec eux connectés via SSH à l'hôte où le service qui l'intéressait, a découvert l'ensemble universel de tail / grep / sed / awk et espérait qu'il serait possible de trouver les données nécessaires sur cet hôte.

Source

Nous avions également un serveur séparé, où tous les répertoires contenant les journaux de tous les serveurs étaient montés via NFS, et qui était parfois longuement réfléchi à ce que tout le monde voulait faire avec les journaux qu'il contenait. Eh bien, tmux avec plusieurs panneaux tournant sur certains journaux activement mis à jour semblait très impressionnant pour les étrangers sur un grand moniteur et a créé une atmosphère passionnante d'implication dans les sacrements de la production.

Tout cela a même fonctionné, mais exactement jusqu'à ce qu'il soit nécessaire de traiter rapidement une grande quantité de données, et cela était le plus souvent requis aux moments où quelque chose était tombé dans la prod.

Parfois, il fallait un temps indécent pour enquêter sur des incidents. Une partie importante de celui-ci a été consacrée à l'agrégation manuelle des journaux, au lancement de béquilles de divers scripts dans Bash et Python, en attendant que les journaux soient téléchargés quelque part pour l'analyse, etc.

En un mot, tout cela a été très lent, inspiré par le découragement et laissé entendre sans équivoque qu'il était temps de s'occuper du stockage centralisé des journaux.

Pour être honnête, il n'y avait pas de processus compliqué de sélection des candidats pour le rôle de la pile technologique qui nous fournirait cela: alors le bundle ELK était déjà populaire à l'époque, avait une bonne documentation, il y avait un grand nombre d'articles sur Internet pour tous les composants. La décision a été immédiate: il faut essayer.

Source

La toute première installation de la pile a été effectuée après avoir regardé le webinaire «Logstash: 0-60 en 60» sur trois machines virtuelles, chacune ayant lancé une instance d'Elasticsearch, Logstash et Kibana.

De plus, nous avons rencontré des problèmes avec la livraison des journaux des hôtes finaux aux serveurs Logstash. Le fait est qu'à cette époque, Filebeat (une solution de pile standard pour fournir des journaux à partir de fichiers texte) fonctionnait bien pire avec des fichiers volumineux et rapidement mis à jour, régulièrement divulgués en RAM et dans notre cas dans son ensemble, ne pouvait pas faire face à sa tâche.

À cela a été ajoutée la nécessité de trouver un moyen de fournir des journaux de serveur d'applications à partir de machines exécutant IBM AIX: la majeure partie de nos applications ont ensuite été lancées dans WebSphere Application Server, qui fonctionnait spécifiquement sous ce système d'exploitation. Filebeat est écrit en Go, il n'y avait pas de compilateur Go plus ou moins efficace pour AIX en 2016, et je ne voulais vraiment pas utiliser Logstash comme agent de livraison.

Nous avons testé plusieurs agents de livraison de journaux: Filebeat, logstash-forwarder-java, log-courier , python-beaver et NXLog. De la part des agents, nous nous attendions à des performances élevées, une faible consommation de ressources système, une intégration facile avec Logstash et la possibilité d'effectuer des manipulations de données de base avec les forces de l'agent (par exemple, l'assemblage d'événements multilignes).

À propos de l'assemblage d'événements multilignes, il convient de mentionner séparément. En effet, il ne peut être exécuté que du côté de l'agent qui lit un fichier spécifique. Malgré le fait que Logstash avait autrefois un filtre multiligne et dispose désormais d'un codec multiligne, toutes nos tentatives pour combiner l'équilibrage des événements sur plusieurs serveurs Logstash avec un traitement multiligne ont échoué. Cette configuration rend l'équilibrage efficace des événements presque impossible, par conséquent, pour nous, le facteur le plus important lors du choix des agents était le support multiligne.

Les gagnants étaient les suivants: log-courrier pour les machines avec Linux, NXLog pour les machines avec AIX. Avec cette configuration, nous avons vécu presque un an sans aucun problème: les logs ont été livrés, les agents ne sont pas tombés (enfin, presque), tout le monde était content.

En octobre 2016, la cinquième version des composants d'Elastic Stack a été lancée, notamment Beats 5.0. Beaucoup de travail a été fait sur tous les agents Beats dans cette version, et nous avons pu remplacer le journal-messagerie (qui à ce moment-là avait ses propres problèmes) par Filebeat, que nous utilisons toujours.

Lors de la migration vers la version 5.0, nous avons commencé à collecter non seulement des journaux, mais aussi certaines mesures: Packetbeat a commencé à être utilisé ici et là comme alternative à l'écriture de journaux de requêtes HTTP dans des fichiers, et Metricbeat a collecté des métriques système et des métriques de certains services.

À ce stade, le travail de nos ingénieurs avec les journaux est devenu beaucoup plus simple: maintenant, il n'était plus nécessaire de savoir sur quel serveur aller pour consulter le journal qui vous intéresse, l'échange d'informations trouvé a été simplifié en transférant simplement le lien vers Kibana dans les salles de discussion ou le courrier, et les rapports qui ont été précédemment créés en quelques heures, a commencé à être créé en quelques secondes. On ne peut pas dire que ce n'était qu'une question de confort: nous avons constaté des changements dans la qualité de notre travail, dans la quantité et la qualité des tâches fermées, dans la rapidité de réponse aux problèmes sur nos stands.

À un moment donné, nous avons commencé à utiliser l'utilitaire ElastAlert de Yelp pour envoyer des alertes aux ingénieurs. Et puis nous avons pensé: pourquoi ne pas l'intégrer à notre Zabbix pour que toutes les alertes aient un format standard et soient envoyées de manière centralisée? La solution a été trouvée assez rapidement: ElastAlert vous permet d'exécuter toutes les commandes au lieu d'envoyer des alertes, que nous avons utilisées.

Désormais, nos règles ElastAlert, lorsqu'elles sont déclenchées, exécutent un script bash sur plusieurs lignes, auquel les données nécessaires sont transmises dans les arguments de l'événement qui a déclenché la règle, et zabbix_sender est appelé à partir du script, qui envoie les données à Zabbix pour le nœud souhaité.

Étant donné que toutes les informations sur qui a généré l'événement et où sont toujours disponibles dans Elasticsearch, il n'y a eu aucune difficulté d'intégration. Par exemple, nous avions auparavant un mécanisme pour détecter automatiquement les serveurs d'applications WAS, et dans les événements qu'ils génèrent, le nom du serveur, du cluster, de la cellule, etc. est toujours écrit. Cela nous a permis d'utiliser l'option query_key dans les règles ElastAlert afin que les conditions des règles soient traitées séparément pour chaque serveur. Le script avec zabbix_sender obtient alors les "coordonnées" exactes du serveur et les données sont envoyées à Zabbix pour le nœud correspondant.

Une autre solution que nous aimons vraiment et qui a été rendue possible grâce à la collecte centralisée des journaux est un script pour créer automatiquement des tâches dans JIRA: une fois par jour, il supprime toutes les erreurs des journaux et, s'il n'y a pas encore de tâches, les démarre. Dans le même temps, à partir de différents index par un ID de demande unique, toutes les informations pouvant être utiles dans l'enquête sont récupérées dans la tâche. Le résultat est une sorte de pièce standard avec les informations minimales nécessaires, que les ingénieurs peuvent compléter si nécessaire.

Bien sûr, nous avons été confrontés à la question de la surveillance de la pile elle-même. Ceci est partiellement implémenté en utilisant Zabbix, en utilisant partiellement le même ElastAlert, et nous obtenons les principales mesures de performances pour Elasticsearch, Logstash et Kibana en utilisant la surveillance standard intégrée à la pile (composant de surveillance dans le X-Pack). De plus, sur les serveurs avec les services de pile eux-mêmes, nous avons installé des données réseau de Firehol. Il est utile lorsque vous avez besoin de voir ce qui arrive à un nœud particulier en ce moment, en temps réel et à haute résolution.

Il était une fois, le module de surveillance Elasticsearch était légèrement cassé, nous l'avons trouvé, corrigé, ajouté toutes sortes de métriques utiles et fait une demande de pull. Désormais, netdata peut surveiller les dernières versions d'Elasticsearch, y compris les métriques JVM de base, l'indexation, les indicateurs de performance de recherche, les statistiques du journal des transactions, les segments d'index, etc. Nous aimons Netdata et nous sommes ravis d'avoir pu y apporter une petite contribution.

Aujourd'hui, après presque trois ans, notre pile élastique ressemble à ceci:


Les ingénieurs travaillent avec la pile de trois manières principales:

• afficher et analyser les journaux et les mesures dans Kibana;
• tableaux de bord à Grafana et Kibana;
• diriger les requêtes vers Elasticsearch à l'aide de SQL ou de la requête DSL intégrée.

Au total, toutes ces ressources sont allouées: 146 CPU, 484 Go de RAM, 17 To sont alloués à l'entrepôt de données Elasticsearch.

Au total, nous avons 13 machines virtuelles fonctionnant dans le cadre d'Elastic Stack: 4 machines pour les nœuds Elasticsearch «chauds», 4 pour les nœuds «chauds», 4 machines avec Logstash et une machine d'équilibrage. Sur chaque nœud actif, Elasticsearch exécute une instance Kibana. Cela s'est produit dès le début, et jusqu'à présent, nous n'avons pas eu à déplacer Kibana vers des voitures séparées.

Mais la décision de prendre Logstash sur des machines séparées s'est avérée être l'une des plus correctes et efficaces pendant le fonctionnement de la pile: la forte concurrence pour le temps CPU entre JVM Elasticsearch et Logstash a conduit à des effets spéciaux pas très agréables lors des rafales de charge. Les éboueurs ont le plus souffert.

Source

Nous stockons les données des 30 derniers jours dans le cluster: il s'agit maintenant d'environ 12 milliards d'événements. Chaque jour, les nœuds actifs écrivent sur le disque 400-500 Go de nouvelles données avec un taux de compression maximal (y compris les données de réplique de partition). Notre cluster Elasticsearch a une architecture chaude / chaude, mais nous y sommes passés relativement récemment, donc moins de données sont encore stockées sur des nœuds «chauds» que sur des nœuds «chauds».

Notre charge de travail typique:

• indexation - en moyenne 13 000 rps avec des pics allant jusqu'à 30 000 (hors indexation en fragments de réplique);
• Recherche - 5200 rps.

Nous essayons de maintenir une marge CPU de 40 à 50% sur les nœuds chauds Elasticsearch afin que nous puissions facilement rencontrer des pics soudains dans le nombre d'événements indexés et les demandes lourdes de Kibana / Grafana ou des systèmes de surveillance externes. Environ 50% de la RAM sur les hôtes avec des nœuds Elasticsearch est toujours disponible pour les besoins de cache de page et hors segment de la JVM.

Pendant le temps écoulé depuis le lancement du premier cluster, nous avons réussi à identifier pour nous-mêmes certains des aspects positifs et négatifs d'Elastic Stack comme moyen d'agrégation de journaux et d'une plateforme de recherche et d'analyse.

Ce que nous aimons particulièrement dans la pile:

• Un écosystème unique de produits bien intégrés les uns aux autres, qui a presque tout ce dont vous avez besoin. Les Beats n'étaient autrefois pas très bons, mais maintenant nous n'avons rien à redire à leur sujet.
• Logstash, avec toute sa monstruosité, est un préprocesseur très flexible et puissant et vous permet de faire beaucoup avec des données brutes (et si quelque chose ne le permet pas, vous pouvez toujours écrire un extrait dans Ruby).
• Elasticsearch avec des plugins (et plus récemment prêt à l'emploi) prend en charge SQL en tant que langage de requête, ce qui simplifie son intégration avec d'autres logiciels et des personnes plus proches de SQL en tant que langage de requête.
• Une documentation de haute qualité qui vous permet d'initier rapidement de nouveaux employés au projet. Le fonctionnement de la pile ne devient donc pas l'affaire d'une seule personne ayant une expérience spécifique et des «connaissances secrètes».
• Il n'est pas nécessaire de connaître à l'avance la structure des données reçues pour commencer à les collecter: vous pouvez commencer à agréger les événements tels qu'ils sont, puis, lorsque vous comprenez quelles informations utiles vous pouvez en extraire, changez l'approche de leur traitement sans perdre la «compatibilité descendante». Il existe de nombreux outils pratiques sur la pile pour cela: alias de champ dans les index, champs scriptés, etc.

Source

Ce que nous n'aimons pas:

• Les composants X-Pack sont distribués uniquement en fonction du modèle d'abonnement et rien d'autre: si de Gold, par exemple, ne prend en charge que les rapports RBAC ou PDF, vous devrez payer pour tout ce que Gold a. Cela est particulièrement frustrant lorsque, par exemple, vous n'avez besoin que de Graph from Platinum, et de Machine Learning et d'un autre ensemble d'autres fonctionnalités dont vous n'avez peut-être pas vraiment besoin sont disponibles à l'achat. Nos tentatives de communiquer avec le service commercial d'Elastic au sujet de l'octroi de licences pour des composants X-Pack individuels il y a environ un an n'ont abouti à rien, mais peut-être que quelque chose a changé depuis.
• Des versions assez fréquentes dans lesquelles, d'une manière ou d'une autre (à chaque fois nouvelle), la compatibilité descendante est rompue. Vous devez lire le journal des modifications très attentivement et préparer les mises à jour à l'avance. Chaque fois que vous devez choisir: restez sur l'ancienne version, qui fonctionne de manière stable, ou essayez de mettre à niveau pour de nouvelles fonctionnalités et des gains de performances.

En général, nous sommes très satisfaits de notre choix fait en 2016, et nous prévoyons de transférer l'expérience de l'exploitation d'Elastic Stack à nos autres projets: les outils fournis par la pile sont très étroitement intégrés dans notre workflow et il serait très difficile de les refuser maintenant.