45 lines
1.4 KiB
Markdown
45 lines
1.4 KiB
Markdown
---
|
|
title: Observabilité
|
|
created: 2026-06-06
|
|
updated: 2026-06-06
|
|
type: concept
|
|
tags: [devops, tech, monitoring]
|
|
confidence: high
|
|
contested: false
|
|
sources: [synthesized]
|
|
---
|
|
# 👀 Observabilité
|
|
|
|
## Définition Courte
|
|
Capacité à comprendre l'état interne d'un système à partir de ses **outputs externes** (logs, métriques, traces). Va au-delà du simple monitoring.
|
|
|
|
## Explication Détaillée
|
|
Les 3 piliers :
|
|
- **Logs** : événements discrets horodatés. (Loki, Elastic, Splunk).
|
|
- **Métriques** : valeurs numériques agrégées dans le temps. (Prometheus, InfluxDB, Datadog).
|
|
- **Traces** : parcours d'une requête à travers les services. (Jaeger, Tempo, Zipkin).
|
|
|
|
L'observabilité permet de répondre à des questions **inconnues à l'avance** ("pourquoi ce service est-il lent sur ce chemin ?"), là où le monitoring répond à des questions connues ("le CPU est-il à 80% ?").
|
|
|
|
## Cas d'Usage
|
|
- Microservices distribués.
|
|
- Debugging en production sans reproduction locale.
|
|
- Détection d'anomalies.
|
|
|
|
## Outils Liés
|
|
- **Pile Grafana** : Loki + Prometheus + Tempo + Grafana.
|
|
- **Datadog**, **New Relic** (SaaS).
|
|
- **OpenTelemetry** : standard d'instrumentation.
|
|
|
|
## Pages Liées
|
|
- [[checklist-monitoring-minimal]]
|
|
- [[ci-cd]]
|
|
- [[architecture-microservices]]
|
|
|
|
## Questions Ouvertes
|
|
- Comment instrumenter du code legacy sans tout réécrire ?
|
|
- Logs vs métriques vs traces : quand utiliser quoi ?
|
|
|
|
## Liens
|
|
- [[monitoring-solo-dev]]
|