Centralisation des logs

1) Pourquoi centraliser les logs

• Accélérer la recherche des racines des incidents (corrélation par request-id/trace-id) ;
• permettent de construire des alertes de signalisation sur des symptômes (erreurs, anomalies) ;
• donner une piste de vérification (qui/quand/ce qu'il a fait) ;
• réduire le coût en unifiant la rétraction et le stockage.

2) Principes de base

1. Seuls les logs structurés (JSON/RFC5424) ne sont pas "free-text'sans clés.
2. Schéma de clé unique : 'ts, level, service, bou, region, tenant, trace_id, span_id, request_id, user_id (masked), msg, kv...'.
3. Corrélation par défaut : faites passer le trace_id de gateway aux backends et aux logs.
4. Minimum de bruit : niveaux corrects, échantillonnage, déduplication des répétitions.
5. Sécurité par design : masque PII, RBAC/ABAC, invariabilité.
6. Économie : hot/warm/cold, compression, agrégation, TTL et rehydration.

3) Architectures types

EFK/ELK: (Fluent Bit/Fluentd/Filebeat) → (Kafka — опц.) → (Elasticsearch/OpenSearch) → (Kibana/OpenSearch Dashboards). Recherche et agrégation universelles.
Loki-like (logs-indexation par étiquette) : Promtail/Fluent Bit → Loki → Grafana. Moins cher pour les grands volumes, puissant filtre label + vue linéaire.
Cloud : CloudWatch/Cloud Logging/Log Analytics + exportation vers le stockage à froid (S3/GCS/ADLS) et/ou vers le SIEM.
Data Lake l'approche : шипперы → le dépôt d'objet (parquet/iceberg) → les demandes bon marché analytiques (Athena/BigQuery/Spark) + la couche en ligne (OpenSearch/Loki) pour les derniers N des jours.

Recommandation : pour le prod-oncall garder la couche en ligne (7-14 jours hot) et archivé (mois/années) dans le lac avec la possibilité de rehydrate.

4) Schéma et format des logs (recommandation)

json
{
"ts":"2025-11-01T13:45:12.345Z",
"level":"ERROR",
"service":"payments-api",
"env":"prod",
"region":"eu-central",
"tenant":"tr",
"trace_id":"0af7651916cd43dd8448eb211c80319c",
"span_id":"b7ad6b7169203331",
"request_id":"r-7f2c",
"user_id":"",        // masked
"route":"/v1/payments/charge",
"code":"PSP_TIMEOUT",
"latency_ms":1200,
"msg":"upstream PSP timeout",
"kv":{"provider":"psp-a","attempt":2,"timeout_ms":800}
}

Normes : RFC3339 pour le temps, niveau de l'ensemble 'TRACE/DEBUG/INFO/WARN/ERROR/FATAL', clés en snake_case.

5) Niveaux de logage et d'échantillonnage

DEBUG - seulement dans dev/stage ; en prod par drapeau et avec TTL.
INFO est le cycle de vie des requêtes/événements.
WARN - situations suspectes sans impact sur les SLO.
ERROR/FATAL - impact sur la demande/l'utilisateur.

• rate-limit pour les erreurs répétées (par exemple, 1/seconde/clé).
• tail-sempling des pistes (laisser les logs/trajets complets uniquement pour les « mauvaises » requêtes).
• dynamique : en cas de tempête d'erreurs, réduire les détails, conserver les résumés.

6) Livraison de logs (agents et shippers)

Sur le nœud : Fluent Bit/Filebeat/Promtail collectent stdout fichiers/jurons, font parsing, masquage, tampon.
Files d'attente réseau : Kafka/NATS pour lisser les pics, les retraits et l'organisation.
Fiabilité : backpressure, tampons de disque, confirmations de livraison (at-least-once), index idempotent (hachage-clé).
Filtrage sur le bord : rejet du « bavardage » et des secrets avant d'entrer dans le réseau.

7) Indexation et stockage

Lot temporel (daily/weekly) + par « bou/region/tenant » (via index templates ou labels).

• Hot (SSD, 3-14 jours) : recherche rapide et alertes.
• Warm (HDD/congélateur, 30-90 jours) : parfois à la recherche.
• Cold/Archive (objet, mois/années) : conformité et enquêtes rares.
• Compression et rotation : ILM/ISM (politiques de cycle de vie), gzip/zstd, downsampling (tables d'agrégation).
• Rehydration : chargement temporaire de lots d'archives dans un cluster « chaud » pour enquête.

8) Recherche et analyse : demandes types

Incident : filtre temporel × 'service =...' × 'level> = ERROR' × 'trace _ id'/' request _ id'.
Fournisseurs : 'code : PSP _' et 'kv. provider : psp-a 'avec regroupement par région.
Anomalies : augmentation de la fréquence des messages ou changement des distributions des champs (détecteurs ML, rule-based).
Audit : 'category : audit' + 'actor '/' resource' + résultat.

9) Corrélation avec les métriques et les tracés

Identifiants identiques : 'trace _ id/span _ id'dans les trois signaux (métriques, logs, trajets).
Links des graphiques : saut cliquable du panneau p99 aux logs par 'trace _ id'.
Annotations de version : versions/canaries dans les métriques et les logs pour une liaison rapide.

10) Sécurité, PII et conformité

Classification des champs : PII/secrets/finances - masquer ou supprimer à l'entrée (filtres Fluent Bit/Lua, Re2).
RBAC/ABAC : accès aux index/labels par rôle, row-/field-level-security.
Invariabilité (WORM/append-only) pour l'audit et les exigences réglementaires.
Rétention et « droit à l'oubli » : TTL/suppression par clé, tokenization 'user _ id'.
Signatures/hash : intégrité des journaux critiques (actions admin, paiements).

11) SLO et métriques pipline logs

Livraison : 99. 9 % des événements dans la couche hot ≤ 30-60 secondes.
Pertes : <0. 01 % sur le segment de 24 h (selon les étiquettes de contrôle).
Disponibilité de la recherche : ≥ 99. 9 % en 28 jours.
Latence des requêtes : p95 ≤ 2-5 secondes sur les filtres types.
Coût : $/1M d'événements et $/stockage/Go en couches coupées.

12) Dashboards (minimum)

Pipline santé : entrée/sortie des aiguilles, retrai, remplissage des tampons, lag Kafka.
Erreurs par service/code : top N, tendances, percentiles 'latency _ ms'.
Audit-activité : actions admin, erreurs de fournisseur, accès.
Economie : volume/jour, indice-augmentation, coût par couche, demandes « chères ».

13) Opérations et playbooks

Tempête de logs : activer l'échantillonnage agressif/rate-limit sur l'agent, lever les tampons, transférer temporairement une partie du flux vers warm.
Dérive du schéma : alert pour l'apparition de nouvelles clés/types, début de la négociation du schéma (schema-catalogue).
Recherche lente : reconfiguration des index, augmentation des répliques, analyse des requêtes « lourdes », archivage des anciens lots.
Incident de sécurité : activation immédiate de l'immuabilité, déchargement des artefacts, restriction d'accès par rôle, RCA.

14) FinOps : comment ne pas s'effondrer sur les loges

Enlevez la verbosité : transformez le stacktrace multi-lignes en un champ 'stack'et échantillonnez les répétitions.
Incluez la TTL : différente pour 'bou '/' level '/' category'.
Utilisez Loki/archive + on-demand rehydrate pour un accès rare.
Lots et compression : les lots plus importants sont moins chers, mais suivez la recherche SLA.
Matérialisez des rapports d'analyse fréquents (agrégats quotidiens).

15) Exemples d'outils

Bit Fluent (masquer et envoyer à OpenSearch)

ini
[INPUT]
Name       tail
Path       /var/log/app/.log
Parser      json
Mem_Buf_Limit   256MB

[FILTER]
Name       modify
Match
Remove_key    credit_card, password

[OUTPUT]
Name       es
Host       opensearch.svc
Port       9200
Index       logs-${tag}-${date}
Logstash_Format  On
Suppress_Type_Name On

Nginx access log в JSON с trace_id

nginx log_format json escape=json '{ "ts":"$time_iso8601","remote":"$remote_addr",'
'"method":"$request_method","path":"$uri","status":$status,'
'"bytes":$body_bytes_sent,"ua":"$http_user_agent","trace_id":"$http_trace_id"}';
access_log /var/log/nginx/access.json json;

Politique OpenSearch ILM (hot→warm→delete)

json
{
"policy": {
"phases": {
"hot":  { "actions": { "rollover": { "max_age": "7d", "max_size": "50gb" } } },
"warm": { "min_age": "7d", "actions": { "forcemerge": { "max_num_segments": 1 } } },
"delete":{ "min_age": "90d", "actions": { "delete": {} } }
}
}
}

16) Chèque de mise en œuvre

• Le schéma des champs et les niveaux des logs ont été adoptés ; la corrélation trace/request-id est incluse.
• Les agents (Fluent Bit/Promtail) avec masquage et tampons sont configurés.
• Une couche en ligne (OpenSearch/Loki/Cloud) et une archive (S3/GCS + parquet) ont été sélectionnées.
• Politiques de rétroaction ILM/ISM + hot/warm/cold, processus rehydrate.
• RBAC/ABAC, immuabilité pour l'audit, journal d'accès.
• Dashboards de pipline, alertes de perte/lag/tampons de disque.
• Pleybooks : tempête de loges, dérive du circuit, recherche lente, sécurité-incident.
• Limites financières : $/1M d'événements, quotas pour les demandes « chères ».

17) Anti-modèles

Les logs de texte sans structure → impossible de filtrer et d'agréger.
Stacktrace géant dans INFO → explosion de volume.
L'absence de corrélation → « trépidation » pour tous les services.
Stocker « tout pour toujours » → facture du nuage comme un avion.
Les secrets/PII dans les loges → les risques de conformité.
Les modifications manuelles des index dans la vente → la dérive et les interruptions de recherche prolongées.

18) Résultat

La centralisation des loges est un système, pas une pile. Un schéma standardisé, une corrélation, des shippers sécurisés, un stockage postérieur et des politiques d'accès strictes transforment les logs en un outil puissant pour les SRE, la sécurité et le produit. Les retences correctes et les FinOps conservent le budget, et les SLO pipline et playbooks rendent les enquêtes rapides et reproductibles.