En quoi l’agrégation de métriques est-elle différente de l’agrégation de logs ? Les logs ne peuvent-ils pas inclure des métriques ? Les systèmes d’agrégation de logs 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 vendeurs 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 temporelles.

Un couple de caractéristiques précieuses dans un système d’agrégation de métriques de séries temporelles est l’intervalle régulier et le système de stockage personnalisé spécifiquement pour les données de séries temporelles. L’intervalle régulier permet à un utilisateur de tirer des résultats mathématiques réels de manière cohérente. Si un système d’agrégation de logs collecte des métriques à intervalle régulier, 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 en utilisant les systèmes de stockage trouvés dans les outils d’agrégation de journaux.

Donc, nous savons qu’un système d’agrégation de journaux n’est probablement pas adapté aux données de séries temporelles, mais à quoi sert-il ? Un système d’agrégation de journaux est un endroit idéal pour collecter des données d’événements. Il s’agit d’activités irrégulières qui sont significatives. Par exemple, les journaux d’accès à un service Web. Ils sont importants car nous voulons savoir ce qui accède à nos systèmes et quand. Un autre exemple serait une condition d’erreur d’application – parce qu’il ne s’agit pas d’une condition de fonctionnement normale, elle pourrait être précieuse lors du dépannage.

Une poignée de règles pour la journalisation :

• DO inclure un horodatage
• DO format en JSON
• DON’T logger les événements insignifiants
• DO logger toutes les erreurs d’application
• MAYBE loger les avertissements
• DO activer la journalisation
• DO écrire les messages dans une forme humaine-.l’homme
• Ne pas enregistrer les données informationnelles en production
• Ne pas enregistrer tout ce qu’un humain ne peut pas lire ou réagir

Coûts du cloud

Lorsque vous étudiez les outils d’agrégation de journaux, le cloud peut sembler être une option attrayante. Cependant, elle peut s’accompagner de coûts importants. Les journaux représentent beaucoup 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.

Pour prendre un point de référence à partir d’un système réel, une collection d’environ 500 nœuds avec quelques centaines d’applications donne lieu à 200 Go de données de journal par jour. Il est probablement possible d’améliorer ce système, mais même en le réduisant de moitié, il en coûtera près de 10 000 $ par mois dans de nombreuses offres SaaS. Cela inclut souvent une rétention de seulement 30 jours, ce qui n’est pas très long si vous voulez examiner les données de tendance d’une année sur l’autre.

Il ne s’agit pas de décourager l’utilisation de ces systèmes, car ils peuvent être très précieux – en particulier pour les petites organisations. Le but est de souligner qu’il pourrait y avoir des coûts importants, et il peut être décourageant quand 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

ELK

ELK, abréviation d’Elasticsearch, Logstash et Kibana, est l’outil d’agrégation de logs open source le plus populaire du 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 NoSQL du moteur de recherche 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, les Beats ont été introduits. Les Beats sont des collecteurs de données. Ils simplifient le processus d’expédition des données vers Logstash. Au lieu de devoir comprendre la bonne syntaxe de chaque type de log, un utilisateur peut installer un Beat qui exportera correctement les logs NGINX ou les logs du proxy Envoy afin qu’ils puissent être utilisés efficacement dans Elasticsearch.

Lors de l’installation d’une pile ELK de niveau 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 parlerons plus tard. Ce système peut être complexe à utiliser, ce qui, à ses débuts, a donné lieu à de nombreux problèmes et plaintes. Ceux-ci ont été largement corrigés, mais c’est toujours un système complexe, donc vous ne voudrez peut-être pas l’essayer si vous êtes une petite opération.

Cela dit, il y a des services disponibles pour que vous n’ayez pas à vous soucier de cela. Logz.io le fera fonctionner pour vous, mais son prix de liste est un peu élevé si vous avez beaucoup de données. Bien sûr, vous êtes probablement plus petit et vous n’avez peut-être pas beaucoup de données. Si vous n’avez pas les moyens de vous offrir Logz.io, vous pouvez vous tourner vers AWS Elasticsearch Service (ES). ES est un service proposé par Amazon Web Services (AWS) qui permet de faire fonctionner Elasticsearch très facilement et rapidement. Il dispose également d’outils permettant de transférer tous les journaux AWS dans ES à l’aide de Lambda et de S3. C’est une option beaucoup moins chère, mais il y a une certaine gestion nécessaire et il y a quelques limitations.

Elastic, la société mère de la pile, offre un produit plus robuste qui utilise le modèle de noyau ouvert, qui fournit des options supplémentaires autour des outils d’analyse, et des rapports. Il peut également être hébergé sur Google Cloud Platform ou AWS. C’est peut-ê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, tout en offrant une grande valeur ajoutée. Ce système pourrait effectivement remplacer 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 grâce à Kibana, mais il lui manque une fonction d’alerte. Elastic fournit une fonctionnalité d’alerte au sein du module complémentaire payant X-Pack, mais il n’y a rien d’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 encore loin derrière la pile ELK. Cela signifie également qu’elle dispose de moins de fonctionnalités développées par la communauté, mais elle peut utiliser les mêmes Beats que la pile ELK. 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 Graylog Server sous le capot. Cela le rend aussi complexe à exécuter que la pile ELK et peut-être un peu plus. Cependant, Graylog est livré avec des alertes intégrées dans la version open source, ainsi que plusieurs autres fonctionnalités notables comme le streaming, la réécriture de messages et la géolocalisation.

La fonctionnalité de streaming permet d’acheminer les données vers des Streams spécifiques en temps réel pendant qu’elles sont traitées. Avec cette fonctionnalité, un utilisateur peut voir toutes les erreurs de base de données dans un seul Stream et les erreurs de serveur web dans un autre Stream. Des 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 des systèmes d’agrégation de journaux, et les flux éliminent ce problème dans Graylog. Dès que le journal arrive, il peut être acheminé vers d’autres systèmes par le biais d’un Stream sans être entièrement traité.

La fonction de réécriture des 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é Blacklisting), d’ajouter ou de supprimer un champ, ou de modifier le message.

La fonctionnalité la plus cool pourrait être la capacité de géolocalisation de Graylog, qui prend en charge le tracé des adresses IP sur une carte. Il s’agit d’une fonctionnalité assez courante, disponible également dans Kibana, mais elle ajoute beaucoup de valeur – surtout si vous voulez 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 sur la version open source si vous le souhaitez. Elle propose également un modèle de base ouvert pour sa version Enterprise qui offre l’archivage, la journalisation des audits et un support supplémentaire. Il n’y a pas beaucoup d’autres options pour le support ou l’hébergement, donc vous serez probablement tout seul si vous n’utilisez pas Graylog (la société).

Fluentd

Fluentd a été développé chez Treasure Data, et le CNCF l’a adopté comme projet incubateur. 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 de nœuds et les envoyer vers des systèmes de stockage centraux. Ce n’est pas un système d’agrégation de logs.

Il utilise un système de plugins robuste pour fournir des intégrations rapides et faciles avec différentes sources de données et sorties de données. Comme 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 en retour à la communauté open source.

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