Slide 1
Slide 1 text
Observabilité :
dépoussiérer
Prometheus avec
@ju_hnny5
Slide 2
Slide 2 text
~#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
Slide 3
Slide 3 text
@ju_hnny5
Le cloud
du Coeur
Slide 4
Slide 4 text
@ju_hnny5
Slide 5
Slide 5 text
Petit historique
du monitoring à l’observabilité 😇
@ju_hnny5
Slide 6
Slide 6 text
La préhistoire
@ju_hnny5
Slide 7
Slide 7 text
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
Slide 8
Slide 8 text
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
Slide 9
Slide 9 text
@ju_hnny5
0 = OK
Slide 10
Slide 10 text
@ju_hnny5
1 = Warning
Slide 11
Slide 11 text
@ju_hnny5
2 = Critical
Slide 12
Slide 12 text
@ju_hnny5
3 = Unknown
Slide 13
Slide 13 text
Les indicateurs (metrics) 🙄
@ju_hnny5
Slide 14
Slide 14 text
[me-trik] : “La science de la mesure”
@ju_hnny5
Slide 15
Slide 15 text
Des indicateurs exploitables
vs indicateurs de vanité*
@ju_hnny5
Slide 16
Slide 16 text
Volume
Vélocité
Variété
@ju_hnny5
Slide 17
Slide 17 text
Comment
les stocker ?
@ju_hnny5
Slide 18
Slide 18 text
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
Slide 19
Slide 19 text
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"}
Slide 20
Slide 20 text
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
Slide 21
Slide 21 text
Des solutions ? 🤫
@ju_hnny5
Slide 22
Slide 22 text
@ju_hnny5
Slide 23
Slide 23 text
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
Slide 24
Slide 24 text
Standard de facto : Prometheus 😏
Source : https://prometheus.io/docs/introduction/overview/
@ju_hnny5
Slide 25
Slide 25 text
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
Slide 26
Slide 26 text
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
Slide 27
Slide 27 text
Mais pas sans défauts … 😅
@ju_hnny5
Slide 28
Slide 28 text
@ju_hnny5
Slide 29
Slide 29 text
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
Slide 30
Slide 30 text
Un peu de glue : Thanos 🧐
@ju_hnny5
Slide 31
Slide 31 text
@ju_hnny5
Slide 32
Slide 32 text
Un peu de glue : Cortex 🧐
@ju_hnny5
Slide 33
Slide 33 text
@ju_hnny5
Slide 34
Slide 34 text
No content
Slide 35
Slide 35 text
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
Slide 36
Slide 36 text
● 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
Slide 37
Slide 37 text
● 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
Slide 38
Slide 38 text
● 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
Slide 39
Slide 39 text
Deux versions
Community 🤭 Enterprise 🤫
Slide 40
Slide 40 text
● 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é 🫨
Slide 41
Slide 41 text
● 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
Slide 42
Slide 42 text
Quelques (gros)
utilisateurs
@ju_hnny5
Slide 43
Slide 43 text
Single-node = Scales vertically 🫣
@ju_hnny5
Slide 44
Slide 44 text
Cluster = Scales horizontally 🤗
@ju_hnny5
Slide 45
Slide 45 text
Ces deux modes partagent
le même code. 🤩
@ju_hnny5
Slide 46
Slide 46 text
VictoriaMetrics : Une architecture simple 😇
victoria-metrics vmstorage
vminsert
vmselect
Un seul noeud Version cluster
@ju_hnny5
vmagent
vmui
Slide 47
Slide 47 text
VictoriaMetrics : Une architecture simple 😇
@ju_hnny5
Slide 48
Slide 48 text
Multi-tenancy ? 🙄
@ju_hnny5
Slide 49
Slide 49 text
● Tenants identifiés par accountID ou accountID:projectID 😲
● Lister les tenants enregistrés via :
○ http://: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/
Ne prend pas en charge l’interrogation de plusieurs tenants dans une
seule requête.
VictoriaMetrics : Namespaces 😎
@ju_hnny5
Slide 50
Slide 50 text
● 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
Slide 51
Slide 51 text
Collect
metrics ? 🤩
@ju_hnny5
Slide 52
Slide 52 text
VictoriaMetrics : Ingestion de données 🤩
Source : https://shorturl.at/nxNX2
https://github.com/VictoriaMetrics/VictoriaMetrics/tree/master/app/vminsert
@ju_hnny5
Slide 53
Slide 53 text
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
Slide 54
Slide 54 text
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
Slide 55
Slide 55 text
VictoriaMetrics : Lecture des données 😲
Source : https://shorturl.at/nxNX2
https://github.com/VictoriaMetrics/VictoriaMetrics/tree/master/app/vmselect
Pull
Pull
@ju_hnny5
Slide 56
Slide 56 text
VictoriaMetrics : Se faire
alerter ! 🫨
Source : https://shorturl.at/nxNX2
https://github.com/VictoriaMetrics/VictoriaMetrics/tree/master/app/vmalert
Pull
Push
@ju_hnny5
Slide 57
Slide 57 text
Migrer les données 🫨
@ju_hnny5
Slide 58
Slide 58 text
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)
Slide 59
Slide 59 text
Un peu de
contrôle 🫡
@ju_hnny5
Slide 60
Slide 60 text
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
Slide 61
Slide 61 text
VictoriaMetrics : Une Web UI (vmui) 🤗
https://github.com/VictoriaMetrics/VictoriaMetrics/tree/master/app/vmui @ju_hnny5
Slide 62
Slide 62 text
Intégration : Grafana 🫣
@ju_hnny5
Slide 63
Slide 63 text
Intégration : Grafana 🫣
https://github.com/VictoriaMetrics/grafana-datasource
@ju_hnny5
Slide 64
Slide 64 text
vmgateway, vmbackupmanager
et vmanomaly
@ju_hnny5
Slide 65
Slide 65 text
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
Slide 66
Slide 66 text
VictoriaMetrics : DownSampling
● Feature disponible dans la version Entreprise (depuis 2021)
@ju_hnny5
Slide 67
Slide 67 text
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/
Slide 68
Slide 68 text
Un cas pratique
@ju_hnny5
Slide 69
Slide 69 text
2 clusters déployés dans
2 envs Kubernetes différents.
VictoriaMetrics aux
@ju_hnny5
Slide 70
Slide 70 text
Pour quel(s)
usage(s) ?
@ju_hnny5
Slide 71
Slide 71 text
Pour l’infrastructure
@ju_hnny5
Slide 72
Slide 72 text
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
Slide 73
Slide 73 text
Besoin métier :
Chambres froides/négatives
@ju_hnny5
Slide 74
Slide 74 text
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)
Slide 75
Slide 75 text
Pour le besoin métier
@ju_hnny5
● V1 = Raspberry PI + dht11 +
Prometheus Exporter (Golang)
Slide 76
Slide 76 text
@ju_hnny5
Slide 77
Slide 77 text
Pour le besoin métier
@ju_hnny5
● V2 = ESP8266 (Wi-Fi version) + ds18b20 + Prometheus Exporter +
batterie +
Slide 78
Slide 78 text
Pour le besoin métier
@ju_hnny5
x3
Slide 79
Slide 79 text
Pour le besoin métier
@ju_hnny5
On supervise également la température des salles serveurs* 😜
Slide 80
Slide 80 text
Pourquoi avoir choisi
VictoriaMetrics ?
@ju_hnny5
Slide 81
Slide 81 text
@ju_hnny5
Toujours plus de metrics,
pour moins de consommation 😶
Slide 82
Slide 82 text
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. 🤯
Slide 83
Slide 83 text
➡ https://play.victoriametrics.com
@ju_hnny5
Slide 84
Slide 84 text
Instant pub ! 😇
Slide 85
Slide 85 text
@ju_hnny5
Slide 86
Slide 86 text
Merci
Slide 87
Slide 87 text
Un feedback ?
@ju_hnny5
Slide 88
Slide 88 text
🫶 Merci pour
votre attention ! 🫶
Slide 89
Slide 89 text
No content