🐶 Partie 4 : Pilier 3 - Log Management (Deep Dive)

Les Métriques (Partie 2) sont des agrégats (ex: "500 erreurs par minute"). Les Logs sont les événements individuels, textuels, qui composent cet agrégat (ex: "Ligne 500: ERROR: Connection refused for user 'admin'").

Le Log Management de DataDog est un service SaaS (similaire à Splunk, ELK/Elastic Stack, ou Grafana Loki) qui s'occupe de :

1. Collecter : Agréger les logs de milliers de sources (fichiers, conteneurs, cloud).
2. Processer (Parser) : Transformer le texte brut ("GET / 200") en données structurées ({method: "GET", path: "/", status: 200}).
3. Indexer : Rendre ces données interrogeables (Search).
4. Corréler : Lier un log à sa Métrique et sa Trace APM (le plus important).

La collecte des logs est (presque) toujours effectuée par l'Agent DataDog. Elle doit d'abord être activée globalement sur l'Agent.

# (datadog.yaml)
logs_enabled: true

# (Variable d'environnement Docker/K8s)
# DD_LOGS_ENABLED="true"
            

Les logs arrivent sous forme de texte brut ("raw"). C'est illisible et inutilisable pour les filtres.
Un Log Pipeline (Pipeline de Traitement) est une série d'étapes (côté DataDog) pour **transformer** ce texte en **JSON structuré**.

Diagramme : Pipeline de Log (Simplifié)

(Log Brut Reçu)
"10.1.2.3 - - [10/Oct/2025:13:55:36] "GET /api/v1/user HTTP/1.1" 200 512"

      |
      ▼
+------------------------------------------------+
| Pipeline (Matching 'source:nginx')             |
+------------------------------------------------+
| 1. Parser (Grok)                               |
| (Extrait "GET", "/api/v1/user", 200)           |
|      |                                         |
|      ▼                                         |
| 2. Remapper (Attributs)                        |
| ('http.status_code' = 200)                     |
| ('http.method' = "GET")                        |
|      |                                         |
|      ▼                                         |
| 3. Create Facets (Indexation)                  |
| (Rendre '@http.status_code' filtrable)         |
+------------------------------------------------+
      |
      ▼
(Log Structuré (JSON))
{
  "message": "10.1.2.3 - ...",
  "http": {
    "status_code": 200,
    "method": "GET",
    "url_path": "/api/v1/user"
  },
  "service": "frontend-web",
  ...
}
            

La Règle d'Or : Si vous le pouvez, loguez en JSON !

C'est un concept clé de DataDog (et source de confusion).

• Attribut (JSON) : Une donnée extraite du log (ex: user.id: 123). Elle est stockée (visible dans le JSON du log), mais on ne peut pas filtrer (@user.id:123) ou grouper dessus (group by @user.id).
• Facet (Facette) : Un attribut que vous avez **promu** (dans l'UI DataDog) pour être **indexé**. Permet le filtrage, le GROUP BY, et la recherche.

Les tags (env, service, host) et les attributs clés (status, source) sont des Facets par défaut. Vous devez manuellement créer des Facets pour vos attributs custom (ex: user.id, cart.id) pour pouvoir les utiliser dans les recherches (4.7) ou les dashboards.

C'est l'interface (UI) pour rechercher, filtrer et analyser les logs structurés. La recherche est basée sur le "full-text" et les Facets (@).

DataDog utilise le ML "on-the-fly" pour regrouper les logs similaires. Au lieu de voir 1 million de lignes :

INFO: User 123 failed login (IP: 1.2.3.4)
INFO: User 456 failed login (IP: 5.6.7.8)
INFO: User 101 failed login (IP: 9.0.1.2)
... (1 million de fois)
            

L'onglet "Patterns" vous montrera :

INFO: User {*} failed login (IP: {*})    (Count: 1,000,000)
            

C'est vital pour détecter une "explosion" d'un nouveau type d'erreur (ex: FATAL: Cannot connect to DB {*}).

C'est la fonctionnalité la plus puissante, qui justifie d'avoir APM (Traces) et Logs dans la même plateforme.

Comme vu en Partie 3 (APM), si dd-trace (APM) est activé, il **injecte automatiquement** le trace_id et span_id actuels dans vos logs (s'ils sont en JSON, ou via DD_LOGS_INJECTION=true).

Exemple (Log Python JSON)

{
  "timestamp": "2024-10-27T10:30:05Z",
  "level": "ERROR",
  "message": "Payment failed for user 123",
  "service": "api-payment",
  
  // (Injecté par dd-trace)
  "dd": {
    "trace_id": "4567890123456",
    "span_id": "9876543210987"
  }
}
            

Résultat (Pivot) :
1. (Vue "Trace" -> "Logs") : Vous regardez un Flame Graph (Trace APM) d'une requête /checkout lente. L'onglet "Logs" vous montre uniquement les logs (y compris l'erreur "Payment failed") de *cette requête précise*.
2. (Vue "Log" -> "Trace") : Vous trouvez ce Log d'erreur. Vous cliquez sur le trace_id. DataDog vous amène au Flame Graph complet, vous montrant ce qui s'est passé *avant* et *après* l'erreur.

Les Logs coûtent cher à indexer (Haute ingestion, haute rétention).

Log-based Metrics (Métriques basées sur les Logs)

Vous ne voulez peut-être pas *indexer* 1 Milliard de logs NGINX (status:200), mais vous voulez *compter* combien il y en a (une Métrique).
Vous pouvez créer une "Log-based Metric" : DataDog scanne le log à l'ingestion, incrémente un compteur (nginx.hits {status:200}), puis (optionnellement) jette le log (s'il est configuré pour ne pas être indexé). C'est beaucoup moins cher.

Archiving (Archivage) & Rehydrating (Réhydratation)

Garder les logs "Hot" (indexés, interrogeables) coûte cher (ex: rétention 15 jours).
Vous pouvez (vous devez) **Archiver** (Archiving) tous vos logs (bruts) vers un stockage "Froid" (Cold Storage) (ex: Amazon S3, Google GCS). C'est peu coûteux.
Si vous avez besoin d'enquêter (ex: audit 6 mois plus tard), vous utilisez **Rehydrate from Archive** (Réhydrater) pour ré-importer les logs de S3 vers DataDog (Log Explorer).