Observability и trace sampling

1) Pourquoi Observability

• Les métriques (agrégats, réagissent rapidement) ;
• Logs (détails et forensisme) ;
• Tracés (causalité de bout en bout) ;
• Profiles (CPU/heap/lock content en mode prod).

Clé : corrélation entre signaux + économie de télémétrie (samplage, rétentions, compression).

2) Carte des signaux et principes

2. 1 RED/USE

RED (pour API) : Taux (RPS), Errors (% 5xx/4xx importants), Durée (p50/p95/p99).
USE (pour les ressources) : Utilisation, Saturation, Errors (NIC, CPU, disque, files d'attente).

2. 2 Invariants du produit

Définissez un SLO (par exemple, "p95 latence "/v1/payments" ≤ 300 ms, budget erroné 0. 5 % sur 30 jours"). Les alertes ne doivent « crier » qu'en cas de violation du SLO ou de sa combustion.

2. 3 Contexte

Mettez en œuvre le W3C Trace Context ('traceparent', 'tracestate') et le baggage pour transférer en toute sécurité les attributs/affaires (par exemple, 'tenant', 'région', sans PII).

3) Architecture d'observabilité

SDK/auto-instrumentation : OpenTelemetry (OTel) dans les services (HTTP/gRPC/DB/clients).
OTel Collector en tant que pneumatique : réception → enrichissement → semplation → exportation (Prometheus, Tempo/Jaeger, Loki/ELK, ClickHouse).

• Métriques : Prometheus/Mimir/VictoriaMetrics ;
• Tracés : Tempo/Jaeger/Zipkin ;
• Logs : Stockage Loki/ELK/Vector→S3+deshevoye ;
• Profiles : Pyroscope/Parca.
• Corrélation : graphes de services, exemples, passage d'un graphique p99 à un tracé spécifique.

4) Sample tracing : stratégies

4. 1 sampling à base de tête (à l'entrée, avant la connaissance du résultat)

Implémentation simple et bon marché (en SDK/ingress).
Inconvénients : peut manquer des erreurs rares/lenteur des demandes.

Quand : des RPA élevés, des budgets stricts, une part prévisible est nécessaire (par exemple, 1-5 %).

4. 2 Tail-based sampling (à la sortie, connaissant le résultat)

La décision est prise par Collector une fois le span terminé.
Vous pouvez être sûr de prendre des anomalies : erreurs, p99, routes spécifiques/tenants.
Inconvénients : Tamponnage, plus difficile et plus cher.

Quand : besoin de trajets « significatifs » à un coût modéré.

4. 3 Modèle combiné

Tête globale 1-5 %, plus règles de tail : « toujours garder les erreurs/slow-spans », « samper 50 % du trafic canary », « garder toutes les trajets des chemins de paiement en cas d'incident ».

5) Sample dynamique et budget de télémétrie

Budget-aware : retenir le volume de ≤ N trajets/min ; en cas de dépassement - augmenter les seuils (par exemple, sélectionner seulement p99. 5+, error-only).
Rules by route/tenant : endpoints/tenants importants - avec une plus grande proportion.
Fenêtres adaptatives : les surtensions → augmenter temporairement la proportion d'erreurs/lenteurs.
Baisse de cardinalité : normaliser l'agent utilisateur, IP/ASN, squash stack traces, masquer les secrets.

6) Configi (référents)

6. 1 Collecteur de télémétrie ouverte - tail-sampling (yaml-fragment)

yaml receivers:
otlp: { protocols: { http: {}, grpc: {} } }

processors:
batch: { send_batch_size: 8192, timeout: 2s }
tail_sampling:
decision_wait: 5s num_traces: 100000 expected_new_traces_per_sec: 5000 policies:
- name: always-error type: status_code status_code: { status_codes: [ERROR] }
- name: slow-endpoints type: latency latency: { threshold_ms: 300 }      # p95 цель
- name: important-routes type: string_attribute string_attribute: { key: http. target, values: ["/v1/payments", "/v1/payouts"] }
- name: tenant-eu1 type: string_attribute string_attribute: { key: tenant, values: ["eu-1"] }
- name: probabilistic-default type: probabilistic probabilistic: { sampling_percentage: 5. 0 }

exporters:
otlphttp/tempo: { endpoint: http://tempo:4318 }
prometheus: { endpoint: "0. 0. 0. 0:9464" }

service:
pipelines:
traces:
receivers: [otlp]
processors: [batch, tail_sampling]
exporters: [otlphttp/tempo]

6. 2 Prometheus - examplars (fragment)

Dans l'application, lorsque vous écrivez des histogrammes, ajoutez des exemples avec 'trace _ id'. À Grafana, les clics des aiguilles conduisent à la traînée.

yaml scrape_configs:
- job_name: api scrape_interval: 10s honor_labels: true static_configs: [{ targets: ["api:9100"] }]
exemplar_limit: 10

6. 3 Loki - réduction du coût des loges

Les étiquettes sont seulement stables ('service', 'bou', 'région', 'route _ class').
La cardinalité élevée (request_id, user_id) est dans payload, mais avec redaction.
Sampliquez les info-logs « réussis », conservez toutes les erreurs/alertes.

6. 4 Jaeger/Tempo - rétention et index

Gardez les remorques crues 3-7 jours, les agrégats/symétries - plus longtemps.
Incluez parquet/blocks dans le stockage bon marché (compatible S3), les index sont compacts.

7) Simulation de tracing

7. 1 Noms et attributs

`service. name`, `service. version`, `deployment. environment`.
`http. method`, `http. route`, `http. target`, `http. status_code`, `net. peer. name`.
Attributs métiers sans PII : 'tenant', 'region', 'payment _ provider', 'game _ id'.

7. 2 Événements et liens

Span events : points importants (début de la transaction DB, rétrospective, circuit ouvert, cache miss).
Liens : Communication zapros→vebkhuk/sobytiye ; utile pour EDA et outbox/inbox.

7. 3 instances (exemples)

Ajoutez aux histogrammes latency/size des exemples avec 'trace _ id' : navigation « de la métrique → à la trace » en un clic.

8) Métriques : lesquelles et comment

8. 1 Technique

RED par itinéraire/tenants/fournisseurs (PSP, KYC).
Пулы: `db_connections_in_use`, `http_client_in_flight`, `queue_depth`.
Stabilisation : retries, timeouts, circuit ouvert/half-open, rate-limit hits.
Go/Java/Python runtime : pauses GC, heap, safepoints, retards GIL.

8. 2 Mesures d'entreprise

Inscriptions/logins/dépôts/retraits, conversions, échecs de 3DS/KYC, chargeback-ratio.
Fiches importantes : time-to-wallet, success-rate payout.

8. 3 Cardinalité et stockage

Histogrammes avec buckets explicites (par exemple, '[50,100,200,300,500,1000,2000] ms').
Éviter les étiquettes à haute cardinalité (raw user_id, request_id) - porter dans les logs/trajets.

9) Logs : Normes et corrélation

Format : JSON + clés nécessaires ('timestamp', 'level', 'message', 'trace _ id', 'span _ id', 'service', 'bou').
Edition : Masquer PAN, tokens, PII.
Sempling : 100 % pour 'error/warn', 5-20 % pour 'info' sur les chemins « bruyants ».
L'ancrage aux remorques est via 'trace _ id'. Les lignes de journal → « pivot » dans la trace et vice versa.

10) Profilage en vente

Inclure le profilage continu (Pyroscope/Parca) pour le CPU/heap/alloc/locks.
Corréler les pics p99 avec les piles chaudes ; garder 7-14 jours.

11) Alerting par SLO/budget erroné

SLO-alertes : « un budget erroné est dépensé plus vite que X %/heure » (alertes prédictives).
Symptômes, pas de cause : alerter sur le niveau du client (RUM/edge ou peer routh) plutôt que sur le CPU.
Taux multi-fenêtre, multi-burn : 2 % pour 1 h et 5 % pour 6 h - deux conditions.
Silence dans les dégradations planifiées : décalage des seuils dans les drapeaux de fiche/canari.

12) Coût et rétention

Quotas de volume : tracés ≤ N TB/mes, logs - chaud 3-7 jours, froid S3 30-90 jours, métriques - downsampling (1 min → 5 min → 1 h).
Tail-rules réduisent le volume × 10 - × 100, tout en conservant les erreurs/lenteurs.
Signaux dont le coût est le plus faible - métriques ; avec la plus grande valeur - les trails et les profiles « corrects ».

13) Anti-modèles

« 100 % remorques toujours » → l'explosion du coût, du bruit et des freins.
Logs en format libre sans clés/masquage.
Métriques avec des labels infinis (user_id/ip/full UA).
Non « traceparent »/« baggage » - la corollation est impossible.
Alert sur le CPU/heap au lieu de SLO - le chat « brûle » sans avantages.
Sample « random 1 % » sans priorité d'erreur/slow - vous perdez des cas précieux.

14) Exemples de dashboards (squelettes)

API Aperçu : RPS, taux d'erreur par classe, latency p95/p99 (implars cliquables), top roots.
Release/Canary : comparaison des métriques de l'ancienne/nouvelle version, outlier-rate, open-circuits, retries.
PSP/KYC : taux de réussite par fournisseur, latence et échec, corrélation avec les erreurs payout.
Infra : Utilisation des ressources, saturation des files d'attente, drops réseau.

15) Spécificités iGaming/Finance

Voies critiques (dépôts/conclusions) : Tracing à 100 % uniquement en cas d'incidents ou de fenêtres restreintes ; en mode normal - tail « tout avec erreur/latence longue ».
Région/tenant : ajouter 'tenant', 'jurisdiction', 'brand' au baggage ; construire un SLO par juridiction.
Antifrod/bot filtre : métriques et tracés des solutions d'API Risk (allow/deny/challenge), challenge-pass-rate, velocity-hits.
Audit/conformité : conserver le minimum nécessaire, sans PII ; Les journaux immuables sont dans un circuit distinct.

16) Chèque-liste prod-prêt

• Propagande de bout en bout (« traceparent », « baggage »), corrélation logs/métriques/tracés.
• Collecteur OTel avec tail-sampling (erreurs/slow/routes importantes) + défaut probabiliste.
• Métriques RED/USE, buckets explicites, explars → transition vers la piste.
• SLO et alerte sur le budget erroné (deux échelles de temps).
• Règlement sur la retraite et budget de télémétrie ; downsampling métriques ; cold storage pour les logs.
• Journal JSON normalisé, redaction PII/secrets.
• Le profilage dans la vente est inclus ; Dashboard des staks « chauds » sur l'incident.
• Dashboards canariens et comparaison des versions ; émission sans « zones aveugles ».
• Runbook : Comment augmenter temporairement la part de samplation dans un incident.
• Documentation sur le neuming des attributs/étiquettes et interdiction de la haute cardinalité.

17) TL; DR

Construisez l'observabilité autour de la corrélation : métriques RED/USE → examplars → tracés → logis/profiles. Gérer le coût grâce à un sample combiné : petites règles de tête % + tail (erreurs, lenteurs, itinéraires importants/tenants). Alert - par SLO et budget des erreurs. Gardez les rétentions et la cardinalité sous contrôle, utilisez OTel Collector comme « système nerveux central ». Pour les voies de paiement/juridiction - télémétrie prioritaire et hygiène stricte des données.