Cas avances¶
AIOps, SLO-based alerting, observabilité CI/CD et maîtrise des coûts.
AIOps et anomaly détection¶
L'AIOps applique le machine learning aux données opérationnelles pour détecter des anomalies sans seuils manuels.
Cas d'usage¶
| Cas | Description | Limite |
|---|---|---|
| Anomaly détection sur métriques | Détection de comportements anormaux sans seuil fixe | Faux positifs en periode de changement |
| Correlation automatique | Relier des alertes liees a une même cause racine | Nécessité historique suffisant |
| Forecasting | Prédire l'épuisement d'une ressource (disque, quota) | Efficace surtout sur patterns réguliers |
| Root cause analysis | Suggérer la cause probable d'un incident | Aide, ne remplacé pas l'expertise humaine |
Limites de l'AIOps¶
- Un modèle entraîné sur l'historique ne connait pas les changements futurs d'architecture
- Les "anomalies" détectées peuvent être des comportements voulus (campagne marketing, batch mensuel)
- L'explicabilite reste faible : "le ML dit que c'est anormal" n'est pas un runbook
- Nécessité un volume de données suffisant pour être pertinent
AIOps ne remplacé pas les fondamentaux
Sans SLO bien définis et alerting actionnable de base, l'AIOps ajoute de la complexité sans valeur. Commencez par les bases, ajoutez l'intelligence après.
SLO-based alerting¶
Le SLO-based alerting alerte sur la consommation du budget d'erreur plutôt que sur des seuils statiques.
Alerting classique vs SLO-based¶
graph TD
I["Incident en cours"]
I --> CL{"Alerting\nclassique"}
I --> SB{"SLO-based\nalerting"}
CL -- "seuil fixe depasse" --> AL1["Alerte immediate\nmeme si budget intact"]
SB -- "burn rate eleve" --> AL2["Alerte si SLO en danger\nconsommation acceleree"]
AL1 --> FP["Faux positifs\npossibles"]
AL2 --> PR["Pertinence\ngarantie"]Burn rate¶
Le burn rate mesure la vitesse de consommation du budget d'erreur.
| Burn rate | Interpretation | Action |
|---|---|---|
| 1x | Consommation normale | Aucune |
| 5x | Budget épuisé en 6 jours | Warning |
| 14x | Budget épuisé en 1 heure | Critical immédiate |
Alertes multi-fenêtres¶
La méthode recommandee utilise deux fenêtres pour éviter les faux positifs :
- Fenêtre courte (1h) + fenêtre longue (6h) : doit franchir les deux seuils
- Réduit les alertes transitoires tout en garantissant la détection rapide
Observabilité CI/CD¶
Appliquer les principes d'observabilité au pipeline de livraison lui-même.
Métriques de pipeline¶
| Métrique | Définition | Usage |
|---|---|---|
| Build duration | Temps moyen de build | Détecter les régressions de performance CI |
| Test pass rate | Taux de réussite des tests | Qualité du code |
| Deployment frequency | Fréquence des deployments | Métrique DORA |
| Lead time | Commit → production | Métrique DORA |
| Change failure rate | % deploys causant un incident | Métrique DORA |
| MTTR | Temps moyen de restauration | Métrique DORA |
Annotations de déploiement¶
Marquer chaque déploiement sur les dashboards de monitoring permet de corr'eler immédiatement une anomalie avec un changement récent. Grafana supporte nativement les annotations depuis diverses sources (ArgoCD, GitHub Actions, Flux).
Coûts et rétention¶
La collecte de télémétrie a un coût qui peut devenir significatif sans gouvernance.
Cardinalite des métriques Prometheus¶
Cardinalite : premier poste de coût Prometheus
Chaque combinaison unique de labels crée une serie temporelle. Un label user_id sur une métrique peut générer des millions de series et faire exploser la mémoire Prometheus. N'utilisez jamais de valeurs à haute cardinalite comme labels.
| Bonne pratique | Description |
|---|---|
| Éviter les labels à haute cardinalite | Pas de user_id, request_id, UUID comme labels |
| Limiter les labels par métrique | Généralement < 5 labels |
| Auditer régulièrement | Identifier les series inutilisees |
| Utiliser des recording rules | Pre-agrégation pour les requêtes fréquentes |
Sampling des traces¶
Collecter 100% des traces est coûteux. Le sampling permet de réduire le volume.
| Stratégie | Description | Usage |
|---|---|---|
| Head-based sampling | Décision à l'entree de la requête | Simple, perd les traces d'erreur |
| Tail-based sampling | Décision après la fin de la trace | Conserve les erreurs, plus complexe |
| Rate limiting | N traces par seconde maximum | Contrôle du coût |
Rétention par type de donnée¶
| Type | Rétention typique | Remarques |
|---|---|---|
| Métriques haute résolution | 15-30 jours | Downsampling après |
| Métriques downsamplee | 1-2 ans | Tendances longues |
| Logs applicatifs | 30-90 jours | Selon compliance |
| Logs sécurité | 1-7 ans | Exigences reglementaires |
| Traces | 3-15 jours | Volume élevé, coût important |
Recapitulatif des cas avances¶
| Technique | Maturité requise | Apport |
|---|---|---|
| SLO-based alerting | SLO bien définis | Alertes plus pertinentes |
| Anomaly détection | Historique stable > 3 mois | Moins de seuils manuels |
| Métriques DORA | CI/CD instrumente | Mesure de la velocite livraison |
| Tail-based sampling | OTel Collector déployé | Réduction coût traces |
| Recording rules | Prometheus en production | Performance requêtes |