分散トレーシング

（セクション： 技術とインフラ）

概要

分散トレースは、ゲートウェイ、API、キュー、データベース、外部プロバイダ（PSP/ゲームスタジオ）を通じてリクエストパスに沿って、どこで時間が失われるのかという質問に対する答えを提供します。OpenTelemetry （OTel）は、トレイル、メトリック、ログを組み合わせたオープンなSDK/エージェント/プロトコル標準です。iGamingでは、p95/p99を維持し、支払い問題を迅速にローカライズし、ピークトーナメントの前にボトルネックを特定するための基本的なツールです。

1） OTelの概念

トレース-オペレーションのフルパス（預金、レート、引き出し）。
Span-作業領域（HTTPハンドラ、SQLリクエスト、キュー/プロバイダ呼び出し）。
Attributes-value key with details （'net。ピア。名前'、'db。システム'、'psp。ルート'）。
イベント-インスタントイベント（リトリート、タイムアウト、キャッシュミス）。
リンク-他のトレースへのリンク（非同期/キューで重要）。
リソース-プロセスメタデータ：'service。名前'、'サービス。バージョン'、'deployment。環境'、'クラウド。「地域」。

2）コンテキスト伝播

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

さらに-安全なキーのための手荷物（例えば、'テナント'、'ルート'）、そこにPIIを入れないでください。

コンテキストをパンクする場所：APIゲートウェイ→内部RPC→producer to queue→consumer→external HTTP （PSP/providers）。

3）セマンティック慣習（必須最小）

HTTP/RPC： 'http。メソッド'、'http。ルート'、'http。 。 。
DB/cache： 'db。システム'（'mysql'/'postgresql'/'redis'）、'db。ステートメント'（マスク）、'db。操作'。

キュー： 'メッセージ。システム'（'kafka'/'rabbitmq'）、'messaging。宛先'、'メッセージ。操作'（'send'/'process'）

支払い：'psp。ルート'、'psp。プロバイダ'、'支払い。id'（仮名）、'amount'、 'currency'。
iGamingドメイン：'ゲーム。プロバイダ'、'ゲーム。session_id' （hash）、 'player。 。 。

単一のタクソノミ→ダッシュボードの比較可能性と原因の迅速な検索。

4）サンプリング： データに溺れない方法

ヘッドベース

簡単、安い；一般的な流れのために適した。
マイナス-「面白い」遅い/誤ったトラックを失うことができます。

テールベース（コレクター）

この決定は、スパン終了後に行われます。エラー/遅い/重要なセグメント（VIP/支払い）のみを保存します。
生産負荷に最適：高い情報内容のコストを大幅に削減します。

• 頭部：「背景」の適用範囲のための5-10％。
• Tail： 100％ error+p95+slow+payment tracks/canaryリリース。

5） OpenTelemetryコレクタートポロジ

Agent-sidecar（各ノード/pod上）：ローカル受諾、最小バッファ、アグリゲータへのエクスポート。
ゲートウェイ（クラスタ）：テールサンプリング、ルーティング、エンリッチメント、Tempo/Jaeger/Zipkin/OTLPへのエクスポート。

例： テールサンプリング（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'を追加します。
p95-boketから特定のトレースへの「ジャンプ」の代表的な'trace_id'への参照-レイテンシーメトリックをヒストグラムとして格納し、exemplarsを含みます。
リリースアノテーション（Git SHA、チャート版）-イベント/ラベルなど。

7）器械使用（言語および自動代理店）

移動（手動+自動）

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'、config via env（'OTEL_SERVICE_NAME'、'OTEL_EXPORTER_OTLP_ENDPOINT'）。
マニュアル-タマネギの場所（JDBCプール、キャッシュ）の注釈/ツール。

ノード。js/Python

SDK+プラグインを使用した自動ツール（Express/FastAPI/celery）。
キューの場合-プロデューサー/コンシューマーラッパーが'messaging。'とリンク。

8）キューと非同期： 正しいスパン

プロデューサー（'send'）：トピック/キューに送信するスパン。
Consumer （'process'）：リンクからプロデューサーへのメッセージ処理の新しいスパン（共通の'trace_id'なしで因果関係を保存）。
属性：'messaging。カフカだよ。パーティション'、'メッセージング。rabbitmq。routing_key'、メッセージ。 。 。
リトレイ-イベント'retry'、試行カウンター。

9） DB/キャッシュおよびN+1

データベースドライバのトレースを有効にし、同じタイプのクエリをバッチにグループ化します。

Redis/cacheの場合、属性は'cacheです。'/'キャッシュを押します。「ミス」

別のスパンに「重い」要求を取り出します-あなたはどこでp99を見ることができます。

10）外部プロバイダー： PSP/ゲームスタジオ

HTTPクライアントをラップします：'psp。プロバイダ'、'psp。route'、'timeout_ms'、 'attempt'。
エラーコード/タイプを記録しますが、PII（カード番号、トークン）ではありません。
スタジオ/ルートを'duration'、 'error-rate'で比較します。

11）フロントエンドとラム酒

OTel Web SDK： 'page_view'、 'resource_load'、 'xhr'。
UI→API→データベースを通してユーザーのパスをステッチするためにバックエンドに'traceparent'を貫通します。
地理/ネットワークプロバイダによるセグメンテーション-オプションのラベル。

12）安全およびPII

フィールドをマスクします（'db。ステートメント'edited）、ハッシュ'player_id'。
データゾーン：'pii=true'、 'region=EU/TR/LATAM'。
支払いトラックへのアクセス制御（ロールベース）。
WORM/Retention：機密トレースの保持期間、ポリシーによる削除。

13）性能および費用

ポリシーによるテールサンプリング：「errors+slow+payments+canary releases」。
メトリクスのダウンサンプリング・ヒストグラム、積極的なログ重複排除。
Cardinality制約：'user_id'をメトリックラベルとして書き込まないでください。
Collectorのバッファ/バッチ、OTLP圧縮。

14）ダッシュボードと分析

サービスマップ：サービス依存性、エラー/レイテンシーカラーリング。
リリース比較：安定版とカナリアリビジョン（p95、エラーレート、支払いconv）。
最も遅いトレース：ルート'/deposit'に沿って、PSP/regionに沿ったセクション。
キューラグ：ディープ消費遅延トラック。

15）コレクター構成例

パイプライン（メトリック/トレイル/ログ、フラグメント）

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） 「payment-api」におけるp99の成長'

1.「トップスロートレース」を開きます→データベース/PSPスパンに該当します。
2.PSPの問題がルートを翻訳する場合は、リトレイ/タイムアウトを有効にします。
3.キューをチェック'withdrawals'（ラグ）、消費者を増加させます。

B）リリース後5xxバグ

1.'serviceでフィルターします。バージョン'。
2.安定した/カナリアを比較して下さい；'pspでスパイクを見つける。ルート'。
3.フリーズプロモーション、ロールバック（リリース戦略/ロールバックを参照）。

C）疑われるN+1

1.多数の短いDBスパンを持つトレイル。
2.集計/ジョインを有効にし、キャッシュレイヤーを追加します。

17）実装チェックリスト

1.OTel SDKとuniform Resource属性（'service。名前'、'env'、'region'）。
2.すべてのレイヤーとキューを通じてW3Cトレースコンテキストを伝播します。
3.セマンティック属性の最小セット（HTTP/DB/queue/PSP）。
4.テールサンプリング：エラー、p95+、支払い、カナリア。
5.'trace_id'/'span_id'でログを記録します。
6.ダッシュボード：サービスマップ、リリース比較、支払いフロー。
7.PIIポリシー：マスキング、ゾーン、役割、保持。
8.テスト/ロード：ピーク前にトレースの相関と完全性をチェックします。
9.アラート内のrunbookリンクの自動生成。
10.Telemetry Cost and Cardinalityレポート。

18） Antipatterns

データベース/キューなしで「入り口でのみ」トレース→使用しない。
非同期の伝播の欠如→原因と効果チェーンが壊れます。
テールロジックのないランダムな1％サンプリング→遅い/誤ったものをキャッチしません。
trace_id→エンドツーエンドの相関なしのログ。
属性/ログ→コンプライアンスリスクの未加工PII。
Cardinality 「to the ceiling」 （user/session as metric labels）→値の爆発。

概要

OpenTelemetryは、異なるツールのコレクションからオブザビリティをエンドツーエンドのパフォーマンス言語に変えます。適切なコンテキスト伝播、端正なセマンティクス、テールサンプリング、および「メトリクス↔トレース↔ログ」の組み合わせにより、iGamingチームはp95/p99を制御し、ボトルネック（DB、キュー、PSP）を迅速に分離し、トラフィックピークでも確実にリリースします。