Distributed Tracing

（部分： 技術和基礎設施）

簡短摘要

分布式跟蹤提供了以下問題的答案：通過網關，API，隊列，DB，外部提供商（PSP/遊戲工作室）的請求路徑在何處以及為何浪費時間。OpenTelemetry（OTel）是開放的SDK/Agent/協議標準，結合了預告片，度量和日誌。在iGaming中，它是保持p95/p99，快速本地化支付問題並在高峰錦標賽之前識別「瓶頸」的基本工具。

1） OTel概念

Trace-完整的交易路徑（存款、出價、出價）。
Span-工作區（HTTP-handler、SQL查詢、隊列/提供程序調用）。

Attributes是具有零件（'net。peer.name`, `db.system`, `psp.route`).

事件-即時事件（轉發、定時、緩存錯誤）。
鏈接是與其他軌道的連接（對於async/queue至關重要）。

資源-流程元數據： '服務。name`, `service.version`, `deployment.environment`, `cloud.region`.

2）上下文的宣傳

traceparent: 00-<trace_id>-<span_id>-01 tracestate:...

另外-對於安全鑰匙（例如「tenant」，「route」），不要將PII放在那裏。

在哪裏刺穿上下文：API網關→內部RPC →生產者排隊→用戶→外部HTTP（PSP/提供商）。

3）語義約定（強制性最低限度）

HTTP/RPC: `http.method`, `http.route`, `http.status_code`.

DB/緩存： 'db。system` (`mysql`/`postgresql`/`redis`), `db.statement「（偽裝），」db。operation`.

隊列： 'messaging。system` (`kafka`/`rabbitmq`), `messaging.destination`, `messaging.operation` (`send`/`process`).

付款：'psp。route`, `psp.provider`, `payment.id'（化名），'amount'，'currency'。

iGaming域： '遊戲。provider`, `game.session_id` (hash), `player.id_hash`.

單一分類法→ dashbords的可比性和快速的原因搜索。

4）Sampling： 如何不淹死在數據中

基於頭部（在查詢輸入處）

簡單，便宜；適合一般流動。
減-您可以丟失「有趣」的緩慢/錯誤的軌道。

Tail-based (в Collector)

該決定是在完成後做出的：我們只保留錯誤/緩慢/重要部分（VIP/付款）。
非常適合prod負荷：在高信息性的情況下,大幅降低成本。

• Head： 5-10%用於「背景」覆蓋。
• Tail： 100%錯誤+p95+緩慢+支付路線/金絲雀發行。

5） OpenTelemetry Collector拓撲

Agent sidkar（在每個節點/子節點上）：本地接收、最小緩沖區、導出到聚合器。
網關（集群）：尾部采樣，路由，富集，導出到Tempo/Jaeger/Zipkin/OTLP。

示例： tail-sampling （YAML片段）

yaml processors:
tailsampling:
decision_wait: 5s policies:
- name: errors type: status_code status_code:
status_codes: [ ERROR ]
- name: slow_p95 type: latency latency:
threshold_ms: 250
- name: payments type: string_attribute string_attribute:
key: service. name values: [ "payments-api", "payments-worker" ]

6）與指標和日誌的相關性

在每個日誌條目中添加「trace_id」/「span_id」。
將潛伏度度量存儲為直方圖，並啟用exemplars-指向代表「trace_id」的鏈接，以從p95框跳到特定的路徑。
發行註釋（Git SHA，圖表版本）-作為活動/標簽。

7）工具化（語言和自動代理）

Go（手動+汽車）

go tp:= sdktrace. NewTracerProvider(
sdktrace. WithBatcher(exporter),
sdktrace. WithResource(resource. NewWithAttributes(
semconv. SchemaURL,
semconv. ServiceName("payments-api"),
)),
)
otel. SetTracerProvider(tp)

ctx, span:= tracer. Start(ctx, "Deposit")
defer span. End()
span. SetAttributes(
attribute. String("psp. route","pspX"),
attribute. String("currency","EUR"),
)

Java

自動代理'-javaagent： opentelemetry-javaagent。jar'，通過env的config（「OTEL_SERVICE_NAME」，「OTEL_EXPORTER_OTLP_ENDPOINT」）。
手動-弓形位置註釋/工具（JDBC池、緩存）。

Node.js / Python

帶有SDK+插件的自動工具（Express/FastAPI/celery）。
對於隊列，是制作人/消費者的包裝紙，以提供「消息傳遞」。

8）隊列和async： 正確的睡眠

制片人（「send」）：span發送到拓撲/隊列。
消費者（「process」）：從鏈接到生產者的span 處理消息的新span（保留因果關系而無需共享「trace_id」）。

屬性： 'messaging。kafka.partition`, `messaging.rabbitmq.routing_key`, `messaging.message_id`.

在回溯中-事件「回溯」，嘗試計數器。

9） DB/緩存和 N+1

啟用DB驅動程序預告,將相同類型的請求分組到batchi中。

對於Redis/緩存,「緩存」屬性。hit`/`cache.miss`.

將「繁重」的查詢發送到單獨的睡眠-可以看到p99的位置。

10）外部提供商： PSP/遊戲工作室

包裹HTTP客戶端： 'psp。provider`, `psp.route`, `timeout_ms`, `attempt`.

編寫代碼/錯誤類型,但不編寫PII（卡號、令牌）。
通過「duration」、「error-rate」比較工作室/路線。

11） Frontend和RUM

OTel Web SDK: `page_view`, `resource_load`, `xhr`.

將「traceparent」刺入後臺，以縫制UI → API → DB skvoz的用戶路徑。
按地理/網絡提供商進行細分-可選標簽。

12）安全和PII

掩蓋字段（'db.「通過編輯」，哈希化「player_id」。
數據區域：「pii=true」，「region=EU/TR/LATAM」。
控制對付款跟蹤的訪問（基於角色）。
WORM/Retention：敏感跟蹤的保留時間,策略刪除。

13）生產力和成本

策略提示采樣：「錯誤+緩慢+付款+金絲雀發行版」。

Downsampling直方圖指標,激進的重復數據消除日誌.

基數約束：不要將「user_id」標記為度量標簽。
Collector中的緩沖區/蹦床，OTLP壓縮。

14） Dashbords和分析

服務地圖：服務依賴性，錯誤/潛伏著色。
Release compare：穩定vs金絲雀修訂（p95, error-rate, payments conv）。
Top slow traces：在「/deposit」路線上,在PSP/區域上切口。
Queue lag：深度延遲的軌道。

15） Collector配置示例

Pipelines（度量/traces/logi，片段）

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

processors:
batch:
memory_limiter:
limit_mib: 1024 spike_limit_mib: 256 attributes/payments:
actions:
- key: "psp. provider"
action: insert value: "pspX"

exporters:
otlp/traces: { endpoint: tempo:4317, tls: { insecure: true } }
otlp/metrics:{ endpoint: prometheus-otlp:4317, tls: { insecure: true } }
otlp/logs:  { endpoint: loki-otlp:4317, tls: { insecure: true } }

service:
pipelines:
traces:
receivers: [ otlp ]
processors: [ memory_limiter, batch, tailsampling ]
exporters: [ otlp/traces ]
metrics:
receivers: [ otlp ]
processors: [ batch ]
exporters: [ otlp/metrics ]
logs:
receivers: [ otlp ]
processors: [ batch ]
exporters: [ otlp/logs ]

16） Runbooks（典型腳本）

A）在「payments-api」中增長p99'

1.打開「Top slow traces」 →失敗到DB/PSP睡眠中。
2.如果PSP問題是轉換路由,則啟用retrai/taymout。
3.檢查隊列「withdrawals」 （lag）,增加消費者。

B）發布後的5xx錯誤

1.通過'服務過濾器。version`.

2.比較穩定/金絲雀；在'psp中找到香料。route`.

3.凍結促銷活動，回滾（請參閱「發行策略「/」Rolbacks」）。

C）懷疑N+1

1.具有大量短DB spans的步道。
2.啟用聚合/joins,添加緩存層。

17）實施支票

1.啟用OTel SDK和單一資源屬性（'service.name`, `env`, `region`).

2.通過所有圖層和隊列宣傳W3C Trace Context。
3.最小語義屬性集（HTTP/DB/queue/PSP）。

4.Tail-sampling： 錯誤,p95+,付款,繩索.

5.帶有「trace_id」/「span_id」的邏輯，帶有exemplars的度量。
6.Dashbords：服務地圖，發行匯編，付款流量。
7.PII政策：掩護，區域，角色，重建。
8.測試/負載：在峰值之前檢查相關性和完整性。
9.Alert中的runbook鏈接的自動生成。
10.遙測和基數成本報告。

18）反模式

沒有DB/隊列的「僅在入口處」跟蹤→沒有好處。
async中缺乏宣傳→因果關系鏈「撕裂」。
Sampling是隨機的1％，沒有尾巴邏輯→不會遇到緩慢/錯誤。
沒有「trace_id」的邏輯→沒有端到端相關性。
屬性/邏輯中的原始PII →合規風險。
「進入天花板」（用戶/會話作為度量標簽）的基數→成本爆炸。

結果

OpenTelemetry將可觀察性從一組不同的工具轉換為端到端性能語言。通過正確的上下文宣傳，整潔的語義，尾隨采樣和捆綁的「軌跡度量↔ ↔ logi」，iGaming團隊可以控制p95/p99，快速隔離瓶頸（DB，隊列，PSP），並自信地發布發行甚至在流量峰值。