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

No content

Slide 4

Slide 4 text

@ju_hnny5 Le cloud du Coeur

Slide 5

Slide 5 text

@ju_hnny5

Slide 6

Slide 6 text

On a besoin de vous ! @ju_hnny5

Slide 7

Slide 7 text

@ju_hnny5 https://www.youtube.com/watch?v=pccSZLjKfVo Comment nous avons transformé les Restos du Coeur en Cloud Provider

Slide 8

Slide 8 text

Petit historique du monitoring à l’observabilité 😇 @ju_hnny5

Slide 9

Slide 9 text

La préhistoire 󰷺 @ju_hnny5

Slide 10

Slide 10 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 11

Slide 11 text

Nagios (netsaint) “la supervision” 🥸 @ju_hnny5

Slide 12

Slide 12 text

Nagios (netsaint) “la supervision” 🥸 ● Donné “naissance” à un grand nombre de solutions : ○ Centreon ○ Zabbix* ○ Icinga ○ Shinken (RIP) @ju_hnny5

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

@ju_hnny5 0 = OK

Slide 15

Slide 15 text

@ju_hnny5 1 = Warning

Slide 16

Slide 16 text

@ju_hnny5 2 = Critical

Slide 17

Slide 17 text

@ju_hnny5 3 = Unknown

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

Les indicateurs (metrics) 🙄 @ju_hnny5

Slide 20

Slide 20 text

[me-trik] : “La science de la mesure” @ju_hnny5

Slide 21

Slide 21 text

Des indicateurs exploitables vs indicateurs de vanité* @ju_hnny5

Slide 22

Slide 22 text

Volume Vélocité Variété @ju_hnny5

Slide 23

Slide 23 text

Comment les stocker ? @ju_hnny5

Slide 24

Slide 24 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 25

Slide 25 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 26

Slide 26 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 27

Slide 27 text

L’observabilité, Ce n’est pas qu’une question de monitoring 🤫 @ju_hnny5

Slide 28

Slide 28 text

Comment ça ? @ju_hnny5 ○ Les logs (la centralisation des logs) ■ Elastic ■ Quickwit ■ Fluentbit / Vector, etc … ○ Le tracing (OpenTelemetry - OTEL), ■ Jaeger ■ Quickwit

Slide 29

Slide 29 text

SRE Friendly ! @ju_hnny5

Slide 30

Slide 30 text

Les SRE, un peu de littérature … @ju_hnny5

Slide 31

Slide 31 text

Les SRE @ju_hnny5 https://www.youtube.com/watch?v=tm0UY0MC1po

Slide 32

Slide 32 text

Vouloir tout Monitorer / Observer ! 👀 @ju_hnny5

Slide 33

Slide 33 text

Alerting 😉 Critical / Warning / Notice / Page @ju_hnny5

Slide 34

Slide 34 text

Gestion des incidents 😅 @ju_hnny5

Slide 35

Slide 35 text

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”

Slide 36

Slide 36 text

La performance 💪 @ju_hnny5

Slide 37

Slide 37 text

Des solutions ? 🤫 @ju_hnny5

Slide 38

Slide 38 text

Des solutions ?

Slide 39

Slide 39 text

Des solutions ?

Slide 40

Slide 40 text

Des solutions ? 😬

Slide 41

Slide 41 text

Des solutions ? 😬

Slide 42

Slide 42 text

@ju_hnny5

Slide 43

Slide 43 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 44

Slide 44 text

Standard de facto : Prometheus 😏 Source : https://prometheus.io/docs/introduction/overview/ @ju_hnny5

Slide 45

Slide 45 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 46

Slide 46 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 47

Slide 47 text

Mais pas sans défauts … 😅 @ju_hnny5

Slide 48

Slide 48 text

@ju_hnny5

Slide 49

Slide 49 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 50

Slide 50 text

Un peu de glue : Thanos 🧐 @ju_hnny5

Slide 51

Slide 51 text

@ju_hnny5

Slide 52

Slide 52 text

Un peu de glue : Cortex 🧐 @ju_hnny5

Slide 53

Slide 53 text

@ju_hnny5

Slide 54

Slide 54 text

No content

Slide 55

Slide 55 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 56

Slide 56 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 57

Slide 57 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 58

Slide 58 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 59

Slide 59 text

Deux versions Community 🤭 Enterprise 🤫

Slide 60

Slide 60 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 61

Slide 61 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 62

Slide 62 text

Quelques (gros) utilisateurs @ju_hnny5

Slide 63

Slide 63 text

Single-node = Scales vertically 🫣 @ju_hnny5

Slide 64

Slide 64 text

Cluster = Scales horizontally 🤗 @ju_hnny5

Slide 65

Slide 65 text

Ces deux modes partagent le même code. 🤩 @ju_hnny5

Slide 66

Slide 66 text

VictoriaMetrics : Une architecture simple 😇 victoria-metrics vmstorage vminsert vmselect Un seul noeud Version cluster @ju_hnny5 vmagent vmui

Slide 67

Slide 67 text

VictoriaMetrics : Une architecture simple 😇 @ju_hnny5

Slide 68

Slide 68 text

Multi-tenancy ? 🙄 @ju_hnny5

Slide 69

Slide 69 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 70

Slide 70 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 71

Slide 71 text

Collect metrics ? 🤩 @ju_hnny5

Slide 72

Slide 72 text

VictoriaMetrics : Ingestion de données 🤩 Source : https://shorturl.at/nxNX2 https://github.com/VictoriaMetrics/VictoriaMetrics/tree/master/app/vminsert @ju_hnny5

Slide 73

Slide 73 text

VictoriaMetrics : Ingestion de données 🤩 @ju_hnny5

Slide 74

Slide 74 text

VictoriaMetrics : Ingestion de données 🤩 @ju_hnny5

Slide 75

Slide 75 text

VictoriaMetrics : Ingestion de données 🤩 @ju_hnny5

Slide 76

Slide 76 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 77

Slide 77 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 78

Slide 78 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 79

Slide 79 text

VictoriaMetrics : Se faire alerter ! 🫨 Source : https://shorturl.at/nxNX2 https://github.com/VictoriaMetrics/VictoriaMetrics/tree/master/app/vmalert Pull Push @ju_hnny5

Slide 80

Slide 80 text

VictoriaMetrics : Se faire alerter ! 🫨 @ju_hnny5

Slide 81

Slide 81 text

VictoriaMetrics : Se faire alerter ! 🫨 @ju_hnny5

Slide 82

Slide 82 text

Migrer les données 🫨 @ju_hnny5

Slide 83

Slide 83 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 84

Slide 84 text

Un peu de contrôle 🫡 @ju_hnny5

Slide 85

Slide 85 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 86

Slide 86 text

VictoriaMetrics : Une Web UI (vmui) 🤗 https://github.com/VictoriaMetrics/VictoriaMetrics/tree/master/app/vmui @ju_hnny5

Slide 87

Slide 87 text

Intégration : Grafana 🫣 @ju_hnny5

Slide 88

Slide 88 text

Intégration : Grafana 🫣 https://github.com/VictoriaMetrics/grafana-datasource @ju_hnny5

Slide 89

Slide 89 text

vmgateway, vmbackupmanager et vmanomaly @ju_hnny5

Slide 90

Slide 90 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 91

Slide 91 text

@ju_hnny5 Parti-pris 🙄

Slide 92

Slide 92 text

@ju_hnny5 Le stockage “block”

Slide 93

Slide 93 text

VictoriaMetrics : DownSampling ● Feature disponible dans la version Entreprise (depuis 2021) @ju_hnny5

Slide 94

Slide 94 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 95

Slide 95 text

Un cas pratique @ju_hnny5

Slide 96

Slide 96 text

2 clusters déployés dans 2 envs Kubernetes différents. VictoriaMetrics aux @ju_hnny5

Slide 97

Slide 97 text

Pour quel(s) usage(s) ? @ju_hnny5

Slide 98

Slide 98 text

Pour l’infrastructure @ju_hnny5

Slide 99

Slide 99 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 100

Slide 100 text

@ju_hnny5 Laisser les serveurs allumés ? ● Contrat à la consommation ○ Plus je consomme, plus je paie ● Allumer/éteindre de manière totalement automatisée

Slide 101

Slide 101 text

@ju_hnny5

Slide 102

Slide 102 text

+ @ju_hnny5

Slide 103

Slide 103 text

Besoin métier : Chambres froides/négatives @ju_hnny5

Slide 104

Slide 104 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 105

Slide 105 text

Pour le besoin métier 🧐 @ju_hnny5

Slide 106

Slide 106 text

Pour le besoin métier @ju_hnny5 ● V1 = Raspberry PI + dht11 + Prometheus Exporter (Golang)

Slide 107

Slide 107 text

@ju_hnny5

Slide 108

Slide 108 text

Pour le besoin métier @ju_hnny5 ● V2 = ESP8266 (Wi-Fi version) + ds18b20 + Prometheus Exporter + batterie +

Slide 109

Slide 109 text

Pour le besoin métier @ju_hnny5 x3

Slide 110

Slide 110 text

Pour le besoin métier @ju_hnny5 On supervise également la température des salles serveurs* 😜

Slide 111

Slide 111 text

Pourquoi avoir choisi VictoriaMetrics ? @ju_hnny5

Slide 112

Slide 112 text

@ju_hnny5

Slide 113

Slide 113 text

@ju_hnny5 Toujours plus de metrics, pour moins de consommation 😶

Slide 114

Slide 114 text

@ju_hnny5 La résilience

Slide 115

Slide 115 text

@ju_hnny5 La simplicité

Slide 116

Slide 116 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)

Slide 117

Slide 117 text

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. 🤯

Slide 118

Slide 118 text

➡ https://play.victoriametrics.com @ju_hnny5

Slide 119

Slide 119 text

Instant pub ! 😇

Slide 120

Slide 120 text

@ju_hnny5

Slide 121

Slide 121 text

Merci

Slide 122

Slide 122 text

Un feedback ? @ju_hnny5

Slide 123

Slide 123 text

🫶 Merci pour votre attention ! 🫶

Slide 124

Slide 124 text

No content