Chapitre 9
09 - Monitoring & Observabilite
09 - Monitoring & Observabilite
Chapitre 09 : Monitoring & Observabilite
9.1 Introduction au Monitoring et a l'Observabilite
9.1.1 Definitions
Le monitoring consiste a collecter, agreger et analyser des metriques pour verifier l'etat de sante d'un systeme. L'observabilite va plus loin : elle permet de comprendre l'etat interne d'un systeme en examinant ses sorties (metriques, logs, traces).
"L'observabilite, c'est la capacite a repondre a des questions que vous ne saviez pas que vous alliez vous poser." - Charity Majors
9.1.2 Les trois piliers de l'observabilite
- Metriques : Donnees numeriques agregees dans le temps (CPU, memoire, requetes/s)
- Logs : Evenements discrets avec horodatage (erreurs, acces, transactions)
- Traces : Parcours d'une requete a travers les services distribues
9.1.3 Monitoring traditionnel vs Observabilite moderne
| Aspect | Monitoring traditionnel | Observabilite moderne |
|---|---|---|
| Approche | Reactif | Proactif |
| Donnees | Metriques pre-definies | Exploration libre |
| Outils | Nagios, Zabbix | Prometheus, Grafana |
| Culture | "Ca marche ?" | "Pourquoi ca ne marche pas ?" |
9.2 Prometheus
9.2.1 Architecture
Prometheus est un systeme de monitoring et d'alerting open-source. Son architecture repose sur :
- Prometheus Server : Collecte et stocke les metriques
- Exporters : Exposent les metriques des applications tiers
- Alertmanager : Gere les alertes (deduplication, grouping, routing)
- Pushgateway : Pour les metriques de taches ponctuelles
- Service Discovery : Decouvre automatiquement les cibles
9.2.2 Modele de donnees
Prometheus utilise un modele de donnees multi-dimensionnel :
<metric_name>{<label_name>=<label_value>, ...} <value>
Exemple :
http_requests_total{method="GET", endpoint="/api/users", status="200"} 1024
Types de metriques :
- Counter : Valeur cumulative qui ne fait qu'augmenter (requetes, erreurs)
- Gauge : Valeur qui peut monter et descendre (CPU, memoire)
- Histogram : Echantillons observes dans des buckets configurable (latences)
- Summary : Similaire a Histogram mais avec des quantiles calcules cote serveur
9.2.3 Exporters
Les exporters sont des processus qui exposent des metriques au format Prometheus :
Exporters officiels :
node_exporter: Metriques systeme (CPU, RAM, disque, reseau)blackbox_exporter: Monitoring externe (HTTP, HTTPS, TCP, ICMP)windows_exporter: Metriques Windowsmysqld_exporter: Metriques MySQL/MariaDBpostgres_exporter: Metriques PostgreSQL
Exemple de configuration node_exporter :
scrape_configs:
- job_name: 'node'
static_configs:
- targets: ['localhost:9100']
9.2.4 Recording Rules
Les recording rules pre-calculent des expressions complexes periodiquement :
groups:
- name: cpu_rules
interval: 30s
rules:
- record: node:cpu_utilization:ratio
expr: (1 - avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance))
Avantages :
- Requetes plus rapides
- Reduction de la charge de calcul
- Reutilisation des expressions complexes
9.2.5 Alerting Rules
Les alerting rules definissent les conditions de declenchement des alertes :
groups:
- name: infrastructure
rules:
- alert: HighCPUUsage
expr: node:cpu_utilization:ratio > 0.8
for: 5m
labels:
severity: critical
annotations:
summary: "CPU usage > 80% on {{ $labels.instance }}"
description: "CPU usage is at {{ $value | humanizePercentage }}"
9.2.6 Alertmanager
L'Alertmanager gere le routage, le grouping et la deduplication des alertes :
route:
group_by: ['alertname', 'cluster']
group_wait: 30s
group_interval: 5m
repeat_interval: 4h
receiver: 'slack'
routes:
- match:
severity: critical
receiver: 'pagerduty'
receivers:
- name: 'slack'
slack_configs:
- api_url: 'https://hooks.slack.com/services/...'
channel: '#alerts'
- name: 'pagerduty'
pagerduty_configs:
- routing_key: '...'
9.2.7 PromQL (Prometheus Query Language)
PromQL est le langage de requete de Prometheus :
Fonctions de base :
rate(): Taux d'augmentation par seconde pour les countersirate(): Taux instantane (plus sensible au bruit)increase(): Augmentation totale sur une periodeavg_over_time(): Moyenne sur une fenetre temporelle
Exemples de requetes :
# Taux de requetes HTTP par minute
rate(http_requests_total[5m])
# Utilisation CPU moyenne par instance
avg(rate(node_cpu_seconds_total{mode!="idle"}[5m])) by (instance)
# 95e percentile de latence
histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))
# Disponibilite des services
up{job="api-server"}
9.3 Grafana
9.3.1 Architecture
Grafana est une plateforme d'observabilite qui permet de :
- Creer des dashboards interactifs
- Interroger de multiples sources de donnees
- Configurer des alertes visuelles
- Partager des dashboards via des liens ou des exports
9.3.2 Sources de donnees
Grafana supporte de nombreuses sources :
- Prometheus
- InfluxDB
- Elasticsearch
- CloudWatch (AWS)
- Azure Monitor
- Google Cloud Monitoring
- Loki (logs)
- Tempo (traces)
9.3.3 Panels et visualisations
Types de panels :
- Time series : Graphiques lineaires pour les series temporelles
- Stat : Valeur unique avec tendance
- Gauge : Jauge avec seuils
- Bar chart : Diagramme en barres
- Heatmap : Distribution des valeurs dans le temps
- Table : Donnees tabulees
- Logs : Visualisation de logs
9.3.4 Variables et template
Les variables rendent les dashboards dynamiques :
# Definition de variable
name: instance
type: query
query: label_values(node_uname_info, instance)
refresh: On Dashboard Load
# Utilisation dans les queries
rate(node_cpu_seconds_total{mode="idle", instance="$instance"}[5m])
9.3.5 Annotations
Les annotations permettent de superposer des evenements sur les graphiques :
# Annotation evenementielle
{
"time": 1630000000000,
"text": "Deploiement v2.3.1",
"tags": ["deploy", "production"]
}
9.3.6 Provisioning
Le provisioning permet de declarer les dashboards et sources de donnees en YAML :
apiVersion: 1
datasources:
- name: Prometheus
type: prometheus
access: proxy
url: http://prometheus:9090
isDefault: true
9.4 OpenTelemetry
9.4.1 Introduction
OpenTelemetry (OTel) est un standard ouvert pour la collecte de donnees d'observabilite. Il unifie la collection de traces, metriques et logs.
Composants principaux :
- OTel API : Interface de programmation
- OTel SDK : Implementation de reference
- OTel Collector : Agent de collecte et de traitement
- OTel Protocol (OTLP) : Protocole de transport
9.4.2 Traces et Spans
Une trace represente le parcours complet d'une requete. Un span est une unite de travail dans cette trace.
from opentelemetry import trace
tracer = trace.get_tracer(__name__)
with tracer.start_as_current_span("process_order") as span:
span.set_attribute("order.id", "12345")
span.set_attribute("payment.method", "credit_card")
with tracer.start_as_current_span("validate_payment") as child_span:
child_span.set_attribute("amount", 99.99)
# Traitement du paiement
9.4.3 Sampling
Le sampling reduit le volume de traces collectees :
# Sampling base sur la probabilite
sampler:
type: probability
probability: 0.1 # 10% des traces
# Sampling base sur le taux
sampler:
type: rate_limiting
traces_per_second: 10
9.4.4 OTel Collector
Le Collector est un proxy entre les applications et les backend d'observabilite :
receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
http:
endpoint: 0.0.0.0:4318
processors:
batch:
timeout: 1s
send_batch_size: 1024
memory_limiter:
check_interval: 1s
limit_mib: 512
exporters:
prometheus:
endpoint: 0.0.0.0:8889
otlp:
endpoint: jaeger:4317
service:
pipelines:
traces:
receivers: [otlp]
processors: [memory_limiter, batch]
exporters: [otlp]
metrics:
receivers: [otlp]
processors: [memory_limiter, batch]
exporters: [prometheus]
9.5 Solutions SaaS
9.5.1 Datadog
Datadog est une plateforme SaaS de monitoring et de securite.
Caracteristiques cles :
- Infrastructure monitoring : Serveurs, conteneurs, services cloud
- APM : Tracing distribue automatique
- Log Management : Centralisation et analyse de logs
- Synthetics : Tests de disponibilite
- Dashboards : Visualisations pre-construites
Agent Datadog :
# datadog-agent.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: datadog-agent
spec:
template:
spec:
containers:
- name: agent
image: datadog/agent:latest
env:
- name: DD_API_KEY
valueFrom:
secretKeyRef:
name: datadog-secret
key: api-key
- name: DD_SITE
value: datadoghq.eu
5.5.2 New Relic
New Relic est une plateforme d'observabilite basee sur le modele de donnees NRDB.
Caracteristiques cles :
- New Relic APM : Monitoring d'applications
- New Relic Infrastructure : Monitoring d'infrastructure
- New Relic Browser : Monitoring frontend
- NRQL : Langage de requete proprietaire
- AIOps : Detection d'anomalies basee sur le ML
9.6 Methodes d'Observabilite
9.6.1 RED Method (Rate, Errors, Duration)
Developpee par Tom Wilkie, la methode RED s'applique aux services :
| Metrique | Description | Exemple PromQL |
|---|---|---|
| Rate | Debit de requetes | rate(http_requests_total[5m]) |
| Errors | Taux d'erreur | rate(http_requests_total{status=~"5.."}[5m]) |
| Duration | Duree des requetes | histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) |
9.6.2 USE Method (Utilization, Saturation, Errors)
Developpee par Brendan Gregg, la methode USE s'applique aux ressources :
| Metrique | Description | Exemple |
|---|---|---|
| Utilization | % du temps ou la ressource est occupee | CPU a 75% |
| Saturation | Degre de demande supplementaire | File d'attente du disque |
| Errors | Nombre d'erreurs | Erreurs reseau |
9.6.3 Les Four Golden Signals
Issus du livre SRE de Google :
- Latence : Temps necessaire pour traiter une requete
- Traffic : Volume de requetes
- Erreurs : Taux d'echec des requetes
- Saturation : Niveau d'utilisation des ressources
9.7 Alerting et On-Call
9.7.1 Best Practices pour les alertes
Principes fondamentaux :
- Ne pas alerter sur des symptomes sans cause
- Eviter les alertes redondantes
- Definir des seuils avec hysteresis
- Utiliser des alertes de type "dead man's switch"
Structure d'une alerte :
- alert: ServiceDown
expr: up{job="api"} == 0
for: 1m
labels:
severity: critical
team: backend
annotations:
summary: "Le service {{ $labels.job }} est inaccessible"
runbook: "https://runbook.company.com/service-down"
dashboard: "https://grafana.company.com/d/abc"
7.7.2 PagerDuty
PagerDuty est la plateforme de gestion d'incidents la plus utilisee.
Configuration d'integration :
# Alertmanager -> PagerDuty
receivers:
- name: pagerduty-critical
pagerduty_configs:
- routing_key: "your-pagerduty-routing-key"
severity: critical
description: "{{ .GroupLabels.alertname }}"
client: "Prometheus"
client_url: "https://prometheus.company.com"
details:
firing: "{{ .Alerts.Firing | len }}"
resolved: "{{ .Alerts.Resolved | len }}"
9.7.3 OpsGenie
OpsGenie (Atlassian) est une alternative a PagerDuty :
receivers:
- name: opsgenie-critical
opsgenie_configs:
- api_key: "your-opsgenie-api-key"
priority: "P1"
responders:
- type: team
name: "on-call-sre"
tags:
- production
- critical
9.7.4 Gestion des rotations
Exemple de configuration de rotation avec le fichier pagerduty-schedule.yaml :
# Exemple de planning d'astreinte
schedule:
name: "SRE Primary Rotation"
time_zone: "Europe/Paris"
layers:
- name: "Night Shift"
start: "2024-01-01T00:00:00Z"
rotation_virtual_start: "2024-01-01T00:00:00Z"
rotation_turn_length_seconds: 604800 # 1 semaine
users:
- user: "alice@company.com"
- user: "bob@company.com"
- user: "charlie@company.com"
9.8 Travaux Pratiques
TP 1 : Deploiement de Prometheus + Grafana sur Kubernetes
Objectif : Deployer une stack de monitoring complete sur Kubernetes.
Etapes :
- Deployer Prometheus Operator via Helm
- Configurer node_exporter pour tous les nœuds
- Creer des recording rules pour le CPU et la memoire
- Configurer Alertmanager avec Slack
- Deployer Grafana et configurer Prometheus comme datasource
- Importer un dashboard Kubernetes (ID 6411)
- Creer un dashboard personnalise avec 3 panels
Fichiers fournis :
values-prometheus.yamlvalues-grafana.yamldashboard.json
TP 2 : Instrumentation d'une application avec OpenTelemetry
Objectif : Instrumenter une application microservices avec OpenTelemetry.
Etapes :
- Deployer l'application exemple (Python + Go)
- Implementer le tracing distribue avec OTel SDK
- Configurer OTel Collector
- Visualiser les traces dans Jaeger
- Exporter les metriques vers Prometheus
- Creer un dashboard Grafana avec traces et metriques
Fichiers fournis :
app.py(application instrumentee)otel-collector-config.yamldocker-compose.yaml
Resume
- L'observabilite repose sur 3 piliers : metriques, logs, traces
- Prometheus est le standard de facto pour les metriques
- Grafana permet de visualiser et d'alerter
- OpenTelemetry unifie la collecte de donnees d'observabilite
- Les methodes RED et USE guident le choix des metriques
- Les alertes doivent etre actionnables et non bruyantes
- PagerDuty et OpsGenie gerent les rotations d'astreinte