###### tags: `monitoring` `alerting` `prometheus` `semaine mathrice` `présentation` # Monitoring sur la PLM ### Retour d'expérience de la mise en place d'un monitoring et alerting avec grafana et victoriametrics --- ## Plan 1. Introduction et historique 2. Schéma explicatif général 3. Quelques mots sur les metrics 4. Exemple de configuration de scrapping & envoi sur un serveur victoriaMetrics 5. Un retour d'expérience sur les dashboards & alertes 6. Évolution et alternatives --- ### Grafana <div style="font-size: 30px;"> <ul> <li>Projet OpenSource créé en 2014</li> <li>Créateur: Torkel Ödegaard</li> <li>Licence: `GNU AfferoGeneralPublic V3`</li> <li>Permet de visualiser trois types de données:</li> <ul> <li>les metrics - les TimeSeries Database (Prometheus, VictoriaMetrics) </li> <li>les logs - agrégateur de log (Loki)</li> <li>les traces (Zipkin ou Jaeger)</li> </ul> <li>Il peut générer des alertes selon les seuils que vous avez configurés</li> </ul> </div> <!---- Plusieurs connecteurs:  --> ---- Dispose d'un catalogue de dashboards déjà présent https://grafana.com/grafana/dashboards/  ---- ## Schéma de flux - example Prometheus  ---- ## Schéma de flux - example VictoriaMetrics  ---- ## Schéma de flux - example PLMlab  --- ## Quelques mots sur les metrics ### Différence entre counter & gauge Il est important d'avoir ces deux différences car les fonctions et les types de graphes utilisé seront différents Counter: Valeur incrémentée Gauge: valeur instantanée ---- Pour le counter: fonctions: Rate (mesure une moyenne) ou Increase (mesure une augmentation) Graphe: TimeSeries (graphe évolutif)  ---- Pour le Gauge: fonctions: Delta (différence entre deux timestamps) ou Deriv (augmentation par seconde) Graphe: Gauge, tableau, texte  ---- Pour plus d'infos, faire une requête CURL sur un "exporter" : ```txt # HELP node_timex_pps_jitter_total Pulse per second count of jitter limit exceeded events. # TYPE node_timex_pps_jitter_total counter node_timex_pps_jitter_total 0 # HELP node_timex_pps_shift_seconds Pulse per second interval duration. # TYPE node_timex_pps_shift_seconds gauge node_timex_pps_shift_seconds 0 ``` --- ### Exemple de configuration de scrapping & envoi sur un serveur prometheus #### Sur plmlab ---- Configuration process-exporter ```yaml= process_names: - exe: - /opt/gitlab/embedded/bin/gitlab-pages - /opt/gitlab/embedded/bin/mattermost - /opt/gitlab/embedded/bin/postgres - /sbin/iscsid - comm: - redis-server - exe: - ruby cmdline: - '.*mail_room.*' ``` ---- Exemple de configuration d'un prometheus pour scrapper les données: ```ruby prometheus['scrape_configs'] = [ { 'job_name': 'process-exporter', 'static_configs' => [ 'targets' => ['localhost:9256'], ] } ] ``` ---- Exemple d'envois de donnée sur un autre serveur : ```ruby prometheus['remote_write'] = [ { url: 'https://********.math.cnrs.fr/api/v1/write', .... } ] ``` --- ### CR - Retour d'expérience #### Dashboards <div style="font-size: 30px;"> <ul> <li>Il faut savoir ce que vous voulez monitorer</li> <ul> <li>Mettre en avant des données qui vous parle</li> <li>que voulons-nous monitorer ?</li> <ul> <li>quels services ?</li> <li>Volumes ? (montages ISCSI)</li> <li>quelles activités ? (git push, issues, merge request, login ...)</li> <li>est-ce que l'on a les metrics ? ==> sinon rajouter ou créer des exporters (process-exporter pour gitlab-page)</li> </ul> </ul> </ul> </div> ---- - Beaucoup de choix  ---- - Une étude des dashboards peut aider mais des fois pas suffisant ... - Pour Plmlab, souvent les metrics n'existaient plus <div style="display: flex;"> <img src="https://codimd.math.cnrs.fr/uploads/d45be488caa29469ce389e82a.png" style="width: 50%;"> <img src="https://codimd.math.cnrs.fr/uploads/d45be488caa29469ce389e8bd.png" style="width: 50%; margin-left: 5%"> </div> ---- - relabelling est important - sinon on se perd et ne sait plus faire la différence entre localhost & localhost  ---- exemple de relabelling en ruby : ```ruby= prometheus['scrape_configs'] = [ { 'job_name': 'node-exporter', 'static_configs' => [ 'targets' => ['plmlab.gricad:9100'], ], 'relabel_configs' => [ 'target_label': 'instance', 'replacement': 'plmlab.gricad' ], }, { 'job_name': 'process-exporter', 'static_configs' => [ 'targets' => ['plmlab.gricad:9256'], ], 'relabel_configs' => [ 'target_label': 'instance', 'replacement': 'plmlab.gricad.pe' ], } ] ``` ---- Exemple de dashboard de plmlab: https://console.supervision.mathrice-plm.virtualdata.cloud.math.cnrs.fr/d/pV1-fisSU/plmlab-overview?orgId=1&refresh=5s --- # CR - Retour d'expérience ## Alertes - il existe différents outils pour la génération d'alertes: - prometheus - grafana ---- #### Pourquoi grafana-alerte ? - gestion en mode gitops (dashboards et alertes versionner au même endroit) - Je me base sur les metrics pour faire les alertes et définir les seuils. ---- Exemple d'une alerte: - 1er exemple: `up{job="gitlab-rails"}` - 2ème exemple: namedprocess_namegroup_oldest_start_time_seconds{instance="plmlab.gricad.pe", groupname="mattermost"} ---- Critères d'évaluation :  ---- Cannaux d'alertes: <img src="https://codimd.math.cnrs.fr/uploads/d45be488caa29469ce389e859.png" style="width: 48%" /> ---- Exemple avec PLMLAB https://console.supervision.mathrice-plm.virtualdata.cloud.math.cnrs.fr/alerting/list --- Alternative et futur ? <div style="font-size: 30px;"> <ul> <li>ELK ? </li> <ul> <li>trop lourd ? </li> <li>bien qu'il soit similaire, lui se spécialise sur les logs</li> </ul> <li>openTelemetry</li> <ul> <li>se présente comme l'avenir</li> <li>permet de gérer les trois axes (metrics, logs, traces)</li> <li>toujours dépendant de serveurs pour stocker les données (prometheus, loki)</li> </ul> </ul> </div> --- # Liens - [Introduction à openTelemetry](https://www.youtube.com/watch?v=avxwyYUkXe0) - [Bonnes pratiques Dashboard grafana](https://grafana.com/docs/grafana/latest/dashboards/build-dashboards/best-practices/) - [Liste des dashboards gitlab](https://gitlab.com/gitlab-org/grafana-dashboards/-/tree/master/dashboards?ref_type=heads) - [Prometheus - grafanas - tutoriels](https://www.youtube.com/playlist?list=PLn6POgpklwWo3_2pj5Jflqwla62P5OI8n)