Logs et traces¶

Structured logging, centralisation, traces distribuées et OpenTelemetry.

Structured logging¶

Le logging structure consiste à produire des logs en format machine-readable (JSON) plutôt que du texte libre.

Texte vs JSON¶

Champs standards recommandes¶

Centralisation des logs¶

graph LR
    A["Application A"] --> AG["Agent\n(Fluentd / Vector)"]
    B["Application B"] --> AG
    C["Systeme / OS"] --> AG
    AG --> AGG["Agregateur\n(Loki / Elasticsearch)"]
    AGG --> ST["Stockage\n(S3 / disque)"]
    AGG --> Q["Requetes\n(Grafana / Kibana)"]
    Q --> OP["Operateurs"]

Stacks de centralisation des logs¶

Traces distribuées¶

Une trace représenté le chemin complet d'une requête à travers plusieurs services.

Concepts¶

Propagation de contexte¶

Le contexte de trace se propagé via des headers HTTP standardises (W3C Trace Context) :

• traceparent : identifiant de trace et span courant
• tracestate : données vendeur spécifiques

Sans propagation correcte, les spans de différents services ne peuvent pas être assembles en trace cohérente.

OpenTelemetry¶

OpenTelemetry (OTel) est le standard CNCF unifiant la collecte de logs, métriques et traces.

Architecture¶

Avantages¶

• Un seul SDK par langage pour les 3 signaux (logs, métriques, traces)
• Vendor-neutral : exporter vers Jaeger, Zipkin, Prometheus, Datadog...
• Auto-instrumentation disponible pour les frameworks majeurs
• Standard CNCF avec adoption massive

Correlation logs / métriques / traces¶

La vraie valeur de l'observabilité vient de la correlation entre les 3 piliers.

Correlation pratique¶

• Ajouter le trace_id dans les logs permet de passer d'un log à la trace complète en un clic
• Grafana permet de naviguer entre Loki (logs), Prometheus (métriques) et Tempo (traces) avec un identifiant commun

Outils¶