Observabilité : logs, métriques, tracés

Observabilité : logs, métriques, tracés

1) Pourquoi est-ce nécessaire

• Les métriques sont des agrégats compacts pour le SLI/SLO et l'alerte par symptôme.
• Les traces sont des chaînes causales de requêtes (end-to-end).
• Logs - événements détaillés pour les enquêtes et les audits.

Objectif : RCA rapide, alertes préventives et fiabilité gérable au sein du budget error.

2) Principes de l'architecture

Contexte unique : nous allons partout 'trace _ id', 'span _ id', 'tenant _ id', 'request _ id', 'user _ agent', 'client _ ip _ hash'.
Normes : OpenTelemetry (OTel) pour SDK/agents, format JSON des logs (canonique, avec schéma).
Symptômes> causes : alertique sur les symptômes de l'utilisateur (latence/erreurs) et non sur le CPU.
Communication des signaux : à partir de la métrique → dans les spans (exemplars) → dans des logs spécifiques par 'trace _ id'.
Sécurité et vie privée : masquage des PII dans les logs, cryptage in transit/at rest, journaux d'audit immuables.
Pluralité : Division des espaces de noms/clés/politiques.

3) Taxonomie des signaux et des schémas

3. 1 Métriques

RED (Rate, Errors, Duration) pour les services et USE (Utilisation, Saturation, Errors) pour les infrastructures.
Типы: counter, gauge, histogram/summary. Pour la latence - histogramme avec des buckets fixes.
Exemplars : référence à 'trace _ id' dans les bits « chauds » de l'histogramme.

name: http_server_duration_seconds labels: {service, route, method, code, tenant}
type: histogram buckets: [0. 01, 0. 025, 0. 05, 0. 1, 0. 25, 0. 5, 1, 2, 5]
exemplar: trace_id

3. 2 Traces

Span = opération avec 'name', 'start/end', 'attributes', 'events', 'status'.
W3C Trace Context pour la portabilité.
Sample : basique (head) + dynamique (tail) + règles « d'importance » (erreurs, haute p95).

3. 3 Logs

Seulement un JSON structuré ; niveaux : DEBUG/INFO/WARN/ERROR.
Champs obligatoires : 'ts _ utc', 'level', 'message', 'trace _ id', 'span _ id', 'tenant _ id', 'bou', 'service', 'region', 'host',' labels {} '.
Interdit : secrets, jetons, PAN, mots de passe. PII - Seulement tokenisé/masqué.

json
{"ts":"2025-10-31T12:05:42. 123Z","level":"ERROR","service":"checkout","env":"prod",
"trace_id":"c03c...","span_id":"9ab1...","tenant_id":"t-42","route":"/pay",
"code":502,"msg":"payment gateway timeout","retry":true}

4) Collecte et transport

Les agents/exportateurs (daemonset/sidecar) → un tampon sur le nœud → bus/ingest (TLS/mTLS) → le stockage des signaux.
Exigences : back-pressure, retraits, déduplication, limitation de la cardinalité (labels !), protection contre "log storms'.

Métriques : pull (Prometheus-compatible) ou push via OTLP.
Traces : OTLP/HTTP (gRPC), tail-samplers sur le collecteur.
Logs : collection locale (journald/docker/stdout) → parser → normaliser.

5) Stockage et rétention (tiered)

Métriques : TSDB chauds 7-30 jours (avec downsample), agrégats à plus long terme (90-365 jours).
Traces : 1-7 jours complets, puis aggrégats/spans de services « importants » ; stocker les index par 'service', 'status', 'error'.
Logs : index chaud 7-14 jours, 3-6 mois chaud, archives jusqu'à 1-7 ans (conformité). Audit - WORM.

Optimisation des coûts : downsampling, filtrage DEBUG en vente, quotas de labels, sampling pour les pistes.

6) SLI/SLO, alerte et service

SLI : disponibilité (% des demandes réussies), latence (p95/p99), proportion 5xx, fraîcheur des données, proportion de job réussis.
SLO : cible sur SLI (par exemple 99. 9 % de succès ≤ 400 ms).
Error budget: 0. 1 % « droit à l'erreur » → règles de fichfries/expériences.

• `ALERT HighLatency` если `p99(http_server_duration_seconds{route="/pay"}) > 1s` 5мин.
• `ALERT ErrorRate` если `rate(http_requests_total{code=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0. 02`.
• Silos alertes (CPU/Disk) - seulement comme auxiliaires, sans paging.

7) Corrélation des signaux

La métrique « rouge » est → en cliquant sur exemplar → sur 'trace _ id' → en regardant le span « lent » → en ouvrant les logs par le même 'trace _ id'.
Corrélation avec les versions : attributs 'version', 'image _ sha', 'feature _ flag'.
Pour les données/ETL : 'dataset _ urn', 'run _ id', lien avec lineage (voir article correspondant).

8) Semage et cardinalité

Métriques : on limite les labels (sans 'user _ id', 'session _ id') ; quotas/validation lors de l'enregistrement.
Traçages : combinons head-sample (à l'entrée) et tail-sample (sur le collecteur) avec les règles : « tout ce que 5xx, p99, erreurs - 100 % ».
Logs : niveaux et étranglement ; pour les erreurs récurrentes fréquentes, les événements d'agrégation (clé dedupe).

yaml processors:
tailsampling:
decision_wait: 2s policies:
- type: status_code status_code: ERROR rate_allocation: 1. 0
- type: latency threshold_ms: 900 rate_allocation: 1. 0
- type: probabilistic hash_seed: 42 sampling_percentage: 10

9) Sécurité et vie privée

In Transit/At Rest : cryptage (TLS 1. 3, AEAD, KMS/HSM).
PII/secrets : désinfectants avant expédition, tokenization, masquage.
Accès : ABAC/RBAC en lecture ; séparation des rôles producers/readers/admins.
Audit : journal d'accès invariable aux logs/pistes ; l'exportation est chiffrée.
Pluralité : namespaces/tenant-labels avec des politiciens ; isolation des clés de chiffrement.

10) Profils de configuration (fragments)

yaml global: { scrape_interval: 15s, evaluation_interval: 30s }
scrape_configs:
- job_name: 'app'
static_configs: [{ targets: ['app-1:8080','app-2:8080'] }]
rule_files: ['slo. rules. yaml']

yaml groups:
- name: http_slo rules:
- record: job:http_request_duration_seconds:p99 expr: histogram_quantile(0. 99, sum(rate(http_server_duration_seconds_bucket[5m])) by (le,route))
- alert: HighLatencyP99 expr: job:http_request_duration_seconds:p99{route="/pay"} > 1 for: 5m

python provider = TracerProvider(resource=Resource. create({"service. name":"checkout","service. version":"1. 8. 3"}))
provider. add_span_processor(BatchSpanProcessor(OTLPExporter(endpoint="otel-collector:4317")))
set_tracer_provider(provider)
with tracer. start_as_current_span("pay", attributes={"route":"/pay","tenant":"t-42"}):
business logic pass

python log. info("gw_timeout", extra={"route":"/pay","code":502,"trace_id":get_trace_id()})

11) Données/ETL et streaming

SLI pour les données : fraîcheur (max lag), exhaustivité (rows vs exposition), « qualité » (validateurs/duplicats).
Alert : passe de fenêtre, lag consumer, croissance DLQ.
Corrélation : 'run _ id', 'dataset _ urn', événements lineage ; traces pour les piplines (span par batch/partition).
Kafka/NATS : métriques producteur/consumer, lag/refus ; les traces par headers (c'est-à-dire « traceparent »).

12) Profilage et eBPF (signal dopé)

Les chemins chauds de bas niveau CPU/alloc/IO ; profils par incident.
eBPF-télémétrie (retards réseau, DNS, appels système) avec référence à 'trace _ id '/PID.

13) Tests d'observabilité

Contrat de signal : vérification de l'exportation des métriques/étiquettes/histogrammes à l'IC.
Synthetic probes : scripts RUM/clients simulés pour SLI externes.
Chaos/Fire drills : désactivation des dépendances, dégradation - nous regardons les alertes et les agents de service réagir.
Smoke dans la vente : Vérification post-déportée que les nouveaux endpoints ont des métriques et des traces.

14) Coût et contrôle des volumes

Budgets par signal/commande ; dashboard « cost per signal ».
Cardinalité sous le budget (SLO sur la cardinalité), limites pour les nouveaux labels.
Downsampling, retences par classe de données, archives « froides » et WORM pour l'audit.

15) Exploitation et SLO de la plate-forme d'observation

Plate-forme SLO : 99. 9 % d'ingestes réussies ; retard jusqu'à l'indice des métriques ≤ 30 s, logs ≤ 2 min, pistes ≤ 1 min.
Alerts de la plate-forme : lag d'injection, croissance des drops, erreur de signature/cryptage, débordement des tampons.
DR/HA : multizonalité, réplication, sauvegardes de configues/règles.

16) Chèques-feuilles

• "trace _ id "/" span _ id'est projeté partout ; JSON-logs avec schéma.
• Métriques RED/USE avec histogrammes ; examplar → les pistes.
• Tail-sampling inclus ; règles 5xx/p99 = 100 %.
• Alerte par symptômes + runibooks ; heures silencieuses/anti-flap.
• Désinfectants PII ; Le cryptage en transit ; WORM pour l'audit.
• Retences et budgets sur les volumes/cardinalité.

• Revue mensuelle des alertes (bruit/précision), réglage des seuils.
• Rapport error budget et mesures prises (fichfriz, hardening).
• Vérification des revêtements dashboards/logs/pistes pour les voies critiques.
• Incidents de formation et mise à jour de runbook.

17) Runbook’и

RCA : croissance p99/pay

1. Ouvrir le dashboard RED pour 'checkout'.
2. Passer par exemplar → la route lente → identifier le « span étroit » (par exemple, 'gateway. call`).
3. Ouvrir les logs par 'trace _ id' → voir les délais/retraits.
4. Activer l'indicateur fich de retour/limite RPS, informer les propriétaires de la dépendance.
5. Après stabilisation - RCA, tiquets d'optimisation, test de lecture.

1. SLI « fraîcheur » rouge → la piste de job → échouer étape.

2. Vérifiez le bracelet du courtier/DLQ, erreurs de connecteur.

3. Démarrer reprocess, avertir les consommateurs (BI/produit) via le canal de statut.

18) Erreurs fréquentes

Logs sans schéma et sans 'trace _ id'. Les enquêtes se prolongent.
Alert sur l'infrastructure au lieu des symptômes. Paging va « au lait ».
La cardinalité illimitée des métriques. L'explosion des coûts et l'instabilité.
Toutes les pistes sont 100 %. Cher et inutile ; activez l'échantillonnage intelligent.
PII/secrets dans les loges. Incluez les désinfectants et les listes rouges.
Les fiches muettes. Nouveau code sans métriques/pistes/logs.

19) FAQ

Q : Dois-je garder le texte brut des loges ?
O : Oui, mais avec la rétention et les archives ; pour les alerts et les SLO il y a assez d'agrégats. Audit - dans WORM.

Q : Que choisir pour les pistes - head ou tail sampling ?
R : Combiner : head-probabilistic pour la couverture de base + tail-rules pour les erreurs et les anomalies.

Q : Comment lier métriques et techniques personnalisées ?
O : Via les labels general 'trace _ id' et business ('route', 'tenant', 'plan') ainsi que via les événements produit (conversion) avec corrélation aux tracés.

Q : Comment ne pas se noyer dans les alerts ?
R : Battez par symptômes, entrez une horloge silencieuse, une déduplication, un regroupement, une hiérarchisation par SLO et un propriétaire par défaut pour chaque alert.

• Audit et journaux invariables
• « Cryptage In Transit/At Rest »
• « Gestion des secrets »
• Origine des données (Lineage)
• «Privacy by Design (GDPR)»
• « Garantie de livraison des webhooks »