RivieraDev 2024 - 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
4. @ju_hnny5 Le cloud du Coeur
5. @ju_hnny5
6. On a besoin de vous ! @ju_hnny5
7. @ju_hnny5 https://www.youtube.com/watch?v=pccSZLjKfVo Comment nous avons transformé les Restos du Coeur en Cloud Provider
8. Petit historique du monitoring à l’observabilité 😇 @ju_hnny5
9. La préhistoire 󰷺 @ju_hnny5
10. 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
11. Nagios (netsaint) “la supervision” 🥸 @ju_hnny5
12. Nagios (netsaint) “la supervision” 🥸 • Donné “naissance” à un grand nombre de solutions : ◦ Centreon ◦ Zabbix* ◦ Icinga ◦ Shinken (RIP) @ju_hnny5
13. Nagios (netsaint) “la supervision” 🥸 • Une grande variété de “Nagios plugins” (exemple : check_nrpe) ◦ Majoritairement des scripts (Perl, Bash, Python) ◦ Utilise principalement le protocole SNMP @ju_hnny5
14. @ju_hnny5 0 = OK
15. @ju_hnny5 1 = Warning
16. @ju_hnny5 2 = Critical
17. @ju_hnny5 3 = Unknown
18. Nagios (netsaint) “la supervision” 🥸 elsif ($return =~ /down/ && $state eq "up"){ print "$interface is down\n"; exit $CRITICAL; }elsif($return =~ /down/ && $state eq "down"){ print "$interface down : ok\n"; exit $OK; }elsif($return =~ /up/ && $state eq "down"){ print "$interface should not be up\n"; exit $CRITICAL; }elsif($return =~ /dormant/ && $state eq "down" || $return =~ /dormant/ && $state eq "up"){ print "Error : $interface is sleeping\n"; exit $CRITICAL; }elsif($return =~ /dormant/ && $state eq "dormant"){ print "$interface is sleeping : ok\n"; exit $OK }elsif($return =~ /up/ && $state eq "dormant"){ print "$interface is up and should be sleeping\n"; exit $CRITICAL; }else{ print "Unknown state for $interface : check your -s state syntax\n"; exit $UNKNOW; } @ju_hnny5 https://exchange.nagios.org/directory/Plugins/ Hardware/Network-Gear/Cisco/Cisco-Switche s-and-routers/details
19. Les indicateurs (metrics) 🙄 @ju_hnny5
20. [me-trik] : “La science de la mesure” @ju_hnny5
21. Des indicateurs exploitables vs indicateurs de vanité* @ju_hnny5
22. Volume Vélocité Variété @ju_hnny5
23. Comment les stocker ? @ju_hnny5
24. 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
25. 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"}
26. 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
27. L’observabilité, Ce n’est pas qu’une question de monitoring 🤫 @ju_hnny5
28. Comment ça ? @ju_hnny5 ◦ Les logs (la centralisation des logs) ▪ Elastic ▪ Quickwit ▪ Fluentbit / Vector, etc … ◦ Le tracing (OpenTelemetry - OTEL), ▪ Jaeger ▪ Quickwit
29. SRE Friendly ! @ju_hnny5
30. Les SRE, un peu de littérature … @ju_hnny5
31. Les SRE @ju_hnny5 https://www.youtube.com/watch?v=tm0UY0MC1po
32. Vouloir tout Monitorer / Observer ! 👀 @ju_hnny5
33. Alerting 😉 Critical / Warning / Notice / Page @ju_hnny5
34. Gestion des incidents 😅 @ju_hnny5
35. Gestion des incidents 😅 @ju_hnny5 ◦ Gérer les tickets d’incidents ◦ Avoir des notifications 🤘 ◦ L’astreinte : ▪ Interconnexion avec des outils comme Grafana OnCall, OpsGenie, PagerDuty ▪ Importance d’avoir des “Runbooks”
36. La performance 💪 @ju_hnny5
37. Des solutions ? 🤫 @ju_hnny5
38. Des solutions ?
39. Des solutions ?
40. Des solutions ? 😬
41. Des solutions ? 😬
42. @ju_hnny5
43. 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
44. Standard de facto : Prometheus 😏 Source : https://prometheus.io/docs/introduction/overview/ @ju_hnny5
45. 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
46. 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
47. Mais pas sans défauts … 😅 @ju_hnny5
48. @ju_hnny5
49. 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
50. Un peu de glue : Thanos 🧐 @ju_hnny5
51. @ju_hnny5
52. Un peu de glue : Cortex 🧐 @ju_hnny5
53. @ju_hnny5
55. 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
56. • 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
57. • 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
58. • 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
59. Deux versions Community 🤭 Enterprise 🤫
60. • 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é 🫨
61. • 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
62. Quelques (gros) utilisateurs @ju_hnny5
63. Single-node = Scales vertically 🫣 @ju_hnny5
64. Cluster = Scales horizontally 🤗 @ju_hnny5
65. Ces deux modes partagent le même code. 🤩 @ju_hnny5
66. VictoriaMetrics : Une architecture simple 😇 victoria-metrics vmstorage vminsert vmselect Un seul noeud Version cluster @ju_hnny5 vmagent vmui
67. VictoriaMetrics : Une architecture simple 😇 @ju_hnny5
68. Multi-tenancy ? 🙄 @ju_hnny5
69. • 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
70. • 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
71. Collect metrics ? 🤩 @ju_hnny5
72. VictoriaMetrics : Ingestion de données 🤩 Source : https://shorturl.at/nxNX2 https://github.com/VictoriaMetrics/VictoriaMetrics/tree/master/app/vminsert @ju_hnny5
73. VictoriaMetrics : Ingestion de données 🤩 @ju_hnny5
74. VictoriaMetrics : Ingestion de données 🤩 @ju_hnny5
75. VictoriaMetrics : Ingestion de données 🤩 @ju_hnny5
76. 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
77. 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
78. VictoriaMetrics : Lecture des données 😲 Source : https://shorturl.at/nxNX2 https://github.com/VictoriaMetrics/VictoriaMetrics/tree/master/app/vmselect Pull Pull @ju_hnny5
79. VictoriaMetrics : Se faire alerter ! 🫨 Source : https://shorturl.at/nxNX2 https://github.com/VictoriaMetrics/VictoriaMetrics/tree/master/app/vmalert Pull Push @ju_hnny5
80. VictoriaMetrics : Se faire alerter ! 🫨 @ju_hnny5
81. VictoriaMetrics : Se faire alerter ! 🫨 @ju_hnny5
82. Migrer les données 🫨 @ju_hnny5
83. 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)
84. Un peu de contrôle 🫡 @ju_hnny5
85. 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
86. VictoriaMetrics : Une Web UI (vmui) 🤗 https://github.com/VictoriaMetrics/VictoriaMetrics/tree/master/app/vmui @ju_hnny5
87. Intégration : Grafana 🫣 @ju_hnny5
88. Intégration : Grafana 🫣 https://github.com/VictoriaMetrics/grafana-datasource @ju_hnny5
89. vmgateway, vmbackupmanager et vmanomaly @ju_hnny5
90. 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
91. @ju_hnny5 Parti-pris 🙄
92. @ju_hnny5 Le stockage “block”
93. VictoriaMetrics : DownSampling • Feature disponible dans la version Entreprise (depuis 2021) @ju_hnny5
94. 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/
95. Un cas pratique @ju_hnny5
96. 2 clusters déployés dans 2 envs Kubernetes différents. VictoriaMetrics aux @ju_hnny5
97. Pour quel(s) usage(s) ? @ju_hnny5
98. Pour l’infrastructure @ju_hnny5
99. 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
100. @ju_hnny5 Laisser les serveurs allumés ? • Contrat à la consommation ◦ Plus je consomme, plus je paie • Allumer/éteindre de manière totalement automatisée
101. @ju_hnny5
102. + @ju_hnny5
103. Besoin métier : Chambres froides/négatives @ju_hnny5
104. 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)
105. Pour le besoin métier 🧐 @ju_hnny5
106. Pour le besoin métier @ju_hnny5 • V1 = Raspberry PI + dht11 + Prometheus Exporter (Golang)
107. @ju_hnny5
108. Pour le besoin métier @ju_hnny5 • V2 = ESP8266 (Wi-Fi version) + ds18b20 + Prometheus Exporter + batterie +
109. Pour le besoin métier @ju_hnny5 x3
110. Pour le besoin métier @ju_hnny5 On supervise également la température des salles serveurs* 😜
111. Pourquoi avoir choisi VictoriaMetrics ? @ju_hnny5
112. @ju_hnny5
113. @ju_hnny5 Toujours plus de metrics, pour moins de consommation 😶
114. @ju_hnny5 La résilience
115. @ju_hnny5 La simplicité
116. 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)
117. Pourquoi avoir choisi VictoriaMetrics ? @ju_hnny5 • 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. 🤯
118. ➡ https://play.victoriametrics.com @ju_hnny5
119. Instant pub ! 😇
120. @ju_hnny5
121. Merci
122. Un feedback ? @ju_hnny5
123. 🫶 Merci pour votre attention ! 🫶