Observabilité : dépoussiérer Prometheus avec VictoriaMetrics

Prometheus s'est imposé comme un standard de facto dans nos infrastructures lorsque l'on souhaite faire de l'observabilité en collectant des métriques. Dans un contexte où l'on a besoin de se mettre rapidement à l'échelle (scalable), Prometheus commence à montrer ses faiblesses.

Prometheus ne possède pas de système de haute disponibilité de manière native, il faut obligatoirement passer par des solutions plus ou moins complexes comme Thanos ou Cortex. Ces solutions s'ajoutent à la lourdeur originelle de Prometheus.

VictoriaMetrics vient corriger tout cela en offrant une architecture micro-services où tout est découpé pour de meilleures performances et une meilleure disponibilité sans perte de données.
Ainsi je ferais un bref historique de l'observabilité, des solutions existantes, et du pourquoi complet de VictoriaMetrics, car il y en a beaucoup à dire sur cet outil prometteur !

Je vous ferais également un retour d'expérience sur l'utilisation de VictoriaMetrics Cluster aux Restos du Cœur et comment nous avons pu ainsi réduire les coûts en consommant plus de métriques qu'auparavant.

Transcript

1. Observabilité : dépoussiérer Prometheus avec @ju_hnny5
2. ~#whoami Julien Briault 😎 (ex) SecOps consultant chez Network Engineer / SRE chez IT/Infrastructure Manager (bénévole) aux Auteur sur blog.jbriault.fr et Linux Pratique #Networking #FOSS #Dev #Music @ju_hnny5
3. @ju_hnny5 Le cloud du Coeur
4. @ju_hnny5
5. Petit historique du monitoring à l’observabilité 😇 @ju_hnny5
6. La préhistoire 󰷺 @ju_hnny5
7. Nagios (netsaint) “la supervision” 🥸 Nagios, créé en 1999, était l'un des outils de surveillance les plus populaires au début des années 2000. 🫠 @ju_hnny5
8. Nagios (netsaint) “la supervision” 🥸 • Donné “naissance” à un grand nombre de solutions : ◦ Centreon ◦ Zabbix* ◦ Icinga ◦ Shinken • Une grande variété de “Nagios plugins” (exemple : check_nrpe) ◦ Majoritairement des scripts (Perl, Bash, Python) ◦ Utilise principalement le protocole SNMP @ju_hnny5
9. @ju_hnny5 0 = OK
10. @ju_hnny5 1 = Warning
11. @ju_hnny5 2 = Critical
12. @ju_hnny5 3 = Unknown
13. Les indicateurs (metrics) 🙄 @ju_hnny5
14. [me-trik] : “La science de la mesure” @ju_hnny5
15. Des indicateurs exploitables vs indicateurs de vanité* @ju_hnny5
16. Volume Vélocité Variété @ju_hnny5
17. Comment les stocker ? @ju_hnny5
18. Les TSDBs (Time Series Database) “c’est un type de base de données qui stock des valeurs qui évoluent dans le temps”. 🤓 @ju_hnny5
19. Les TSDBs (Time Series Databases) Plusieurs objectifs : • Observer • Alerter • Corréler Le standard : Open Metrics : • Fournit une specification : https://github.com/OpenObservability/OpenMetrics/blob/main/sp ecification/OpenMetrics.md ◦ Format : metric{label=valeur_label} ◦ Exemple : pdns_auth_uptime{instance="$host",dc="$dc"}
20. La structure des indicateurs (metrics) 🤨 requests_total{path=”/”, code:”200”} 10 1674518400 requests_total{path=”/”, code:”403”} 1 1674518410 Le nom Meta info Valeur Timestamp @ju_hnny5
21. Des solutions ? 🤫 @ju_hnny5
22. @ju_hnny5
23. Standard de facto : Prometheus 😏 • Création en 2012 par SoundCloud • Rendu Open Source en 2015 sous licence Apache 2. • Intégré à la CNCF en 2016 Fournit plusieurs outils : - alertmanager pour gérer les alertes - prometheus server (intégrant une Web UI) - pushgateway Source : https://developers.soundcloud.com/blog/prometheus-has-come-of-age-a-reflection-on-the-development-of-an-open-source-project
24. Standard de facto : Prometheus 😏 Source : https://prometheus.io/docs/introduction/overview/ @ju_hnny5
25. Standard de facto : Prometheus 😏 - Agrège ses métriques sur les 15 derniers jours dans sa TSDB (par défaut) - Configurable sur une plus longue durée mais ça peut rapidement être un problème : - Coûts du stockage - Ressources utilisées (RAM, CPU) - En cas de dysfonctionnement : - Perte des données s’il n’y a pas de backup. 😤 @ju_hnny5
26. Mais pas sans défauts … - Stockage local - Évolutivité verticale* - Possibilité de manière horizontale depuis la v2 = le stockage $$$ - Rétention de données - Haute disponibilité = 󰷻 - Gestion des alertes - Mono-tenant
27. Mais pas sans défauts … 😅 @ju_hnny5
28. @ju_hnny5
29. Un peu de glue : Thanos 🧐 - Infrastructure bien plus complexe* - Une utilisation des ressources bien plus conséquente - Même s’il est possible de partager la charge grâce au sharding. - Difficile à opérer 🤫 @ju_hnny5
30. Un peu de glue : Thanos 🧐 @ju_hnny5
31. @ju_hnny5
32. Un peu de glue : Cortex 🧐 @ju_hnny5
33. @ju_hnny5
35. VictoriaMetrics : Un vent de modernité • Solution jeune (2018) • Solution Open Source (Apache 2.0) d’observabilité et une TSDB. • Support officiellement pleins de protocoles pour l’ingestion de données (push/pull) : ◦ Prometheus (exporters) & Prometheus ◦ InfluxDB ◦ Graphite ◦ DataDog Agent ◦ OpenTSDB ◦ CSV, JSON ◦ OpenTelemetry = schemaless @ju_hnny5
36. • Fortement inspiré de l’éco-système Prometheus 🤓 • Ecrit en Go(lang) • Découverte et scrape les cibles Prometheus (et Kubernetes naturellement) 😱 • Facile à opérer et à mettre en place. VictoriaMetrics : Un vent de modernité @ju_hnny5
37. • Consomme beaucoup moins de ressources • Des performances bien meilleures qu’avec le combo Thanos/Prometheus :😏 ◦ Utilise l’algo de compression Snappy (comme Google BigTable) vs Prometheus utilise LZF (à titre de comparaison) ◦ Utilise du block storage VictoriaMetrics : Un vent de modernité @ju_hnny5
38. • Permet de faire du stockage (à froid) longue durée mais également de la collecte ◦ Rétention minimum de 24h ◦ 1 mois par défaut • Possède son propre agent (vmagent) pour ingérer les données vers VM 😱 VictoriaMetrics : Un vent de modernité 🫨 @ju_hnny5
39. Deux versions Community 🤭 Enterprise 🤫
40. • A l’inverse de Prometheus qui ne fonctionne par défaut qu’en mode Pull ◦ Utilisation de la pushgateway pour le mode Push • VictoriaMetrics supporte nativement les modes Pull & Push VictoriaMetrics : Un vent de modernité 🫨
41. • 10x moins de RAM qu’InfluxDB • Jusqu’à 7x moins de RAM que Prom/Thanos|Cortex • Peut recevoir jusqu’à 70 fois plus de données que TimescaleDB • Consomme environ 7x moins d’espace de Stockage que Prometheus/Thanos|Cortex Benchmark réalisé grâce à l’outil de TimescaleDB. VictoriaMetrics : Quelques chiffres Source : https://valyala.medium.com/measuring-vertical-scalability-for-time-seri es-databases-in-google-cloud-92550d78d8ae https://github.com/VictoriaMetrics/VictoriaMetrics#prominent-features
42. Quelques (gros) utilisateurs @ju_hnny5
43. Single-node = Scales vertically 🫣 @ju_hnny5
44. Cluster = Scales horizontally 🤗 @ju_hnny5
45. Ces deux modes partagent le même code. 🤩 @ju_hnny5
46. VictoriaMetrics : Une architecture simple 😇 victoria-metrics vmstorage vminsert vmselect Un seul noeud Version cluster @ju_hnny5 vmagent vmui
47. VictoriaMetrics : Une architecture simple 😇 @ju_hnny5
48. Multi-tenancy ? 🙄 @ju_hnny5
49. • Tenants identifiés par accountID ou accountID:projectID 😲 • Lister les tenants enregistrés via : ◦ http://<vmselect>:8481/admin/tenants • vminsert peut accepter des données provenants de plusieurs tenants via le point d’entrée multitenant : ◦ http://vminsert:8480/insert/multitenant/<suffix> Ne prend pas en charge l’interrogation de plusieurs tenants dans une seule requête. VictoriaMetrics : Namespaces 😎 @ju_hnny5
50. • Se veut une amélioration de PromQL en étant fortement inspiré (et est compatible) • Peut être utilisé de manière autonome (via le package metricsql) pour analyser des requêtes MetricsQL dans des applications externes (pour débogage par exemple) VictoriaMetrics : MetricsQL 😨 https://valyala.medium.com/promql-tutorial-for-beginners-9ab455142085 @ju_hnny5
51. Collect metrics ? 🤩 @ju_hnny5
52. VictoriaMetrics : Ingestion de données 🤩 Source : https://shorturl.at/nxNX2 https://github.com/VictoriaMetrics/VictoriaMetrics/tree/master/app/vminsert @ju_hnny5
53. VictoriaMetrics : Collecter des données 🥸 Source : https://shorturl.at/nxNX2 https://github.com/VictoriaMetrics/VictoriaMetrics/tree/master/app/vmagent Agent pour collecter les métriques à partir de diverses sources. Push Pull @ju_hnny5
54. VictoriaMetrics : Utilisation de l’agent 🥸 • Ingère des données via les protocoles populaires de “push” ◦ Exemple : remoteWrite de Prometheus • Compatible avec Prometheus* : ◦ Les configs de “scrape” Prometheus ◦ Le module de découverte de services (service discovery) ◦ Le système de “filtering” et “relabeling” • Clustering @ju_hnny5
55. VictoriaMetrics : Lecture des données 😲 Source : https://shorturl.at/nxNX2 https://github.com/VictoriaMetrics/VictoriaMetrics/tree/master/app/vmselect Pull Pull @ju_hnny5
56. VictoriaMetrics : Se faire alerter ! 🫨 Source : https://shorturl.at/nxNX2 https://github.com/VictoriaMetrics/VictoriaMetrics/tree/master/app/vmalert Pull Push @ju_hnny5
57. Migrer les données 🫨 @ju_hnny5
58. VictoriaMetrics : Migrer ses données Source : https://docs.victoriametrics.com/vmctl.html Une commande : vmctl. Permet de migrer les données de : - Prometheus via l’API de snapshot - Thanos, Cortex, Mimir - InfluxDB - OpenTSDB - Promscale - Entre noeuds VictoriaMetrics (single ou cluster)
59. Un peu de contrôle 🫡 @ju_hnny5
60. VictoriaMetrics : Ajouter de l’authentification 🫡 Source : https://shorturl.at/nxNX2 https://github.com/VictoriaMetrics/VictoriaMetrics/tree/master/app/vmauth • Authentification basique au travers d’HTTP(S). • Le client envoie une requête à vmauth en spécifiant le mot de passe, si vmauth authetifie correctement cette requête, alors la requête est envoyée à VictoriaMetrics (vminsert). 😯 Push @ju_hnny5
61. VictoriaMetrics : Une Web UI (vmui) 🤗 https://github.com/VictoriaMetrics/VictoriaMetrics/tree/master/app/vmui @ju_hnny5
62. Intégration : Grafana 🫣 @ju_hnny5
63. Intégration : Grafana 🫣 https://github.com/VictoriaMetrics/grafana-datasource @ju_hnny5
64. vmgateway, vmbackupmanager et vmanomaly @ju_hnny5
65. VictoriaMetrics : Détection des anomalies 😍 • vmanomaly : Un service qui analyse en permanence les données dans VictoriaMetrics et utilise des mécanismes d'apprentissage automatique pour détecter les changements inattendus qui peuvent être utilisés dans les alertes. @ju_hnny5
66. VictoriaMetrics : DownSampling • Feature disponible dans la version Entreprise (depuis 2021) @ju_hnny5
67. VictoriaMetrics : Intégration dans Kubernetes (vmoperator) Mode cluster dans Kubernetes (via Helm charts pour installer l’operateur). Simple d’accès : helm install vmoperator vm/victoria-metrics-operator kubectl --namespace default get pods -l "app.kubernetes.io/instance=vmoperator" https://docs.victoriametrics.com/operator/quick-start/
68. Un cas pratique @ju_hnny5
69. 2 clusters déployés dans 2 envs Kubernetes différents. VictoriaMetrics aux @ju_hnny5
70. Pour quel(s) usage(s) ? @ju_hnny5
71. Pour l’infrastructure @ju_hnny5
72. Pour l’infrastructure @ju_hnny5 • Tourne dans un cluster Kubernetes on-prem dédié ◦ Cluster hyper-convergé (kube + ceph SSD) ◦ At-scale (bare-metal via MaaS) • Utilise Ceph RBD pour stocker les valeurs • Utilisation du mode multi-tenancy • Utilisation du vmoperator
73. Besoin métier : Chambres froides/négatives @ju_hnny5
74. Pour le besoin métier 🧐 @ju_hnny5 • Tourne dans un cluster Kubernetes déployé sur OpenStack (cloud privé) ◦ Mise à l’échelle automatique en fonction de l’évolution du besoin (via Horizontal Pod Autoscaler) ◦ Cluster dédié à ce besoin • Permettre de fournir : ◦ Alerte en cas de dysfonctionnement de la sonde ◦ Alerte en cas de seuil de température dépassé ◦ Historique sur 1 an de l’évolution de la température et des alertes (besoin légal)
75. Pour le besoin métier @ju_hnny5 • V1 = Raspberry PI + dht11 + Prometheus Exporter (Golang)
76. @ju_hnny5
77. Pour le besoin métier @ju_hnny5 • V2 = ESP8266 (Wi-Fi version) + ds18b20 + Prometheus Exporter + batterie +
78. Pour le besoin métier @ju_hnny5 x3
79. Pour le besoin métier @ju_hnny5 On supervise également la température des salles serveurs* 😜
80. Pourquoi avoir choisi VictoriaMetrics ? @ju_hnny5
81. @ju_hnny5 Toujours plus de metrics, pour moins de consommation 😶
82. Pourquoi avoir choisi VictoriaMetrics ? @ju_hnny5 • Réduction des coûts (vs Prometheus utilisé historiquement) : ◦ Coût CPU, RAM, disque + de migration (grâce à vmctl) 🤩 ▪ Divisé par 4 (par rapport à Prometheus / Thanos) • Stockage à froid • Pas de changement à prévoir sur nos dashboards historiques (utilisant PromQL). 🧐 • Le split des différents éléments (vm), simplifiant grandement leur mise à l’échelle. 🤯
83. ➡ https://play.victoriametrics.com @ju_hnny5
84. Instant pub ! 😇
85. @ju_hnny5
86. Merci
87. Un feedback ? @ju_hnny5
88. 🫶 Merci pour votre attention ! 🫶