Loadbalancing exporter internals

OpenTelemetry meetup 2026-05 の発表資料です
https://opentelemetry.connpass.com/event/390564/

これの前提となっているセッションはこちらに録画があるので、そちらも確認してください。
https://event.cloudnativedays.jp/cnk/talks/3062
https://speakerdeck.com/ymotongpoo/why-you-need-the-tail-sampling-and-why-you-dont-want-it

Transcript

1. OpenTelemetry meetup 2026-05 – May 21st, 2026 Loadbalancing エクスポーター について 山口 能迪 (@ymotongpoo) Staff Developer Advocate, Grafana Labs
2. 山口 能迪（やまぐちよしふみ） Staff Developer Advocate Grafana Labs 専門領域 • オブザーバビリティ • SRE @ymotongpoo
3. 祝！ OpenTelemetry CNCF Graduated 🎉🎉🎉🎉🎉 🎉🎉 🎉🎉🎉🎉🎉 🎉🎉
4. 今⽇の話はこれで話さなかった部分 https://event.cloudnativedays.jp/cnk/talks/3062
5. トレース過多は大変 • ストレージコスト高騰 • 分析ツールの負荷増 • 計測時のオーバーヘッド増 • コレクターのSPOF化
6. 解決策 1: コレクタープール コレクターを複数立てて負荷分散
7. 解決策 2: サンプリング トレースのサンプリングの大きな分岐点 最初のスパンを受け取った瞬間に記 録有無を決定 特定のトレースのすべてのスパンを受 け取った後に記録するかを決定 ヘッドベースサンプリング テイルベースサンプリング 確率的サンプリング • eg) 100回に1回記録 (1%) ルールベースサンプリング • eg) ヘルスチェックの除外 ルールベースサンプリング • eg) トレース全体のレイテンシー • eg) スパン数の合計 • eg) 特定のスパンの有無
8. 解決策 2: サンプリング トレースのサンプリングの大きな分岐点 最初のスパンを受け取った瞬間に記 録有無を決定 特定のトレースのすべてのスパンを受 け取った後に記録するかを決定 ヘッドベースサンプリング テイルベースサンプリング 確率的サンプリング • eg) 100回に1回記録 (1%) ルールベースサンプリング • eg) ヘルスチェックの除外 ルールベースサンプリング • eg) トレース全体のレイテンシー • eg) スパン数の合計 • eg) 特定のスパンの有無 みんなこれをやりたがる
9. コレクタープール × テイルサンプリングで解決？
10. コレクタープール × テイルサンプリングの罠 テイルを知る術がない
11. コレクタープール × テイルベースサンプリングの罠 ロードバランサーがトレース IDを見 て振り分けないとダメ
12. しかもバッチで来る A A A B1 B1 B1 A A A B1 B1 B1 ロードバランサーが見える ヘッダーはパケットの外
13. 同一トレースのスパンを同一コレクターに振り分け A A A B1 B1 B1 A B1 A B1 A B1
14. チャレンジ 思っているより考えることが多い OTLPでロードバランサーに送信しているときに起きていること • エクスポーターからLBへのバッチ送信も1つのトレース • 汎用ロードバランサーは送信トレースのヘッダーは見れる • OTLP over gRPC は内部に複数のスパンデータを持つ 汎用L4/L7 LB だとバッチ自体のトレースしか見れない
15. loadbalancing エクスポーターでできる https://github.com/ymotongpoo/otel-lb-tailsampling-demo
16. Tier 1: Gateway loadbalancing エクスポーターの設定 exporters: loadbalancing: routing_key: "traceID" protocol: otlp: resolver: dns: hostname: otel-tier2-internal port: "4317" トレースなら "service", "traceID", "attribute" が有効
17. Tier 1がスケールしたらどうするの？
18. コンシステントハッシュ loadbalancingexporter/consistent_hash.go https://www.paperplanes.de/2011/12/9/the-magic-of-consistent-hashing.html
19. loadbalancingエクスポーター動作原理 1. デコード A A A B1 B1 B1 A A A B1 B1 B1 まずptrace形式でスパンを全部バラす
20. loadbalancingエクスポーター動作原理 2. グルーピング A A A B1 B1 B1 traceID ごとに束ねる
21. loadbalancingエクスポーター動作原理 3. ハッシュ A A A B1 B1 B1 hash: 374044869 hex: 0x164b78c5 position: 4869 traceID: 4bf92f…4736 traceID: 0af765…319c hash: 223009813 hex: 0x0d4adc15 position: 25813 traceID: 70bc2f…ce51 hash: 3272612155 hex: 0xc310193b position: 32155 この番地に応じて宛先ノードを決定する CRC32でハッシュ化して36000でmod
22. 4. ルーティング loadbalancingエクスポーター動作原理 • アドレスは 035999 • 仮想点は 100個
23. 4. ルーティング（ノード増加時） loadbalancingエクスポーター動作原理
24. 4. ルーティング（ノード減少時） loadbalancingエクスポーター動作原理
25. コレクタープール側の設定 kind: Service metadata: name: otel-tier2-internal spec: clusterIP: None # Headlessにする selector: app: otel-tier2 ports: - port: 4317 targetPort: 4317 kind: StatefulSet metadata: name: otel-tier2 spec: serviceName: otel-tier2-internal replicas: 4 selector: matchLabels: app: otel-tier2 template: metadata: labels: app: otel-tier2 Pod名を {StatefulSet名}-{通し番号} で固定 Tier 2: Sampling
26. tail_sampling プロセッサーの設定 processors: batch: tail_sampling: decision_wait: 5s num_traces: 10000 expected_new_traces_per_sec: 100 policies: - name: latency-policy type: latency latency: {threshold_ms: 100}
27. tail_sampling プロセッサーの設定 processors: batch: tail_sampling: decision_wait: 5s num_traces: 10000 expected_new_traces_per_sec: 100 policies: - name: latency-policy type: latency latency: {threshold_ms: 100}
28. loadbalancing エクスポーター & tail_sampling プロセッサー オープンソースのみの構成 https://github.com/ymotongpoo/otel-lb-tailsampling-demo