Fondamentaux du monitoring¶

Comprendre les bases : monitoring vs observabilité, les 3 piliers, et les méthodes de mesure essentielles.

Monitoring vs observabilité¶

Ces deux termes sont souvent confondus mais désignent des approches distinctes.

Critère	Monitoring	Observabilité
Approche	Prédire les pannes connues	Comprendre un état inconnu
Questions	"Est-ce que ca marche ?"	"Pourquoi ca ne marche pas ?"
Données	Métriques prédéfinies	Logs, métriques, traces correles
Alerting	Seuils fixes	Comportement anormal
Idéal pour	Systèmes stables	Systèmes distribués complexes

Le monitoring surveille ce que vous savez déjà mesurer. L'observabilité vous permet d'explorer ce que vous n'aviez pas anticipe.

Complementarite

Un système mature combine les deux : monitoring pour les SLO critiques, observabilité pour le diagnostic rapide en production.

Les 3 piliers¶

graph TD
    O["Observabilite"]
    O --> L["Logs\nEvenements textuels\nhorodates"]
    O --> M["Metriques\nValeurs numeriques\ndans le temps"]
    O --> T["Traces\nChemins de requetes\ndistribuees"]
    L --> C["Correlation\nContexte unifie"]
    M --> C
    T --> C

Logs¶

Enregistrements d'événements textuels produits par les applications et systèmes. Ils sont détaillés, contextuels, mais volumineux. Utiles pour comprendre ce qui s'est passe exactement.

Métriques¶

Valeurs numériques agreges dans le temps (counters, gauges, histogrammes). Peu coûteux a stocker, efficaces pour les alertes et tendances. Ne décrivent pas le "pourquoi".

Traces¶

Représentation du chemin complet d'une requête à travers plusieurs services. Indispensables en architecture microservices pour isoler la source d'une latence.

Les Golden Signals¶

Définis par le SRE Book de Google, les quatre signaux dores s'appliquent à tout service expose.

Signal	Définition	Exemple métrique
Latence	Temps de traitement d'une requête	p50, p95, p99 en ms
Trafic	Volume de demandes par unite de temps	req/s, transactions/min
Erreurs	Taux de requêtes en échec	HTTP 5xx / total
Saturation	Degré d'utilisation des ressources	CPU %, queue depth

Latence des erreurs

Mesurez séparément la latence des requêtes en succès et des erreurs. Une erreur rapide peut masquer une dégradation de disponibilité.

Méthode USE¶

La méthode USE (Utilization, Saturation, Errors) s'applique aux ressources matérielles et système.

Composant	Utilization	Saturation	Errors
CPU	% utilisé	run queue length	n/a
Mémoire	% utilisé	swap usage	OOM events
Disque	% IOPS utilisés	io wait	erreurs I/O
Réseau	% bande passante	drop / retransmit	erreurs interface

Commencez par l'utilisation : si elle est faible, la saturation et les erreurs sont rarement le problème.

USE pour l'infra, RED pour les services

La méthode USE diagnostique les ressources. La méthode RED analyse les services. Les deux sont complementaires.

Méthode RED¶

La méthode RED (Rate, Errors, Duration) s'applique aux services et microservices.

Signal	Description	Exemple
Rate	Requêtes par seconde reçues	1200 req/s sur /api/orders
Errors	Proportion de requêtes en échec	0.3% de 5xx
Duration	Distribution de la durée de traitement	p99 < 400ms

RED est particulièrement adapté aux environnements Kubernetes et aux APIs REST/gRPC.

Recapitulatif¶

graph LR
    GS["Golden Signals\n(tout service)"]
    USE["USE Method\n(ressources)"]
    RED["RED Method\n(services)"]
    GS --> USE
    GS --> RED

Choisir la méthode selon le contexte : USE pour analyser un serveur lent, RED pour diagnostiquer un service degradant, Golden Signals pour définir les SLI de base de tout composant.