Serveur d'impression

3 outils d'agrégation de journaux open source – Bien choisir son serveur d impression

Le 11 décembre 2019 - 11 minutes de lecture

En quoi l'agrégation de métriques est-elle différente de l'agrégation de journaux? Les journaux ne peuvent-ils pas inclure de statistiques? Les systèmes d'agrégation de journaux ne peuvent-ils pas faire les mêmes choses que les systèmes d'agrégation de métriques?

Ce sont des questions que j'entends souvent. J'ai également vu des fournisseurs présenter leur système d'agrégation de journaux comme la solution à tous les problèmes d'observabilité. L'agrégation de journaux est un outil précieux, mais ce n'est normalement pas un bon outil pour les données de séries chronologiques.

L'intervalle régulier et le système de stockage personnalisés spécifiquement pour les données de série temporelle sont quelques fonctionnalités précieuses d'un système d'agrégation de métriques de séries chronologiques. L'intervalle régulier permet à un utilisateur de dériver des résultats mathématiques réels de manière cohérente. Si un système d'agrégation de journaux collecte des métriques à intervalles réguliers, il peut potentiellement fonctionner de la même manière. Cependant, le système de stockage n'est pas optimisé pour les types de requêtes typiques d'un système d'agrégation de métriques. Ces requêtes prendront plus de ressources et de temps à traiter à l'aide des systèmes de stockage trouvés dans les outils d'agrégation de journaux.

Nous savons donc qu'un système d'agrégation de journaux n'est probablement pas adapté aux données de séries chronologiques, mais à quoi sert-il? Un système d'agrégation de journaux est un excellent endroit pour collecter des données d'événements. Ce sont des activités irrégulières qui sont importantes. Un exemple pourrait être les journaux d'accès pour un service Web. Celles-ci sont importantes car nous voulons savoir ce qui accède à nos systèmes et quand. Un autre exemple serait une condition d'erreur d'application – car il ne s'agit pas d'une condition de fonctionnement normale, elle peut être utile lors du dépannage.

Une poignée de règles de journalisation:

  • Incluez un horodatage
  • Format DO en JSON
  • NE PAS enregistrer les événements insignifiants
  • NE PAS enregistrer toutes les erreurs d'application
  • MAYBE log warnings
  • Activez la journalisation
  • ÉCRIVEZ les messages sous une forme lisible par l'homme
  • NE PAS enregistrer de données informatives en production
  • NE PAS enregistrer quoi que ce soit qu’un être humain ne peut pas lire ni réagir

Coûts du cloud

Lorsque vous étudiez les outils d'agrégation de journaux, le cloud peut sembler une option intéressante. Cependant, cela peut entraîner des coûts importants. Les journaux représentent une grande quantité de données lorsqu'ils sont agrégés sur des centaines ou des milliers d'hôtes et d'applications. L'ingestion, le stockage et la récupération de ces données sont coûteux dans les systèmes basés sur le cloud.

Comme point de référence d'un système réel, une collection d'environ 500 nœuds avec quelques centaines d'applications génère 200 Go de données de journal par jour. Il est probablement possible d'améliorer ce système, mais même le réduire de moitié coûtera près de 10 000 $ par mois dans de nombreuses offres SaaS. Cela inclut souvent une conservation de seulement 30 jours, ce qui n'est pas très long si vous souhaitez consulter les données sur les tendances d'une année à l'autre.

Cela ne doit pas décourager l'utilisation de ces systèmes, car ils peuvent être très utiles, en particulier pour les petites organisations. Le but est de souligner qu'il pourrait y avoir des coûts importants, et cela peut être décourageant lorsqu'ils sont réalisés. Le reste de cet article se concentrera sur les solutions open source et commerciales qui sont auto-hébergées.

Options d'outils

WAPITI

ELK, abréviation de Elasticsearch, Logstash et Kibana, est l'outil d'agrégation de journaux open source le plus populaire sur le marché. Il est utilisé par Netflix, Facebook, Microsoft, LinkedIn et Cisco. Les trois composants sont tous développés et maintenus par Elastic. Elasticsearch est essentiellement une implémentation de moteur de recherche NoSQL et Lucene. Logstash est un système de pipeline de journaux qui peut ingérer des données, les transformer et les charger dans un magasin comme Elasticsearch. Kibana est une couche de visualisation au-dessus d'Elasticsearch.

Il y a quelques années, Beats a été lancé. Les battements sont des collecteurs de données. Ils simplifient le processus d'envoi des données à Logstash. Au lieu d'avoir besoin de comprendre la syntaxe appropriée de chaque type de journal, un utilisateur peut installer un Beat qui exportera correctement les journaux NGINX ou les journaux proxy Envoy afin qu'ils puissent être utilisés efficacement dans Elasticsearch.

Lors de l'installation d'une pile ELK au niveau de la production, quelques autres pièces peuvent être incluses, comme Kafka, Redis et NGINX. En outre, il est courant de remplacer Logstash par Fluentd, dont nous discuterons plus tard. Ce système peut être complexe à utiliser, ce qui, à ses débuts, a entraîné de nombreux problèmes et plaintes. Celles-ci ont été en grande partie corrigées, mais c'est toujours un système complexe, donc vous ne voudrez peut-être pas l'essayer si vous êtes une petite entreprise.

Cela dit, il existe des services, vous n'avez donc pas à vous en préoccuper. Logz.io l'exécutera pour vous, mais sa liste de prix est un peu abrupte si vous avez beaucoup de données. Bien sûr, vous êtes probablement plus petit et pouvez ne pas avoir beaucoup de données. Si vous ne pouvez pas vous permettre Logz.io, vous pouvez regarder quelque chose comme AWS Elasticsearch Service (ES). ES est un service proposé par Amazon Web Services (AWS) qui permet de faire fonctionner Elasticsearch très rapidement. Il dispose également d'outils pour obtenir tous les journaux AWS dans ES à l'aide de Lambda et S3. Il s'agit d'une option beaucoup moins chère, mais une certaine gestion est requise et il existe quelques limitations.

Elastic, la société mère de la pile, propose un produit plus robuste qui utilise le modèle de noyau ouvert, qui fournit des options supplémentaires concernant les outils d'analyse et les rapports. Il peut également être hébergé sur Google Cloud Platform ou AWS. Cela pourrait être la meilleure option, car cette combinaison d'outils et de plates-formes d'hébergement offre une solution moins chère que la plupart des options SaaS et offre toujours beaucoup de valeur. Ce système pourrait remplacer efficacement ou vous donner la capacité d'un système de gestion des informations et des événements de sécurité (SIEM).

La pile ELK offre également d'excellents outils de visualisation via Kibana, mais il manque une fonction d'alerte. Elastic fournit une fonctionnalité d'alerte dans le module complémentaire X-Pack payant, mais il n'y a rien de intégré pour le système open source. Yelp a créé une solution à ce problème, appelée ElastAlert, et il y en a probablement d'autres. Ce logiciel supplémentaire est assez robuste, mais il augmente la complexité d'un système déjà complexe.

Graylog

Graylog a récemment gagné en popularité, mais il a débuté lorsque Lennart Koopmann l'a créé en 2010. Une entreprise est née avec le même nom deux ans plus tard. Malgré son utilisation croissante, il est toujours loin derrière la pile ELK. Cela signifie également qu'il a moins de fonctionnalités développées par la communauté, mais il peut utiliser les mêmes battements que la pile ELK utilise. Graylog a gagné des éloges dans la communauté Go avec l'introduction du Sidecar Graylog Collector écrit en Go.

Graylog utilise Elasticsearch, MongoDB et le serveur Graylog sous le capot. Cela rend son exécution aussi complexe que la pile ELK et peut-être un peu plus. Cependant, Graylog est livré avec des alertes intégrées à la version open source, ainsi que plusieurs autres fonctionnalités notables telles que la diffusion en continu, la réécriture de messages et la géolocalisation.

La fonction de diffusion en continu permet d'acheminer les données vers des flux spécifiques en temps réel pendant leur traitement. Grâce à cette fonctionnalité, un utilisateur peut voir toutes les erreurs de base de données dans un seul flux et les erreurs de serveur Web dans un autre flux. Les alertes peuvent même être basées sur ces flux lorsque de nouveaux éléments sont ajoutés ou lorsqu'un seuil est dépassé. La latence est probablement l'un des plus gros problèmes avec les systèmes d'agrégation de journaux, et Streams élimine ce problème dans Graylog. Dès que le journal arrive, il peut être acheminé vers d'autres systèmes via un Stream sans être traité complètement.

La fonction de réécriture de messages utilise le moteur de règles open source Drools. Cela permet à tous les messages entrants d'être évalués par rapport à un fichier de règles défini par l'utilisateur permettant de supprimer un message (appelé liste noire), d'ajouter ou de supprimer un champ ou de modifier le message.

La fonctionnalité la plus intéressante pourrait être la capacité de géolocalisation de Graylog, qui prend en charge le traçage des adresses IP sur une carte. Il s'agit d'une fonctionnalité assez courante qui est également disponible dans Kibana, mais elle ajoute beaucoup de valeur, surtout si vous souhaitez l'utiliser comme système SIEM. La fonctionnalité de géolocalisation est fournie dans la version open source du système.

Graylog, la société, facture le support de la version open source si vous le souhaitez. Il propose également un modèle de noyau ouvert pour sa version Entreprise qui offre l'archivage, la journalisation d'audit et un support supplémentaire. Il n'y a pas beaucoup d'autres options de support ou d'hébergement, vous serez donc probablement seul si vous n'utilisez pas Graylog (la société).

Fluentd

Fluentd a été développé chez Treasure Data, et la CNCF l'a adopté comme projet d'incubation. Il a été écrit en C et Ruby et est recommandé par AWS et Google Cloud. Fluentd est devenu un remplacement courant de Logstash dans de nombreuses installations. Il agit comme un agrégateur local pour collecter tous les journaux des nœuds et les envoyer aux systèmes de stockage centraux. Ce n'est pas un système d'agrégation de journaux.

Il utilise un système de plug-in robuste pour fournir des intégrations rapides et faciles avec différentes sources de données et sorties de données. Puisqu'il y a plus de 500 plugins disponibles, la plupart de vos cas d'utilisation devraient être couverts. S'ils ne le sont pas, cela ressemble à une opportunité de contribuer à la communauté open source.

Fluentd est un choix courant dans les environnements Kubernetes en raison de ses faibles besoins en mémoire (quelques dizaines de mégaoctets) et de son débit élevé. Dans un environnement comme Kubernetes, où chaque pod a un side-car Fluentd, la consommation de mémoire augmentera de façon linéaire avec chaque nouveau pod créé. L'utilisation de Fluentd réduira considérablement l'utilisation de votre système. Cela devient un problème courant avec les outils développés en Java qui sont destinés à en exécuter un par nœud où la surcharge de mémoire n'a pas été un problème majeur.

Que lire ensuite

Commentaires

Laisser un commentaire

Votre commentaire sera révisé par les administrateurs si besoin.