Stack de monitoring performante sous Grafana - De Prometheus/Loki/Mimir à Vector/VictoriaMetrics¶
Quand on souhaite monter une stack de monitoring, on pense bien entendu à Grafana pour la réalisation de ses dashboard.
Pour remonter toute nos infos à celui-ci, on pense Prometheus pour les métriques, Loki pour les logs, et Mimir pour le stockage long terme des métriques.
Mais n'existe t-il pas de nouveaux framework moins gourmant en ressource que cette traditionnel stack ? 🤔
Comparaison entre les divers stack¶
Avant que j'aille plus loins dans l'explication de ma stack que je propose et qui me semble plus optimisé en terme de consomation de ressource, commençons par voir le basique, à savoir ce qui se fait de nos jours qui est commun. Je te montre ensuite ce qui me semble mieux, que j'ai mis en place et surtout en quoi elle est mieux 
Stack mainstream schema¶
On peut retrouver chez pas mal d'entreprise, une stack assez commune pour la gestion des logs et métriques. C'est facile à mettre en place, commun en terme d'utilisation et de technos, de documentation et de communauté.
- Kubernetes, ici je parle de métriques internes à k8s qui sont exposés, ou de tes divers services qui tournent et qui crash des logs
- Grafana loki, la base qui stocke tes logs. Ils sont collectés dans ton cluster par un agent (Promtail historiquement, remplacé aujourd'hui par Grafana Alloy)
- Prometheus, responsable de récuperer les métriues exposées dans ton cluster
- Grafana mimir, est la database pour stocker tes métriques sur du long terme (Mimir ne stocke que des métriques, les logs restent dans Loki)
- Grafana, afin de créer tes dashboard. Ceux-ci iront lire les métriques dans Mimir et les logs dans Loki dans notre cas
Stack plus récente & optimisé schema¶
- Kubernetes, ici je parle de métriques internes à k8s qui sont exposés, ou de tes divers services qui tournent et qui crash des logs
- Kube state metrics, permettant d'exposer d'avantage de metriques. Ce framework reste optionnel
- Vector, permet d'aller scrapper les métriques et logs que tu souhaites, de les reformater (j'y reviendrais plus bas)
- VictoriaMetrics, qui permet le stockage de long terme des métriques
- VictoriaLogs, son équivalent pour les logs, que Vector alimente aussi
- Grafana, afin de créer tes dashboard. Ceux-ci iront lire les données dans VictoriaMetrics et VictoriaLogs dans notre cas
Avantage & inconvénients de chaque stack¶
Au fil du temps, on va créer de plus en plus de dashboard, et donc se baser sur d'avantages de métriques, et/ou de logs applicatifs. On continue ainsi à allourdir la stack avec le développement croissant de nos services. Un des soucis majeur, une fois votre stack qui fonctionne en production, va être la consommation en ressource de notre stockage de logs. On tombe nez à nez fasse à deux soucis :
- Le stockage coute plus cher chez votre cloud provider
- Le requêtage des datas dans notre base de données, depuis nos dashboard, deviennent de plus en plus longs à s'afficher
C'est un soucis que l'on rencontre avec notre première stack. On peut évidemment diminuer notre nombre de métriques scrappé, ainsi que les logs, ou encore la fréquence de scrapping ou encore diminuer la rétention des données dans notre base. Mais moins de données équivaut à diminuer les fonctionnalités de notre monitoring.
C'est ici que resort 2 nouveaux framework, Vector et VictoriaMetrics, qui se veulent plus léger et moins gourmand en ressource.
Vector¶
Vector est extremement bien fourni :
- Nombre incroyable d'inputs de datas (source)
- Nombre incroyable d'outputs de datas (sinks)
- Langage dédié (VRL, Vector Remap Language, open source comme le reste de Vector), permettant très facilement de modifier nos données
- construction complexe de pipeline
- écrit en rust et donc très performant
- free & open source
En terme de performances, ça outpass la concurrence de façon général ou ça reste dans le top 
VictoriaMetrics¶
VictoriaMetrics peut être un remplacement direct de Prometheus car :
- free & open source
- écrit en go et donc très performant.
- peut remplacer Prometheus car utilise du MetricsQL, construit sur du PromQL le language de query de Prometheus avec de nouvelles fontionnalités
- se plug donc directement à Vector avec le même sink que Prometheus
- se plug directement à Grafana pour les dashboard à la place de Grafana Mimir : la datasource Prometheus native de Grafana suffit (un plugin VictoriaMetrics existe si tu veux profiter de MetricsQL)
Si on parle de performances pures, les benchmarks de l'éditeur (2019-2020, à reprendre avec du recul vu les évolutions des autres outils depuis) annoncent :
- 10X moins gourmant en RAM que InfluxDB, et jusqu'a 7X moins gourmant en RAM que Prometheus/Cortex/Thanos
- En terme de data ingestion et query, 20X meilleur que InfluxDB/TimescaleDB
- Meilleurs algos de compression et use 7X moins de disque storage que Prometheus/Cortex/Thanos
Conclusion¶
Stack facilement implémentable, celle-ci peut donc servir de remplacement build-in par la précédente car :
- Vector peut scrapper les endpoints façon Prometheus
- VictoriaMetrics peut scrapper les pods annoté/labélisé façon Prometheus via ses VMAgent défini par ses VMServiceScrape
Pour aller plus loin¶
Je détaille la mise en place de chaque brique dans ces tutos :
- Logs collector & aggregator avec Vector
- Exposer des métriques avec Kube-state-metrics
- VictoriaMetrics & intégration dans Grafana
- VictoriaLogs & intégration dans Grafana
- Grafana Mimir et Grafana Loki pour la stack Grafana