Upgrade to Pro — share decks privately, control downloads, hide ads and more …

OpenTelemetry SpanProcessor を Let's カスタマイズ!

OpenTelemetry SpanProcessor を Let's カスタマイズ!

Avatar for Tomonori Hayashi

Tomonori Hayashi

May 16, 2025
Tweet

More Decks by Tomonori Hayashi

Other Decks in Technology

Transcript

  1. Tomonori Hayashi • NTT コミュニケーションズ ◦ ソフトウェアエンジニア ▪ Front:TypeScript -

    React/Next.js ▪ Infra:Google Cloud • Google Cloud Partner Top Engineer 2024 - 2025 • Google Cloud Tech Blog Challenge 2024 個人カテゴリ受賞 • Google Cloud All Certifications • コミュニティ ◦ Jagu’e’r (Google Cloud 公式ユーザーコミュニティ) ▪ Evangelist ▪ オブザーバビリティ分科会 Organizer • 興味がある方はぜひ Connpass グループにご参加ください! 2 @pHaya72 @t_hayashi
  2. 7 原因は FastAPI のライブラリ計装と Hypercorn それぞれの性質から仮説をたてた HTTP/1.1 50MB Upload HTTP/2

    50MB Upload 原因となりえる仮説 FastAPI のライブラリ計装は クライアント・サーバー間の通信が発生する度に スパンが生成される ASGI の イベントごとに スパンを生成
  3. 8 原因は FastAPI のライブラリ計装と Hypercorn それぞれの性質から仮説をたてた HTTP/1.1 50MB Upload HTTP/2

    50MB Upload 原因となりえる仮説 FastAPI のライブラリ計装は クライアント・サーバー間の通信が発生する度に スパンが生成される Hypercorn はリクエストボディの受信 を粒度の細かいチャンクに分割 フレーム フレーム フレーム フレーム フレーム フレーム フレーム フレーム フレーム フレーム フレーム ライフサイクル イベントが発生 ASGI の イベントごとに スパンを生成
  4. 9 原因は FastAPI のライブラリ計装と Hypercorn それぞれの性質から仮説をたてた HTTP/1.1 50MB Upload HTTP/2

    50MB Upload 原因となりえる仮説 FastAPI のライブラリ計装は クライアント・サーバー間の通信が発生する度に スパンが生成される Hypercorn はリクエストボディの受信 を粒度の細かいチャンクに分割 → 高頻度でスパン生成が行われてしまっていた フレーム フレーム フレーム フレーム フレーム フレーム フレーム フレーム フレーム フレーム フレーム ライフサイクル イベントが発生 ASGI の イベントごとに スパンを生成
  5. 10 Before :不要なスパンをフィルタリングしたい ローカルでは otel-tui で確認 課題発覚時は右図のように「 http receive」という サフィックスのつくスパンが大量に生成される

    冒頭ではこのようなスパンが 7000 以上トレースに 紐づいてしまっていてデバッグしづらい状況に 特定サフィックスのつくスパン名のス パンを除外したい
  6. 11 OpenTelemetry Collector があれば・・ Processors で処理できそう 特定のスパンの除外などは Collector に任せればよさそう 一方で、Collector

    のデプロイに悩んだ ・既存の Collector は GKE 上にあり公開していない → Cloud Run 上のアプリケーションから参照可能な 新たな Collector を用意する必要があった → 管理コンポーネントの増加や管理するリポジトリの検討な どいくつか面倒な問題が・・・ 今回はアプリから直送する形に!
  7. 12 After :SpanProcessor をカスタムすることで解決 OpenTelemetry-Python のコード on_start 関数 ・スパンが開始された時に呼び出されるメソッド ・注意点としてスパンを開始したスレッドで同期的に

    呼び出されるために、処理をブロックするような実装は 避けるべきとのこと on_end 関数 ・スパンが終了した時に呼び出されるメソッド ・ReadableSpan 型のオブジェクトが終了したスパンとなっており、 スパンが終了した後は基本的に読み取り専用となっている on_end 関数で生成したスパンを処理する 引用:https://github.com/open-telemetry/opentelemetry-python/blob/main/opentelemetry-sdk/src/opentelemetry/sdk/trace/export/__init__.py
  8. 13 After :SpanProcessor をカスタムすることで解決 直送でも SpanProcessor のカスタムが可能 BatchSpanProcessor を継承した CustomSpaProcessor

    を作成 特定のサフィックスがつくスパン名を除外するように on_end 関数をオーバーライドする
  9. 想定以上のスパン生成を経験 • FastAPI のライブラリ計装と Hypercorn の性質が合わさったコーナーケースにハマった → コードを見に行って事象を想像できたのは良い経験だった OpenTelemetry Collector

    がなくてもスパン生成をカスタムできる • Collector をデプロイしなくてもコード上でカスタムできた → チーム状況によってコンポーネントを増やすことを避けたいケースもあるため、コードでやりくり できるのは選択肢として持っておいても良さそう まとめと学び