分散トレース

分散トレース

1）理由とそれが何であるか

分散トレーシングは、リクエストパス全体に沿って操作をリンクする方法です。front→APIゲートウェイ→マイクロサービス→データベース/キャッシュ→ブローカー→jabs/パイプライン。
結果はスパン（スパン）からのトレースで、各スパンは属性、イベント、ステータスを持つコンポーネントの操作をキャプチャします。これは、RCAを加速し、SLOを維持し、MTTRを低減するのに役立ちます。

• クリティカルパスとボトルネックの可視性。
• 症状（メトリック）と原因（スパン）と詳細（ログ）の相関。
• リトレイ、キュー、DLQ、ファンアウト、レイテンシーの「こぎり」の分析。

2）トレースデータモデル

trace-'trace_id'でグラフを呼び出します。
Span-операция： 'name'、 'kind' （SERVER/CLIENT/PRODUCER/CONSUMER/INTERNAL）、 'start/end'、 'status'、 'attributes'、 'events'、 'links［］'。
属性-値キー（route、 db。システム、メッセージ。システム、クラウド。地域、等）。
イベント-スパン内のインスタントタグ（'retry'、 'cache_miss'など）。
Span Links-「親子」以外の接続（batchi、 retrai、 fan-in/out）。
リソース-プロセス/サービスメタデータ（'service。name'、version、 environment）。

3）コンテキストと許容性

3.1 W3Cトレースコンテキスト

• 'traceparent'： 'version-traceid-spanid-flags'（フラグはサンプリングを含む）。
• 'tracestate'：ベンダー固有の状態（最小）。
• 手荷物-ビジネスコンテキストのキー（限定、PII/秘密なし）。

3.2コンテキストを投げる

HTTP： 'traceparent'/'tracestate'；gRPC：メタデータ；WebSocket：アップグレード時とメッセージ内；

メッセージ：ヘッダー（Kafka/NATS/RabbitMQ）-元のコンテキストをPRODUCERで保存し、CONSUMERで転送します。
ベース：コンテキストを「運ぶ」ことはありません-属性をスパンに記録します（query、 rows、 db。システム）、しかし値ではありません。

4）見本抽出： 壊れた行く方法

ヘッドサンプリング：確率的/ルール別（ルート、テナント、エンドポイント）。
テールサンプリング（コレクター上）：「面白い」トレイルを保存-エラー、長いp95/p99、まれなパス。
例：ヒストグラムメトリックには、特定の'trace_id'への参照が格納されます。
推薦：結合-5xx/timeout/p99のための頭部5-20％+尾の規則100％。

5）属性と分類（最低必要）

• 「サービス」名前'、'サービス。バージョン'、'deployment。環境'、'クラウド。region'、'http。ルート'、'http。メソッド'、'http。status_code'、 'db。システム'、'db。statement'（短縮/データなし）'、messaging。システム'、'メッセージ。操作'、'ピア。サービス'、'net。ピア。名前'、'テナント。id'、'リクエスト。ID。

ビジネスラベル：きちんとした、PII-free。例：'order。セグメント'、'計画。Tier'。

6）非同期スクリプト、キュー、バッチ

PRODUCER→CONSUMER： contextでspan PRODUCERを作成します。メッセージ内-ヘッダー（traceparent、 baggage）。CONSUMERは、SERVER/CONSUMER-spanからPRODUCERへのリンクを開始します（厳密な階層がない場合）。
ファンアウト：1つの入力-多くの出力→子スパンまたはリンク。
バッチ：CONSUMERは、Nメッセージのバースト→N個のコンテキストに対して各messageIdの'events'または'links'を持つ1つのスパンを読み込みます。
DLQ：別々のspan 'messaging。dlq。publish'理性の数。
Retrai： 'event： retry'+'retry。count'属性；できれば新しいCHILDスパンを試してみてください。

7）ログとメトリックとの統合

ログは'trace_id'/'span_id'→をクリックしてログに移動します。
RED/USEメトリックには、例題→p99ピークから「悪い」スパンに移動します。
トレースは、イベントを通じて技術信号（依存性エラー）とビジネス信号（変換）を生成します。

8）性能および費用

イベントサンプリングとスロットリング。
属性のカーディナリティ削減（'user_id'/'session_id'はlabel！）。
輸出業者による圧縮/butching；タイムアウト境界をエクスポートします。
貯蔵：熱い1-7日、そして-単位/だけ「問題」の道。
支出のカテゴリ：コレクター、インデックス、ストレージ、出口。

9）セキュリティとプライバシー

Transit： TLS 1。 ；Rest：暗号化、秘密鍵（「Encryption In Transit/At Rest」を参照）。
PIIと秘密：属性/イベントに書き込まないでください。プロデューサーのトークン化/マスキング。
マルチテナント：'テナント。リソースラベルとしてのid'とスペースの分離、ポリシーの読み取り；監査、トレースアクセス（監査および変更されていないログを参照）。

10）実装スキーム（参考）

10.1 OpenTelemetry SDK（擬似コード）

python from opentelemetry import trace from opentelemetry. sdk. trace import TracerProvider from opentelemetry. sdk. resources import Resource from opentelemetry. sdk. trace. export import BatchSpanProcessor from opentelemetry. exporter. otlp. proto. grpc. trace_exporter import OTLPSpanExporter

provider = TracerProvider(resource=Resource. create({
"service. name":"checkout","service. version":"1. 12. 0","deployment. environment":"prod"
}))
provider. add_span_processor(BatchSpanProcessor(OTLPSpanExporter(endpoint="otel-collector:4317", insecure=True)))
trace. set_tracer_provider(provider)
tr = trace. get_tracer("checkout")

with tr. start_as_current_span("POST /pay", attributes={
"http. route":"/pay","http. method":"POST","tenant. id":"t-42"
}):
business logic, external API call and pass DB

10.2 OTelコレクター-テールサンプリング（フラグメント）

yaml processors:
tailsampling:
decision_wait: 2s policies:
- type: status_code status_codes: [ERROR]
- type: latency threshold_ms: 900
- type: probabilistic sampling_percentage: 10 exporters:
otlphttp: { endpoint: http://trace-backend:4318 }
service:
pipelines:
traces:
receivers: [otlp]
processors: [batch, tailsampling]
exporters: [otlphttp]

10.3カフカ-コンテキスト転送（コンセプト）

PRODUCER：ヘッダー'traceparent'、 'baggage'を追加します。
CONSUMER：メッセージが新しいストリームを開始した場合、新しいSERVER/CONSUMERスパンがヘッダーからコンテキストへリンクされます。

11） データ/ETLのML

バッチパイプラインの場合： 'dataset。urn'、'run。id'、'行。'in/out'、 'freshness。「遅い」

MLの場合：トレーニング/推論の範囲、モデルバージョン、レイテンシ、フィーチャーストア。
Lineage： 'runへのリンク。「id」のデータセットです。トレースからデータ起源グラフにジャンプすることができます。

12） トレースプラットフォームSLO

空室状況の摂取： ≥ 99。9%

インデックス作成の遅延： ≤ 60 s p95

ヘッドサンプルの適用範囲： 主要なルートの≥ 5-10％

「クリティカルパス」ディレクトリに従って、status ERRORとlatency> thresholdのトレイルを100％保存

プラットフォームアラート：ドロップの増加、エクスポートタイムアウト、インデクサラグ、カーディナリティの過熱。

13）テストおよび検証

CIのトレースコントラクト：キーエンドポイント上のスパンの存在、必須属性、正しい'トレースペアレント'がゲートウェイ/プロキシを通過します。
合成/ラムサンプル：外部からトレイルを収集します。
カオス/インシデント：依存関係を無効にし、テールサンプラーがエラーを「ピックアップ」することを確認します。
販売中の煙：リリース後-「任意のスパンがあります」と模範→トレース。

14）チェックリスト

販売する前に

• W3C Trace Contextはどこでもスローされます。メッセージ-ヘッダー。
• 基本的なヘッドサンプリングが有効です。5xx/p99のテールルールが設定されています。
• 必須属性はルート、メソッド、ステータス、サービスです。バージョン、テナント。id。 id。
• JSONは'trace_id'/'span_id'でログを記録します。
• PII消毒剤；外出/レストアクセスポリシーでの暗号化。
• ダッシュボード：「critical path」、 「dependency errors'、」 retras/timeouts'。

操作

• 属性のカーディナリティの月次レビュー。クォータ。
• SLOによるテールサンプリングのチューニング（ノイズが少なく、サンプル内のすべての「ホット」）。
• transition metric→exemplar→trace→logsでRCAをトレーニングします。
• キュー、DLQ、 ETLジョブのカバーをチェックします。

15） Runbook'の

RCA： p99上昇/支払

1.REDダッシュボードを開きます。bin p99から模範的にトレースします。
2.「狭い」CLIENT-span（例えば、'gateway。call'）、check' retry。カウント'、タイムアウト。
3.サービスバージョン/依存関係、地域/ゾーンを比較します。
4.劣化（キャッシュ応答/RPS制限）を有効にし、依存関係の所有者に通知します。
5.修正後-RCAと最適化チケット。

DLQサージ

1.'messagingによるトレースフィルタ。dlq。公開してください。
2.理由（イベント）を確認し、リリースと相関します。
3.再処理を開始し、一時的にCONSUMERのタイムアウトを増やし、下流の所有者に通知します。

16）頻繁なエラー

ゲートウェイ/ブローカーによるコンテキスト予測はありません。ソリューション：ミドルウェア/インターセプター、単一のライブラリ。
すべてのトレイル100％。高価で無意味-テールサンプリングを使用します。
'trace_id'なしでログを記録します。相関→MTTR→が失われます。
属性のPII。マスク/トークン化；技術的な文脈だけを保ちなさい。
「ミュート」バックグラウンドジャブ。バッチ/パーティションと'runにスパンを追加します。ID。
名前の不一致。スパンと属性キーの辞書を入力します。

17） FAQ

Q：頭部か尾のサンプリングはよりよいですか？
A：組合せ。ヘッドはベースレイヤーを与え、テールは異常/エラーの保存を保証します。

Q：厳格な階層なしでKafkaをトレースするにはどうすればよいですか？
A： PRODUCERとCONSUMERの間のスパンのリンクを使用して下さい；コンテキスト-ヘッダーで。

Q：敏感なSQLをどうするか？
A： 'db。statement 'shortened/normalized （no values）または'db。操作'+寸法/時間。

Q：ビジネスメトリクスとどのように関係していますか？
A： PII （plan/segment）なしでドメインの属性を追加し、スパン内で「ビジネスステージ」のイベントを使用して、変換メトリクスからexemplarに移動します。

• 「Observability：ログ、メトリクス、トレース」
• 「監査ログと不変ログ」
• 「In Transit/At Rest Encryption」
• 「データ起源（系統）」
• 「デザインによるプライバシー（GDPR）」
• 「秘密管理」