alex_aldo - Fotolia

Monitoring : Grafana Loki réduit les coûts, mais ne fait pas tout

Disponible depuis juin 2019, Grafana Loki ne remplacera pas les outils avancés d’analyse de logs, mais il pourrait être une aubaine pour les équipes désirant collecter des quantités massives de données pour dépanner les applications.

Les données issues de logs ne cessent d’augmenter avec la prolifération d’applications basées sur des microservices complexes et des systèmes distribués. Sans doute possible, il faut adopter de nouvelles approches pour gérer ce volume croissant. 

En juin 2019, la communauté derrière Grafana, un logiciel open source de monitoring a lancé officiellement le projet Loki.

Présenté à la Kubecon de Seattle en décembre 2018, il s’agit d’un système d’agrégation de logs multitenant inspiré par Prometheus.

Les premiers utilisateurs de l'outil de gestion des données de logs Grafana Loki ont déclaré qu'il les avait aidés à gérer plus efficacement les logs en même temps que les métriques Prometheus, notamment pour le dépannage des applications de microservices basées sur Kubernetes.

Grafana Loki ne convient peut-être pas à tous les usages – ses créateurs issus de la communauté open source ont déclaré qu’il n’était pas destiné à remplacer des outils comme Splunk ou Elasticsearch pour les cas d’usage BI, par exemple. Cependant, il peut avoir des avantages majeurs dans la capacité d’ingérer rapidement de grandes quantités de données et de les stocker à moindre coût.

« Nous ingérons environ 2000 logs par minute, par service, et nous centralisons les logs d’environ 25 services », déclare Piyush Baderia, ingénieur DevOps chez Paytm Insider, un service de billetterie événementielle basé à Mumbai. « [Avec Grafana Loki] nous avons déjà économisé environ 75 % [sur les coûts de stockage], et nous cherchons à le maximiser à environ 90 % si possible - nous pensons que c'est réalisable ».

Au lieu d'indexer chaque log complet et de stocker ces données dans une base de données structurée pour des requêtes ultérieures, comme le font les plateformes d'analyse de logs, Loki stocke une série d'étiquettes qui sont associées à des métadonnées dans un magasin clé-valeur, ou une base de données NoSQL, comme AWS DynamoDB.

Paytm Insider a rencontré des problèmes de performance quand il utilisait la version open source d’Elasticsearch pour collecter les logs. Les volumes trop importants ont submergé les shards de la base de données front-end de l’outil. L’équipe IT de Paytm Insider a eu du mal à adapter Elasticsearch à cette charge. Certains logs se perdaient pendant la collecte. Comme Grafana Loki n’indexe que les métadonnées, Paytm Insider a pu éviter ce goulet d’étranglement.

Les données complètes des journaux restent disponibles pour un accès ultérieur, mais comme il n’est pas nécessaire de les garder à disposition pour l’indexation, Paytm Insider utilise un système multi-tiers pour les stocker avec Grafana Loki. L’entreprise les place d’abord dans des pods Kubernetes Statefulsets, puis les migre vers un bucket S3 et enfin vers Amazon Glacier.

« Les index [de métadonnées] de Grafana Loki sont stockés dans DynamoDB [...] et nous avons un système multi-tier pour stocker les logs », explique Aayush Anand, également ingénieur DevOps chez Paytm Insider. « Cela simplifie le processus [de collecte des logs] et nous a également aidé à réduire le coût de stockage des logs ».

Grafana Loki fonctionne mieux s’il est associé avec Prometheus

Paytm Insider était bien placé pour devenir l'un des premiers à adopter Grafana Loki, car il utilisait déjà Prometheus pour les métriques de suivi de Kubernetes, ce qui est important pour un dépannage efficace avec cet outil.

Comme Grafana Loki n’indexe que les métadonnées, lorsque les utilisateurs veulent consulter les données de logs, ils doivent d’abord se servir des mesures provenant de Prometheus pour affiner la période pendant laquelle un problème applicatif a eu lieu. Ensuite, les DevOps doivent vérifier les logs Loki associés à cette période pour obtenir davantage d’informations.
L’interface Grafana Explorer permet d’accomplir ces deux étapes. Auparavant, les ingénieurs de Paytm Insider devaient utiliser deux plateformes différentes pour corréler les métriques et les logs.

Paytm Insider était également prêt à faire face aux problèmes de jeunesse de Grafana Loki : le produit a atteint la version 1.0 à la fin du mois de novembre 2019.

Cette version ne prenait pas en charge les requêtes parallélisées, une fonctionnalité qui a été ajoutée dans la version 1.3, sortie le 5 février, que les ingénieurs de Paytm Insider veulent tester avec impatience. Elle doit accélérer les requêtes et permettre leur exécution sur de plus grands volumes de données.

« Maintenant, même si vous effectuez une requête pour 70 logs de sept jours, la fonctionnalité divisera la requête en période de quatre heures et lancera ces sous-requêtes en parallèle avec DynamoDB », assure Aayush Anand.

La version remaniée du Query Frontend, publiée dans la version 1.3, offrira également une meilleure protection contre les attaques DDoS potentielles en organisant les requêtes en files d'attente limitées par locataire, selon un blog de Grafana Labs. Aayush Anand a également déclaré qu'il attendait avec impatience une fonctionnalité toujours présente sur la feuille de route de Grafana Loki qui devrait améliorer les performances des requêtes en conservant les résultats des requêtes les plus récentes dans la mémoire cache.

Grafana Loki optimise la collecte des données de logs dans un contexte particulier, mais les éditeurs de solution d'analyse de logs adoptent également de nouvelles approches pour rationaliser le coût du stockage et de la récupération des données. Sumo Logic et Splunk ont également introduit une tarification échelonnée pour le stockage des logs ainsi que des forfaits en fonction du nombre de requêtes effectuées. De son côté, Elastic ne facture pas séparément l'indexation des opérations informatiques et des informations de sécurité derrière son produit SIEM.

Pour approfondir sur DevOps et Agilité

Close