Baselines et métriques¶

Établir des baselines de performance, identifier les patterns de charge et collecter les données utiles.

Qu'est-ce qu'une baseline¶

Une baseline est une mesure de référence établie sur une periode representative du comportement normal du système. Elle sert de point de comparaison pour détecter les anomalies et valider les projections futures.

Caractéristiques d'une bonne baseline¶

Periode representative : 2 a 4 semaines minimum, couvrant au moins un cycle complet
Granularité adequate : données a 1 minute pour l'exploitation, 5 minutes pour les tendances
Multi-dimensionnelle : CPU, RAM, IOPS, réseau, métriques applicatives (req/s, latence, erreurs)
Contextuelle : annotee avec les événements métier (campagnes, jours feries, releases)

Baseline sans contexte business = baseline inutile

Une baseline technique detachee du contexte métier ne permet pas de distinguer un pic normal (fin de mois, soldes) d'une anomalie a investiguer. Toujours annoter les periodes avec les événements business correspondants.

Comment établir une baseline¶

gantt
    title Etablissement d'une baseline (4 semaines)
    dateFormat  YYYY-MM-DD
    section Collecte
    Activation monitoring       :done, a1, 2024-01-01, 3d
    Collecte semaine 1          :done, a2, 2024-01-04, 7d
    Collecte semaine 2          :done, a3, 2024-01-11, 7d
    Collecte semaine 3          :active, a4, 2024-01-18, 7d
    Collecte semaine 4          :a5, 2024-01-25, 7d
    section Analyse
    Identification patterns     :a6, 2024-01-25, 3d
    Annotation evenements       :a7, 2024-01-28, 2d
    Validation baseline         :a8, 2024-01-30, 2d

Étapes pratiques¶

Vérifier que tous les agents de collecte sont actifs et que la rétention est suffisante
Identifier les cycles métier : jour ouvre, weekend, fin de mois, periode de soldes
Laisser tourner la collecte sans intervention majeure sur l'infrastructure
Annoter les événements exceptionnels (migration, incident, campagne marketing)
Exclure les periodes anormales de la baseline (incident majeur, migration en cours)

Patterns de charge¶

Les patterns de charge sont les variations rythmiques et prévisibles de la demande.

Saisonnalite¶

Cycle	Exemples	Impact sur le dimensionnement
Journalier	Pic 9h-11h / 14h-16h, creux nuit	Scaling schedule ou auto-scaling
Hebdomadaire	Lundi fort, weekend faible	Ressources reducibles le week-end
Mensuel	Fin de mois (paie, facturation)	Headroom supplémentaire J-3/J+3
Annuel	Soldes, Black Friday, periode fiscale	Pre-scaling planifie

Pics prévisibles vs imprévisibles¶

Prévisibles : événements métier connus, scaling planifiable à l'avance
Imprévisibles : viraux, incidents partenaires, attaques — exigent headroom structurel
Semi-prévisibles : campagnes dont la date est connue mais l'amplitude incertaine

Métriques de saturation¶

La saturation est plus informative que la simple utilisation.

Ressource	Métrique d'utilisation	Métrique de saturation
CPU	`cpu_usage_percent`	Run queue length, load average / nb CPU
RAM	`mem_used_percent`	Swap utilisé, OOM events
Disque	`disk_used_percent`	Disk queue depth, await (ms)
Réseau	`net_bytes_sent/recv`	Retransmissions TCP, drops
Base de données	Connexions actives	Connexions en attente, deadlocks

Load average mal interprété

Un load average de 4.0 sur une machine 8 CPU = 50 % d'utilisation (acceptable). Le même load average sur une machine 2 CPU = saturation (urgent). Toujours normaliser par le nombre de CPU.

Collecte de données¶

Outils de collecte¶

Outil	Type	Points forts
Prometheus + exporters	Pull, open source	Écosystème riche, PromQL puissant
collectd	Push, agent léger	Faible empreinte, protocoles varies
Telegraf	Push/Pull, agent	Integrations nombreuses, TICK stack
CloudWatch (AWS)	Natif cloud	Zero config sur EC2/RDS/ELB
Azure Monitor	Natif cloud	Intégration native ARM
OpenTelemetry	Standard ouvert	Vendor-neutral, traces + métriques

Granularité et rétention¶

Horizon	Granularité recommandee	Rétention
Exploitation temps réel	15-60 secondes	15 jours
Analyse quotidienne	1-5 minutes	3 mois
Tendances mensuelles	1 heure	2 ans
Projections annuelles	1 jour	5 ans

Downsample pour réduire les coûts de stockage

Les données à haute granularité sont coûteuses a stocker sur le long terme. Configurer une politique de downsample : garder 15s pendant 2 semaines, puis agréger en 5 minutes pour 3 mois, puis en 1 heure pour le reste.

Points clés¶

Une baseline couvre au moins 2-4 semaines pour capturer tous les cycles recurrents
La saisonnalite est prévisible et doit être intégrée dans le dimensionnement
Les métriques de saturation (queue depth, swap, retransmissions) sont plus pertinentes que les simples pourcentages
La granularité et la rétention des données doivent être adaptées à l'horizon d'analyse