Métriques et surveillance

Types de métriques, méthodes RED et USE, Prometheus, Grafana et comment mesurer le comportement des systèmes distribués.

Que sont les métriques ?

Les métriques sont des valeurs numériques qui représentent l’état ou le comportement d’un système à un instant donné. Contrairement aux logs (qui capturent des événements individuels), les métriques capturent des tendances et permettent de répondre à des questions telles que : « Combien de requêtes par seconde traitons-nous ? » ou « Quelle est la latence du 99e centile ? »

Types de métriques

Counters (compteurs)

Un counter est une valeur qui ne peut que s’incrémenter. Il se réinitialise lorsque le service redémarre.

Usage : Compter des événements cumulatifs.
Exemples : Total des requêtes reçues, total des erreurs, total des messages traités.
Clé : Ce qui est utile n’est pas la valeur absolue mais le taux de variation (requêtes/seconde).

Gauges (jauges)

Une gauge est une valeur qui peut augmenter et diminuer. Elle représente l’état actuel de quelque chose.

Usage : Mesurer des valeurs instantanées.
Exemples : Connexions actives, utilisation de la mémoire, taille de file d’attente, température du CPU.
Clé : Utile pour détecter la saturation et les tendances.

Histograms (histogrammes)

Un histogramme regroupe les observations dans des buckets prédéfinis et calcule des distributions.

Usage : Mesurer des distributions de valeurs, en particulier les latences.
Exemples : Latence des requêtes (p50, p95, p99), taille des payloads.
Clé : Les centiles sont plus utiles que les moyennes — une moyenne de 100 ms peut masquer le fait que 1 % des requêtes prend 5 secondes.

Summaries (résumés)

Similaires aux histogrammes, mais ils calculent les centiles côté client plutôt que côté serveur.

Usage : Lorsque vous avez besoin de centiles exacts sans configurer de buckets.
Compromis : Ils ne peuvent pas être agrégés entre instances, contrairement aux histogrammes.

Méthodes pour choisir les métriques

Méthode RED (pour les services)

La méthode RED se concentre sur des métriques orientées utilisateur pour les services request-driven :

Métrique	Ce qu’elle mesure	Exemple
Rate	Requêtes par seconde	500 req/s
Errors	Taux d’erreurs	0,5 % des requêtes en erreur
Duration	Latence des requêtes	p99 = 200 ms

RED est idéal pour les microservices qui traitent des requêtes HTTP ou gRPC. Si ces trois métriques sont bonnes, le service est probablement en bonne santé.

Méthode USE (pour les ressources)

La méthode USE se concentre sur l’infrastructure et les ressources du système :

Métrique	Ce qu’elle mesure	Exemple
Utilization	Pourcentage d’utilisation de la ressource	CPU à 75 %
Saturation	Travail en file d’attente	50 requêtes en file d’attente
Errors	Erreurs de la ressource	3 erreurs de disque/heure

USE est idéale pour diagnostiquer les problèmes d’infrastructure : CPU, mémoire, disque, réseau, connexions à la base de données.

Combiner RED et USE

En pratique, utilisez les deux méthodes :

RED pour comprendre l’expérience utilisateur et la santé des services.
USE pour comprendre la santé de l’infrastructure sous-jacente.

Prometheus

Prometheus est le standard de facto pour les métriques dans les architectures cloud-native.

Modèle pull

Contrairement à d’autres systèmes qui reçoivent les métriques (push), Prometheus les collecte activement (pull). Chaque service expose un endpoint /metrics que Prometheus interroge périodiquement.

Format des métriques

# HELP http_requests_total Total de requests HTTP recibidas
# TYPE http_requests_total counter
http_requests_total{method="GET",path="/api/orders",status="200"} 15234
http_requests_total{method="POST",path="/api/orders",status="201"} 3421
http_requests_total{method="POST",path="/api/orders",status="500"} 12

PromQL

Prometheus inclut un langage de requête puissant (PromQL) pour analyser les métriques :

# Tasa de requests por segundo en los últimos 5 minutos
rate(http_requests_total[5m])

# Porcentaje de errores
sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

# Latencia del percentil 99
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))

Alertes avec Prometheus

Prometheus s’intègre avec Alertmanager pour définir des règles d’alerte basées sur PromQL :

groups:
  - name: servicio-ordenes
    rules:
      - alert: AltaTasaDeErrores
        expr: rate(http_requests_total{status=~"5.."}[5m]) > 0.05
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Alta tasa de errores en el servicio de órdenes"

Grafana

Grafana est l’outil de visualisation le plus populaire pour les métriques de Prometheus.

Dashboards efficaces

Un bon dashboard Grafana pour un microservice comprend :

Panneau supérieur : Métriques RED (rate, errors, duration) comme indicateurs principaux.
Panneaux de latence : Histogrammes avec centiles p50, p95, p99.
Panneaux de ressources : CPU, mémoire, connexions (métriques USE).
Panneaux de dépendances : Latence et erreurs vers les services downstream.

Variables et templates

Grafana permet de créer des dashboards dynamiques avec des variables :

Sélecteur de service pour réutiliser le même dashboard.
Sélecteur de plage temporelle.
Filtres par instance, méthode HTTP ou endpoint.

Bonnes pratiques

Nomenclature cohérente

Utilisez des conventions claires pour nommer les métriques :

Préfixe avec le nom du service : order_service_requests_total.
Suffixe avec l’unité : _seconds, _bytes, _total.
Labels pour les dimensions : method, status, endpoint.

Cardinalité maîtrisée

Chaque combinaison unique de labels crée une série temporelle. Évitez les labels à forte cardinalité (comme les user IDs ou les request IDs) — ils peuvent faire exploser le stockage de Prometheus.

Métriques métier

Ne vous limitez pas aux métriques techniques. Les métriques métier sont tout aussi précieuses :

Commandes créées par minute.
Paiements réussis vs refusés.
Temps moyen de checkout.

Golden signals

Google définit quatre « golden signals » que tout service devrait surveiller :

Latence : Temps nécessaire pour traiter les requêtes.
Trafic : Volume de requêtes.
Erreurs : Taux de requêtes en échec.
Saturation : À quel point le service est « plein ».

Résumé

Les métriques sont le deuxième pilier de l’observabilité. Alors que les logs vous disent ce qui s’est passé, les métriques vous disent comment le système se porte maintenant et vers où il se dirige. En combinant les méthodes RED et USE avec des outils comme Prometheus et Grafana, vous pouvez construire un système de surveillance qui vous alerte avant que les problèmes n’impactent les utilisateurs.