# Prometheus

## Intro

Prometheus est un logiciel Open-Source offrant un système de **supervision** et **d'alerte**. Il est écrit en go, offre un simple exécutable lançable très facilement via un service systemd.

Pour enregistrer ses métriques, Prometheus utilise une **base de données time series** qui lui est propre.

Les composants de Prometheus reposent beaucoup sur le protocole HTTP. En général, un service Prometheus principal installé sur un serveur va récupérer toutes les métriques mises à disposition par tout un ensemble d'**exporteurs** installés sur les différents serveurs d'un cluster, via une simple page web.


L'architecture de tout un système de supervision par Prometheus est extrêment modulable. Chaque élement peuvent indépendemment tourner sur différents serveurs et communiquer ensemble.

- Prometheus Server (Serveur principal)
- Prometheus Web Server (système interne de visualisation de métriques/graphs)
- Pushgateway (agrégateur de métriques de différents exporteurs)
- Exporter (collecteur de données / métriques)
- Alertmanager (système d'envoi d'alertes/résolutions par mail, slack, ...)

Prometheus semble particulièrement bien designé pour un cluster Kubernetes.

### Métriques

Chaque métrique est inscrite sur une ligne, avec une syntaxe `metric_name{label1="valeur1",label2="valeur2"} valeur`

Exemple:

# HELP node_disk_io_time_seconds_total Total seconds spent doing I/Os.
# TYPE node_disk_io_time_seconds_total counter
node_disk_io_time_seconds_total{device="sda"} 607858.42
node_disk_io_time_seconds_total{device="sda1"} 0.06
node_disk_io_time_seconds_total{device="sda2"} 0.92
node_disk_io_time_seconds_total{device="sda3"} 607204.144
node_disk_io_time_seconds_total{device="sda4"} 4687.604

Prometheus offre 4 types de métriques:

- Counter (nombre entier incrémental: compteur)
- Gauge (valeurs réelles montantes et descendantes - exemple: température de cpu)
- Histogram (fourni en plus quelques valeurs comme la somme de toutes les valeurs obervées par exemple - exemple: temps de requêtes, taille de réponses)
- Summary (semblables aux histogrammes: [pour plus de détails](https://prometheus.io/docs/practices/histograms/))

### PromQL

Prometheus utilise un langage de requête qui lui est propre et très simple: **PromQL**.

`metric_name{label="value",...}`

#### Lissage des données

Sur un temps donné

`rate(node_network_receive_bytes_total[5m])`

## Exporteurs

Les exporteurs de Prometheus sont en général aussi des exécutables récupérant des informations. Il en existe [de toute sorte](https://prometheus.io/docs/instrumenting/exporters/).

Les exporteurs officiels sont écrits en go mais Prometheus offre plusieurs API afin de créer ses propres exporteurs

- Go
- Python

Une fois qu'un exporter est en place et retourne des données, il est possible de créer des graphes et des alertes en fonction des données retournées.

### node_exporter

Le node_exporter est l'exporter officiel de Prometheus concernant retournant les métriques concernant la partie matérielle d'un serveur.

- Consommation de mémoire / CPU
- Santé des disques
- État du réseau
- Services systemd

#### collectors

Les métriques du node_exporter sont organisées en collecteurs activables ou désactivables via un fichier de configuration. Il existe beaucoup de [collecteurs disponibles](https://github.com/prometheus/node_exporter/tree/master/collector) pour le node_exporter.

## Blackbox

La Blackbox est un exporter particulier: au lieu d'être un programme qui s'exécute depuis le serveur à superviser, elle s'exécute sur le serveur principal de Prometheus et accède à des hôtes distantes via le réseau. Cela permet de superviser entre autres:

- Le ping
- Les requêtes DNS
- Les certificats ssl/tls
- ...

## Myelefant

À ce jour, voici les exporteurs déployés sur les serveurs de Myelefant

| Serveur | node_exporter | supervisord (node_exporter col) | apache_exporter | postgres_exporter | uwsgi_exporter |
|---------|:-------------:|:-----------:|:----:|:----:|:----:|
| m1 | ✔ |
| m3 | ✔ |
| m5 | ✔ |
| m6 | ✔ |
| m7 | ✔ | ✔ |
| m8 | ✔ | ✔ | | | ✔ |
| m9 | ✔ |
| m10 | ✔ | ✔ |
| m11 | ✔ |
| m13 | ✔ | ✔ |
| m14 | ✔ | ✔ |
| m15 | ✔ |
| m16 | ✔ |
| m18 | ✔ |
| m19 | ✔ |
| m20 | ✔ |
| m21 | ✔ |
| m22 | ✔ |
| m23 | ✔ |
| m24 | ✔ |
| m25 | ✔ |
| m26 | ✔ | ✔ |
| m28 | ✔ |
| m29 | ✔ |
| m30 | ✔ |
| m31 | ✔ | ✔ |
| m32 | ✔ |
| m33 | ✔ | | ✔ |
| sesame1 | ✔ |
| sesame2 | ✔ |
| static1 | ✔ |
| static2 | ✔ |
| shdb1 | ✔ | | | ✔ |

## Done ✔

### supervisord_exporter

Le collecteur **supervisord** du **node_exporter** a été activé sur plusieurs serveurs. Une issue est ouverte car le collecteur en question ne sait pas récupérer les données de supervisor sur une socket, mais uniquement sur un port. Il a donc fallu ajouter deux lignes dans les fichiers de configuration de supervisor pour qu'il discute sur un port.

La manipulation nécessite un redémarrage du service supervisor, et donc de tous les services lancés via supervisor. C'est pourquoi le collecteur n'est pas encore actif sur tous les serveurs, nécessitant une interruption des services pendant quelques secondes/minutes.

### apache_exporter

Ansiblisé

### uwsgi_exporter

Ansiblisé

### haproxy_exporter

Ansiblisé

### zeo_myef_exporter

Exporteur python réalisé à partir du script écrit par Brice (`maintenance/databases/zodb/zeo_stats_exporter.py`). À terminer (exporter via server http)

### À noter

Quelques soucis subsistent quant à l'ansibilisation du déploiement de ces exporters, notamment la règle iptables qui ouvre le port d'écoute à m33 pour venir récupérer les métriques via http.

En effet, la règle semble ne pas être prise en compte lorsqu'elle est ajoutée à la fin. Pour l'instant, il faut remonter la règle iptables juste après celle qui correspond au node_exporter.

## Todo !

### Ansibiliser l'installation de Prometheus/Grafana/Alertmanager

### Activer le collecteur supervisord sur tous les serveurs

Pour ce faire, une tâche a été ajoutée dans **mserversetup**:

#### Relancer le role node_exporter si besoin pour prendre en compte la nouvelle conf activant par défaut le collecteur supervisord

ansible-playbook -i inventory/myelefant.yml playbook.yml --tags="node_exporter" --limit mon-serveur.myelefant.com

#### Ouverture du port de communication supervisor

Le port utilisé est renseigné dans `roles/node_exporter/vars/main.yml`

ansible-playbook -i inventory/myelefant.yml playbook.yml --tags="open_supervisor_port" --limit mon-serveur.myelefant.com

### Déployer l'exporteur uWSGI sur les serveurs concernés

Depuis mserversetup:

ansible-playbook -i inventory/myelefant.com playbook.yml --tags="uwsgi_exporter" --limit mon-serveur.myelefant.com

**Souci**: L'exporter n'est pas capable pour l'instant de superviser plusieurs processus uwsgi tournant sur le même serveur.

https://github.com/timonwong/uwsgi_exporter/issues/31

### Déployer l'exporter apache sur les serveurs concernés

Depuis mserversetup:

ansible-playbook -i inventory/myelefant.com playbook.yml --tags="apache_exporter" --limit mon-serveur.myelefant.com

**Souci**: pour l'instant l'exporter apache semble ne pas faire la liaison avec le module *status* de Apache, qui doit fournir les informations nécessaires à l'exporter.

### Déployer l'exporter HAProxy sur les serveurs concernés

Depuis mserversetup:

ansible-playbook -i inventory/myelefant.com playbook.yml --tags="haproxy_exporter" --limit mon-serveur.myelefant.com

#### Redémarrage de supervisor sur le serveur modifié

**--> /!\ ATTENTION!!!! /!\ <--**

Bien penser à faire un `sudo supervisorctl stop all` avant un `sudo systemctl restart supervisor`, sinon les services supervisor ne vont pas s'arrêter correctement et il faudra tuer tous les processus à la main....

## Configuration

### global

[Plus d'infos](https://prometheus.io/docs/prometheus/latest/configuration/configuration/)

# /etc/prometheus/prometheus.yml
global:
  scrape_interval: 1m # intervale de récolte des données sur les exporteurs
  evaluation_interval: 1m # intervale d'évaluation des règles dans rules.d
  scrape_timeout: 10s

rule_files: # Emplacement des règles à évaluer
  - /etc/prometheus/rules.d/*

scrape_configs: # Configuration des données à récolter
  - job_name: node
  static_configs:
    - targets:
      - dix.myelefant.com:19100
      - treize.myelefant.com:19100
      - vignt-six.myelefant.com:19100
      - trente-et-un.myelefant.com:19100
     labels:
       group: myelefant
       type: server
       function: shortener
       label: value
       
  - job_name: other
  static_configs: ...

# Alertmanager configuration
alerting:
  alertmanagers:
  - static_configs:
    - targets: ['localhost:9093']

### règles

Il existe deux types de règles:

- Recording rules: Écrire de nouvelles métriques à partir de requêtes PromQL [infos](https://prometheus.io/docs/prometheus/latest/configuration/recording_rules/)

groups:
  - name: group
  rules:
  - record: job:http_inprogress_requests:sum
    expr: sum(http_inprogress_requests) by (job)

- Alerting rules: Règles levant des alertes si elles sont vérifiées [infos](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/)

groups:
- name: system
  rules:
  - alert: node_down
    expr: up{job="node"} == 0
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: "Instance {{ $labels.function }}/{{ $labels/instance }} down"
      description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 1 minute."

  - alert: high_hardware_temperature
    expr: node_hwmon_temp_celsius > 80
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "Instance {{ $labels.function }}/{{ $labels.instance }}: Core Hardware Temperature > 80°C"
      description: "Instance {{ $labels.function }} ({{ $labels.job }} job) has hardware temperature above 80 degress celsius: {{ printf "%.2f" $value }} for over 5 minutes."

### Alertes

[Plus d'infos](https://prometheus.io/docs/alerting/configuration/)

Les règles d'alertes sont définies dans **Prometheus** mais la gestion de leur communication se fait via la configuration de l'**Alertmanager**.

# /etc/prometheus/alertmanager.yml
global:
  smtp_smarthost: 'localhost:25'
  smtp_from: '[e-mail]'
  smtp_require_tls: false

route:
  # Obligation de définir une route principale pour l'envoi des alertes
  receiver: slack
  group_by:
  - alertname
  - cluster
  - service
  repeat_interval: 2h
  routes:
    - match:
      severity: warning
    receiver: mail

receivers:
  - name: mails
    email_configs:
      - to: [e-mail]
        send_resolved: true
      - to: [e-mail]
        send_resolved: true
      - ...
  - name: slack
    slack_configs:
    - api_url: 'https://hooks.slack.com/...'
      channel: '#monitoring'
      text: 'Description : {{ template "slack.default.text" . }}'
      title: 'Title: {{ template "slack.default.title" . }}'
      send_resolved: true

templates:
- "/etc/prometheus/alertmanager_templates/*.tmpl"

## Écriture d'exporters

Il est possible d'écrire ses propres exporteurs de métriques, il suffit de respecter le modèle. On peut exporter les métriques de deux façons:

- servir un serveur web (conseillé par les bonnes pratiques)
- écrire dans un fichier texte lu par le node_exporter (emplacement par défaut: `/var/lib/prometheus/node_exporter/${filename}.prom`)

# Grafana

## Introduction
Grafana Open-Source est une interface web permettant de généger notamment des graphes et des tableaux de bord *dashboards* à partir des différentes données métriques afin de pouvoir les mettre en forme et les visualier [Info](https://grafana.com/).

Exemple:


Grafana traduit des données métriques issues de Prometheus à l'aide de requêtes PromQL.

Exemple:

node_cpu{job="node"} 

La configuration de l'interface peut se faire de deux manières différentes
* JSON Model
* Interaction sur l'interface

La supervision à partir de grafana permet de regrouper les différentes fonctions selon les besoins, il est notamment possible de créer des variables afin de visualiser les représentations les concernant.

la création de variables se fait soit sur l'interface grace à des paramètres (Nom, Type,...) et une ligne de code en **PromQL** soit en implémentation JSON contenant les mêmes informations.

la configuration de ces dernières nécessite l'implémentation des labels dans le fichier de configuration global de Prometheus.
Les labels sont des "étiquettes" qui permettent de filter des *targets* par type, fonctions ...

Exemple:

- targets:
    - lambda.myelefant.com:00000
    labels: 
        group: myelefant
        type: server
        function: server's function

L'utilisation des variables se fait en indiquant le nom suivi d'un $ dans les paramètres de la requête **PromQL**.

Exemple:

Requête **PromQL** indiquant si l'instance est allumée

up{instance~="$name_variable"}

## Cas Pratique

### Migration vers la nouvelle supervision

La supervision sur Grafana est regrouper dans un dossier *Monitoring*
contenant deux *Dashboards*.
[Supervision](https://sup.myelefant.com)

* L'acceuil
* Recette-supervisor

#### L'acceuil

Pour la supervision actuelle quatres variables ont été mis en place:


* Serveurs ($node)
* Clients ($cert_instance)
* Services ($service)
* Fonctions de serveurs ($function)

Supervision sur Grafana :


**Ping** s'assurer non seulement que les serveurs sont accessibles, mais également mesure le temps mis pour recevoir une réponse ICMP.

* Requête :

probe_icmp_duration_seconds{group="Online",instance=~"$node,job="icmp",phase="resolve"}

**Services** et **Service per server's function** représentent l'état général des instances (serveurs) en fonction des services.

**Services** Chaque panneau "*panel*" représente un serveur et contient autant de requêtes que de services présents dans ce seveurs


* Requête :

(node_systemd_unit_state{instance=~"$node:$port",job=~"$job",name="service_name",state="active"}) * -1

**Services per server's function** Chaque panneau "*panel*" représente une fonction regroupant plusieurs serveurs pour un service choisi.

* Requête :

node_systemd_unit_state{function="$function",name="$service",state="active"} 

Pour ce faire il est nécessaire de selectionner uniquement un service, par contre il est possible de selectionner autant de fonctions que besoin.

Exemple :

Service ssh sur les serveurs d'HAProxy et de BackUp


**Platforms** et **Internal tools** repésentent l'état des sites web client et internes, Le temps restant avant la péremtion des certificats, mais aussi la durée de la requête http.

* Requête

Certificats:

probe_ssl_earliest_cert_expiry{type="website",instance="myelefant.com"} - time()

Requête HTTP:

probe_http_duration_seconds{type="website",phase="resolve"}

Concerant **Facebook-messenger**, **Facebook-messenger-api**, **Rich-sms-V2**, **mlft-push** et **rbm** il a fallu implémenter un *Prometheus-exporter-supervisord* pour avoir accès aux métrics concerant la supervision de l'état des services *supervisord* notamment **zeo**, **uwsgi**, **Daemon** ...

* Requête

node_supervisord_up{name="Supervisor_service_name"}

Pour finir **Sentry** représente l'état de sentry

* Requête

probe_success{instance="https://sentry.yaal.fr/_health/?full"}

#### Recette-supervisor

Le serveur de recette M8 contenant plusieurs services *supervisord* a été mis dans un *Dashboard* à part afin de ne pas encombrer l'acceuil.


La configuration de celui-ci est similaire à celle des services *supervisord* dans l'acceuil.

## Todo !

* Le deploiment des Prometheus-exporters (apache, uwsgi, haproxy) sur les serveurs restant pour avoir accès aux métriques dans le but de pouvoir superviser les services.
Deployer *supervisord* sur les serveurs concernés (M28, M29, M30, M32) et ajouter les compartiments suivant dans la nouvelle supervision en deployant le service sur les serveurs correspondants
**deploy** Concerne un serveur de Yaal (Y7)
**sesame** sesame1 et semane2
**belambra-sms** M18 et M19
**connecteur-myelefant** M19
**richsms-api** M19
**miscellanous** M1, M3, M5 et Y7
**sms** M6 et M11

* Supervision des *Cron*

* supervision des serveurs de réplication

## Liens

[Pad](https://pad.aquilenet.fr/p/yaal-lena-simon)