README
This commit is contained in:
9
README
9
README
@@ -1,9 +0,0 @@
|
|||||||
# Observabilité pour l'IoT et l'Industrie
|
|
||||||
|
|
||||||
## Les 3 piliers de l'observabilité
|
|
||||||
|
|
||||||
### Journaux (événements)
|
|
||||||
|
|
||||||
### Métriques (mesures quantitatives)
|
|
||||||
|
|
||||||
### Traces (chemin d'une requête)
|
|
||||||
56
README.md
Normal file
56
README.md
Normal file
@@ -0,0 +1,56 @@
|
|||||||
|
# Observabilité pour l'IoT et l'Industrie
|
||||||
|
|
||||||
|
## 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éguer 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.
|
||||||
|
|
||||||
|
### 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.
|
||||||
Reference in New Issue
Block a user