Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Observabilité : dépoussiérer Prometheus avec Vi...

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.

Julien Briault

April 18, 2024
Tweet

More Decks by Julien Briault

Other Decks in Technology

Transcript

  1. ~#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
  2. 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
  3. 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
  4. 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
  5. 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"}
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. • 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
  13. • 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
  14. • 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
  15. • 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é 🫨
  16. • 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
  17. • 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
  18. • 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
  19. 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
  20. VictoriaMetrics : Se faire alerter ! 🫨 Source : https://shorturl.at/nxNX2

    https://github.com/VictoriaMetrics/VictoriaMetrics/tree/master/app/vmalert Pull Push @ju_hnny5
  21. 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)
  22. 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
  23. 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
  24. 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/
  25. 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
  26. 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)
  27. Pour le besoin métier @ju_hnny5 • V1 = Raspberry PI

    + dht11 + Prometheus Exporter (Golang)
  28. Pour le besoin métier @ju_hnny5 • V2 = ESP8266 (Wi-Fi

    version) + ds18b20 + Prometheus Exporter + batterie +
  29. 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. 🤯