<!-- .slide: class="prez-slide-title-page" -->
# PF-2640<br/>Thanos Receiver<!-- .element: style="font-size: 2em" -->
#### Démo Équipe Monitoring du 11/04/2024
---
# Le problème
## (Yves)<!-- .element: class="prez-slide-qui" -->
- Prometheus-central explose trop souvent
- Prometheus-central met trop de temps à redémarrer et cela cause l'explosion suivante
- Il faut "vidanger" tous les Prometheus-cluster pour redémarrer
- Prometheus-central est monolithique et supporte mal le passage à l'échelle
---
# Les solutions
## (Yves)<!-- .element: class="prez-slide-qui" -->
- **Prometheus** avec des *shards*
- applicable seulement pour le scrapping
- non applicable pour le remote-receive
- **Mimir** : la cible de NGOT-2025
- on ne connait pas encore ce logiciel
- il aurait fallu prévoir un temps d'apprentissage
- il aurait fallu prévoir une migration de l'existant
- **Thanos-Receive**
- il faut "juste" déployer un nouveau composant de ce logiciel qu'on connaît déjà
- il faut "juste" déployer aussi un Thanos-Ruler
- c'est la solution a priori la plus rapide à mettre en prod
- c'est la solution nécessitant a priori la plus faible montée en compétence de l'équipe Supervision
---
# Thanos-Receiver
## (Yves)<!-- .element: class="prez-slide-qui" -->
Thanos-Receiver implémente le protocole Remote-Receive de Prometheus.
Il est possible de distribuer le travail sur plusieurs Thanos-Receivers.
En cas de problème comme avec Prometheus, il suffit donc de "scale up" le nombre de receivers.
---
# Thanos-Ruler
## (Yves)<!-- .element: class="prez-slide-qui" -->
Si Prometheus est déchargé de son rôle de "receiver", il ne dispose plus de l'ensemble des métriques NGOT. Il n'est donc plus en mesure d'évaluer les rules et d'alerter.
Il faut donc un composant ayant accès à toutes les métriques et pouvant évaluer les rules et alerter : Thanos-Ruler
---
<!-- .slide: class="prez-slide-schema-architecture" -->
# Schéma d'architecture (1/2)
## (Yves)<!-- .element: class="prez-slide-qui" -->
---
# Schéma d'architecture (2/2)
## (Nolwenn)<!-- .element: class="prez-slide-qui" -->
[Schéma dans Confluence](https://confluence.corp.caascad.com/pages/viewpage.action?pageId=32376603#ThanosReceiver+Ruler-Principedel'architecture) : noter les blocs
- Receiver et Distributor :new:
- Ruler et Querier dédié :new:
- Querier "proxy" :new:
- Store Gateway : même rôle qu'avant
- Compactor : même rôle qu'avant
---
# Thanos-Receive "distributor"
## (Nolwenn)<!-- .element: class="prez-slide-qui" -->
Le composant "distributor" n'est rien d'autre qu'un Thanos-Receive. Sa configuration diffère des "receivers" :
- il est stateless (plus rapide) et en HA
- il connait tous les "receivers" : il forwarde aux "receivers" selon un algorithme de hachage "ketama"
- il facilite le "scale up" et minimise le temps d'indisponibilité
---
<!-- .slide: class="prez-slide-ruler-querier" -->
# Thanos-Ruler et Thanos-Querier
## (Nolwenn)<!-- .element: class="prez-slide-qui" -->
Thanos-Ruler est déployé par Prometheus-Operator
- bénéficie de la configuration automatique à partir des PrometheusRules
- configuré dans [contexts/ngot/kube-prometheus-stack.cue](https://git.corp.caascad.com/caascad/terraform/envs-ng/-/blob/master/contexts/ngot/kube-prometheus-stack.cue) et non [thanos.cue](https://git.corp.caascad.com/caascad/terraform/envs-ng/-/blob/master/contexts/ngot/thanos.cue).
Thanos-Ruler évalue ses expressions en obtenant les métriques à partir de Thanos-Querier.
- Thanos-Querier dédié (2 replicas pour plus de HA).
- évite les perturbations des consultations via Grafana.
---
# Thanos-Querier "proxy"
## (Nolwenn)<!-- .element: class="prez-slide-qui" -->
Un composant Thanos-Querier, que nous appelons "proxy" a été ajouté
- parce que le querier de Grafana n'interroge qu'une seule cible (à cause de envoy)
- par effet collatéral, il simplifie l'architecture de façon élégante
Ce composant pourrait également être déployé dans la stack actuelle pour simplifier la configuration du querier (pour pointer sur le sidecar et le store-gateway) mais la valeur ajoutée est moindre.
---
<!-- .slide: class="prez-slide-ruler-topologie" -->
# Topologie
## (Yves)<!-- .element: class="prez-slide-qui" -->
Sur Prometheus Central :
- un noeud forcé sur une AZ par `topology`
- Prometheus forcé sur ce noeud
- problème : Thanos store, Cloudeye-exporter, Blackbox-exporter, Alertmanager et Kthxbye ne sont pas attachés à une AZ
Sur Thanos-Receiver :
- les pods sont forcés sur des noeuds d'une AZ par `nodeAffinity`
- en place pour Prometheus, Thanos Queriers, Receivers et Distributors, Rulers et Store
- à faire pour Alertmanager et Kthxbye, Blackbox-exporter et Cloudeye-exporter
- affinité hard pour les distributors, soft pour les receivers
- pas besoin de noeuds spécifiques
---
<!-- .slide: class="prez-slide-ruler-metrologie" -->
# Métrologie
## (Nolwenn)<!-- .element: class="prez-slide-qui" -->
Un [dashboard spécifique](https://grafana.obs-corp-prd.cloudservicesfactory.com/d/d1001822-7080-49f8-8bf2-0b0fa83a1186/pf-2640) a été créé. Voir également l'[étude dans Confluence](https://confluence.corp.caascad.com/pages/viewpage.action?pageId=32376603#ThanosReceiver+Ruler-M%C3%A9trologie)
Les divers tests montrent globalement que, comparativement à Prometheus Central :
- CPU : la consommation est supérieure
- Mémoire : la consommation est légèrement supérieure
- Disques : la somme des PV/PVC est supérieure
---
# Tests effectués
## (Nolwenn)<!-- .element: class="prez-slide-qui" -->
Principaux tests effectués :
- scale up, scale down (nombre de receivers)
- redémarrage d'un distributor, d'un receiver
- variations du nombre de distributors
- déploiement recording rule
Résultats conformes à ce qui est attendu.
Au démarrage, les distributors demandent beaucoup de mémoire (limite mémoire élevée)
Lors d'un incident (scale up/down, redémarrage...) les Prometheus-Cluster "se mettent en incident".
---
<!-- .slide: class="prez-slide-deja-en-prod" -->
# Opérations : ce qui est déjà sur la prod
## (Yves)<!-- .element: class="prez-slide-qui" -->
Tous les composants sont déployés :
- cluster `kub-53`
- zone `svc-monitoring-stack-corp-prd-1`
- svc_hint `mon3`
Karma est connecté aux Alertmanagers.
Les Alertmanagers n'envoient aucune notification.
Des silences sont posés parce qu'il n'y a pas encore de MCO sur cette zone.
---
# Opérations : le passage en prod
## (Nolwenn)<!-- .element: class="prez-slide-qui" -->
- Une stack "`mon3`" (zone svc-monitoring-stack-corp-prd-1) a déjà été déployée : [CAASCHR-2582](https://jira.corp.caascad.com/browse/CAASCHR-2582)
- Il faut terminer les étapes nécessaires au MCO
- Puis passer "`mon3`" en MCO (avec "`mon1`", "`mon2`")
- La zone "`mon4`" viendra rapidement après, suivie de la suppression de "`mon1`", "`mon2`" et d'autres étapes de nettoyage
---
<!-- .slide: class="prez-slide-graph" -->
# Opérations : le passage en prod
## (Nolwenn)<!-- .element: class="prez-slide-qui" -->
```mermaid
graph TD
DEBUT((*)) --> PF-2925["PF-2925<br>tests de conformité"]
DEBUT --> PF-2926["PF-2926<br>alerting"]
PF-2925 --> PF-2931["PF-2931<br>automatisation via envs-ng/trackbone<br>du déploiement de Thanos-v3"]
PF-2925 --> PF-2928["PF-2928<br>notifications + go MCO"]
PF-2926 --> PF-2928
PF-2928 --> PF-2927["PF-2927<br>déploiement de mon4"]
PF-2927 --> PF-2930["PF-2930<br>cleanup"]
PF-2929 --> FINI
PF-2930 --> PF-2929["PF-2929<br>documentation"]
PF-2931 --> FINI((*))
```
---
<!-- .slide: class="prez-slide-conclusion" -->
# Conclusion
## (Yves)<!-- .element: class="prez-slide-qui" -->
Ceci n'est pas la conclusion !<!-- .element: style="text-align: center; margin-top: -0.7em" -->
Après 3 mois de travail, nous avons plein de détails à vous présenter, y compris sur l'existant.
Mais...
- *Prometheus-Central explose trop souvent* : l'origine du problème semble être au niveau de Prometheus-Cluster. Thanos-Receiver n'apporte rien
- Il faut toujours "vidanger" tous les Prometheus-Cluster pour redémarrer (et potentiellement Thanos-Receiver aussi)
- Thanos-Receiver coûte un peu plus cher que Prometheus-Central
Heureusement :
- Thanos-Receiver/Distributors redémarrent plus vite
- Thanos-Receiver/Distributors passent mieux à l'échelle
---
<!-- .slide: class="prez-slide-conclusion2" -->
# Conclusion
## (Yves)<!-- .element: class="prez-slide-qui" -->
La conclusion est à construire ensemble.
Le POC et un MVP sont en place à 90%
Il faut [comparer](https://confluence.corp.caascad.com/pages/viewpage.action?pageId=32376603#ThanosReceiver+Ruler-ComparatifThanos-Receiver/Prometheus) Prometheus Central et Thanos-Receive pour savoir si on valide le POC
Si le POC est validé, une autre présentation aura lieu avec plus de détails techniques.
<style type="text/css">
p {
font-size: 0.8em;
}
.reveal ul li {
font-size: 0.8em;
}
.reveal ul ul li {
font-size: 0.6em;
}
.reveal ol li {
font-size: 0.8em;
}
.reveal section {
text-align: left;
}
}
.reveal h3 {
color: orange;
text-align: center;
border-bottom: 1px solid orange;
font-size: 1em;
}
.reveal h1 {
color: orange;
text-align: center;
border-bottom: 1px solid orange;
margin-bottom: 0.4em;
font-size: 1.2em;
}
.reveal code {
color: aquamarine;
font-size: smaller;
}
.prez-slide-title-page div {
text-align: center;
}
.prez-slide-ruler-querier div {
font-size: smaller;
}
.prez-slide-ruler-topologie div {
font-size: smaller;
}
.prez-slide-ruler-metrologie div {
font-size: smaller;
}
.prez-slide-deja-en-prod div {
font-size: smaller;
}
.prez-slide-schema-architecture div {
text-align: center;
}
.prez-slide-conclusion div {
font-size: smaller;
}
.prez-slide-graph svg {
width: 40%;
}
.prez-slide-pas-parle-de ul li {
font-size: 0.6em;
}
h2.prez-slide-qui {
margin: 0;
font-size: .2em;
text-align: right;
color: white;
}
</style>