observability/README.md

# Observabilité pour l'IoT et l'Industrie


## Supervision

La supervision (monitoring) correspond au processus de collecte, d’analyse et d’utilisation des informations des équipements physiques et logiciels qui composent le système d'informations, afin de suivre les progrès d’un programme vers la réalisation de ses objectifs, de détecter les éventuels dysfonctionnements et de garantir son fonctionnement optimal à tout moment.

Ce suivi porte sur l’observation de paramètres spécifiques et peut fournir bien des données supplémentaires. Mais il est généralement considéré indépendamment du contexte plus large du système.

La supervision consiste à surveiller un système à l’aide d’**indicateurs connus à l’avance**.

C’est une approche réactive : on définit ce qu’on veut surveiller, puis on vérifie que tout reste dans des valeurs normales.

Cela repose typiquement sur :

- des métriques,
- des alertes (seuils dépassés),
- des dashboards (dashboards).

## Observabilité

L’observabilité désigne quant à elle la capacité de comprendre l’état interne d’un système en analysant les données observables dont font partie les artefacts numérisés, tels que les journaux, les traces, les appels API, le temps d’attente, les téléchargements et les transferts de fichiers, qui sont générés lorsqu’une partie prenante prend une mesure quelconque. L’observabilité aide les équipes à analyser ce qui se passe afin de pouvoir détecter et résoudre les causes sous-jacentes des problèmes.

Si l’on devait résumer : la supervision permet de connaître la situation d’un système, tandis que l’observabilité aide à déterminer plus précisément ce qui se passe et ce qu’il convient de faire.

## Les 3 piliers de l'observabilité

### Journalisation (Logging)

La journalisation désigne la pratique consistant à enregistrer les événements qui se produisent dans un système, tels que les erreurs, les avertissements et les messages informatifs.

Chaque entrée de journal (log) contient des informations sur un événement survenu à un moment précis, ce qui aide au suivi du système et au débogage.

#### Types de logs :

##### Logs simples (Plain Logs)

Des logs sous forme de texte libre, faciles à générer mais souvent difficiles à analyser car ils manquent de structure.

##### Logs structurés (Structured Logs)

Des logs généralement formatés en JSON ou dans d’autres formats structurés.
Ils sont beaucoup plus faciles à analyser automatiquement, à agréger et à filtrer.

- Utiliser des bibliothèques de journalisation pour standardiser la forme des logs.
- Agréger les logs pour gérer efficacement un grand volume et éviter les surcharges.
- Stocker les logs dans un système de stockage persistant (ex. Elasticsearch) afin de pouvoir les consulter et les analyser sur le long terme.
- Utiliser des outils de visualisation comme Kibana pour interroger, filtrer et visualiser les données de log.

### Métriques (mesures quantitatives)

Les métriques sont des représentations numériques de données qui décrivent le comportement de composants ou de services au fil du temps.

Elles permettent d’obtenir une vision sur les performances et l’état de santé d’un système.

Les métriques sont généralement agrégées dans le temps, afin d’identifier des **tendances** ou des anomalies.

Elles permettent de comprendre des indicateurs usuels de performance d’un système, tels que :
 - les temps de réponse,
 - les taux d’erreur,
 - l’utilisation des ressources (CPU, mémoire, réseau, etc.).

La plupart des bibliothèques de programmation intègrent des mécanismes pour collecter et exposer des métriques.

Dans certains environnements, des bibliothèques dédiées aux métriques peuvent envoyer les données vers des endpoints prévus pour la supervision.

#### Les 4 types de métriques principales

##### Compteur (Counter)

Valeur monotone qui ne peut qu’augmenter (sauf remise à zéro). Sert à compter un nombre d’événements.

##### Jauge (Gauge)

Valeur qui peut augmenter ou diminuer librement. Représente un état instantané.

##### Histogramme

C'est un ensemble de valeurs qui sont rangées dans des intervalles fixes (appelés buckets). Sert à analyser la distribution des valeurs. Les histogrammes peuvent être cumulés.

##### Résumé statistique (Summary)

Donne des valeurs précises correspondant à des quantiles.



Les fonctions

- rate() — La vitesse moyenne par seconde
- irate() — La vitesse instantanée
- increase() — Le nombre total durant la fenêtre
- deriv() — Dérivée linéaire d’une gauge
- delta() — Différence simple entre deux valeurs (pour gauges)
- idelta() — Delta instantané (deux derniers points)
- resets() — Nombre de resets d’un counter
- changes() — Nombre de changements de valeur


### Traçage (chemin d'une requête)

Le traçage consiste à capturer le parcours d’une requête à travers les différents composants d’un système.

Il permet de comprendre comment les services interagissent entre eux lors de l’exécution d’une même requête.

Chaque trace est associée à un identifiant global (trace ID) transmis à travers l’ensemble des services impliqués.

Des outils de traçage distribué comme Jaeger ou Zipkin permettent de visualiser le chemin parcouru par la requête, afin d’identifier facilement les goulots d’étranglement ou les points de défaillance.

OpenTelemetry fournit une approche standardisée pour implémenter le traçage dans différents langages de programmation.

Le traçage permet de mettre en évidence des problèmes de performance à divers niveaux de l’architecture des services.

## Collecte de métriques

Deux modèles existent pour récupérer les métriques :

### Modèle Pull

Le collecteur (ex : Prometheus) interroge périodiquement les applications.

#### Fonctionnement

Chaque application expose un endpoint HTTP (ex: /metrics)

Le collecteur (Prometheus) vient lire les métriques sur cet endpoint

Le scraper stocke les données dans la base interne TSDB

#### Avantages

- Contrôle centralisé : c’est le collecteur qui décide de la fréquence et des cibles.
- Auto-découverte (service discovery) → énorme avantage en environnement dynamique (Kubernetes, EC2, etc.).
- Pas besoin de “client lourd” côté application.
- Sécurité : pas de flux sortant non contrôlé.

#### Limites

- Ne marche que si le collecteur peut atteindre l’application (réseau, firewall, privé/public).
- Peu adapté aux environnements IoT, serveurs intermittents, fonctions serverless.
- Difficile si l’application ne peut pas exposer un endpoint.

### Modèle Push

L'application envoie activement ses métriques vers un collecteur ou une passerelle.

#### Fonctionnement

L'application pousse ses métriques vers un endpoint (ex: Prometheus PushGateway, OTLP/HTTP, StatsD, Telegraf).

Le collecteur stocke ou retransmet les métriques.

#### Avantages

- Fonctionne même si le collecteur ne peut pas joindre les applications (NAT, firewall, IoT derrière 4G, serverless).
- Idéal pour les jobs courts/éphémères (scripts, cronjobs).
- Compatible avec des environnements sans exposition HTTP.

#### Limites

- Perte de contrôle sur la cadence d’envoi (risque de flood).
- Nécessite un endpoint push sécurisé.
- Peut compliquer la gestion du multi-tenant.

En Prometheus pur : le PushGateway ne doit pas être utilisé pour des services permanents (risque de données obsolètes).

## Affichages des métriques

### KPI : les Indicateurs Clés de Performance

Les KPI (Key Performance Indicator) sont un sous-ensemble d’indicateurs, sélectionnés car ils donnent une vision synthétique de la performance du système.

Un KPI doit être :
- pertinent
- compréhensible
- mesurable
- actionnable
- suivi régulièrement

[TD 1](td1.md)
[TP 1](tp1.md)