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

Transcript

1. OpenTelemetry SpanProcessor を Let’s カスタマイズ SRE Tech Talk #12 - Tomonori Hayashi 1
2. 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
3. 本日お話しすること • 想定以上にスパンが生成されてしまった罠について • OpenTelemetry Collector を使わなくてもスパンをカスタムできることについて
4. 4 とある日に見つけたトレース 7000 以上のスパンが生成されてトレースに紐づいている・・・
5. 5 きっかけは Cloud Run の制約 Cloud Run のリクエスト最大サイズの制約にハマった HTTP/1.1 50MB Upload 引用：https://cloud.google.com/run/quotas?hl=ja
6. 6 原因は FastAPI のライブラリ計装と Hypercorn 制約を回避するために HTTP/2 でリクエストを受けるように変更 HTTP/1.1 50MB Upload HTTP/2 50MB Upload
7. 7 原因は FastAPI のライブラリ計装と Hypercorn それぞれの性質から仮説をたてた HTTP/1.1 50MB Upload HTTP/2 50MB Upload 原因となりえる仮説 FastAPI のライブラリ計装は クライアント・サーバー間の通信が発生する度に スパンが生成される ASGI の イベントごとに スパンを生成
8. 8 原因は FastAPI のライブラリ計装と Hypercorn それぞれの性質から仮説をたてた HTTP/1.1 50MB Upload HTTP/2 50MB Upload 原因となりえる仮説 FastAPI のライブラリ計装は クライアント・サーバー間の通信が発生する度に スパンが生成される Hypercorn はリクエストボディの受信 を粒度の細かいチャンクに分割 フレーム フレーム フレーム フレーム フレーム フレーム フレーム フレーム フレーム フレーム フレーム ライフサイクル イベントが発生 ASGI の イベントごとに スパンを生成
9. 9 原因は FastAPI のライブラリ計装と Hypercorn それぞれの性質から仮説をたてた HTTP/1.1 50MB Upload HTTP/2 50MB Upload 原因となりえる仮説 FastAPI のライブラリ計装は クライアント・サーバー間の通信が発生する度に スパンが生成される Hypercorn はリクエストボディの受信 を粒度の細かいチャンクに分割 → 高頻度でスパン生成が行われてしまっていた フレーム フレーム フレーム フレーム フレーム フレーム フレーム フレーム フレーム フレーム フレーム ライフサイクル イベントが発生 ASGI の イベントごとに スパンを生成
10. 10 Before ：不要なスパンをフィルタリングしたい ローカルでは otel-tui で確認 課題発覚時は右図のように「 http receive」という サフィックスのつくスパンが大量に生成される 冒頭ではこのようなスパンが 7000 以上トレースに 紐づいてしまっていてデバッグしづらい状況に 特定サフィックスのつくスパン名のス パンを除外したい
11. 11 OpenTelemetry Collector があれば・・ Processors で処理できそう 特定のスパンの除外などは Collector に任せればよさそう 一方で、Collector のデプロイに悩んだ ・既存の Collector は GKE 上にあり公開していない → Cloud Run 上のアプリケーションから参照可能な 新たな Collector を用意する必要があった → 管理コンポーネントの増加や管理するリポジトリの検討な どいくつか面倒な問題が・・・ 今回はアプリから直送する形に！
12. 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
13. 13 After ：SpanProcessor をカスタムすることで解決 直送でも SpanProcessor のカスタムが可能 BatchSpanProcessor を継承した CustomSpaProcessor を作成 特定のサフィックスがつくスパン名を除外するように on_end 関数をオーバーライドする
14. 想定以上のスパン生成を経験 • FastAPI のライブラリ計装と Hypercorn の性質が合わさったコーナーケースにハマった → コードを見に行って事象を想像できたのは良い経験だった OpenTelemetry Collector がなくてもスパン生成をカスタムできる • Collector をデプロイしなくてもコード上でカスタムできた → チーム状況によってコンポーネントを増やすことを避けたいケースもあるため、コードでやりくり できるのは選択肢として持っておいても良さそう まとめと学び