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 公式ユーザーコミュニティ） ▪ エバンジェリスト ▪ オブザーバビリティ分科会 運営 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 のライブラリ計装は クライアント・サーバー間の通信が発生する度に スパンが生成される (Ex. リクエストボディの受信 ) ASGI の イベントごとに スパンを生成
8. 8 原因は FastAPI のライブラリ計装と Hypercorn それぞれの性質から仮説をたてた HTTP/1.1 50MB Upload HTTP/2 50MB Upload 原因となりえる仮説 FastAPI のライブラリ計装は クライアント・サーバー間の通信が発生する度に スパンが生成される (Ex. リクエストボディの受信 ) Hypercorn はリクエストボディの受信 を粒度の細かいチャンクに分割 フレーム フレーム フレーム フレーム フレーム フレーム フレーム フレーム フレーム フレーム フレーム ライフサイクル イベントが発生 ASGI の イベントごとに スパンを生成
9. 9 原因は FastAPI のライブラリ計装と Hypercorn それぞれの性質から仮説をたてた HTTP/1.1 50MB Upload HTTP/2 50MB Upload 原因となりえる仮説 FastAPI のライブラリ計装は クライアント・サーバー間の通信が発生する度に スパンが生成される (Ex. リクエストボディの受信 ) 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 をカスタムすることで解決 直送でも SpanProcessor のカスタムが可能
13. 想定以上のスパン生成を経験 • FastAPI のライブラリ計装と Hypercorn の性質が合わさったコーナーケースにハマった → コードを見に行って事象を想像できたのは良い経験だった OpenTelemetry Collector がなくてもスパン生成をカスタムできる • Collector をデプロイしなくてもコード上でカスタムできた → チーム状況によってコンポーネントを増やすことを避けたいケースもあるため、コードでやりくり できるのは選択肢として持っておいても良さそう まとめと学び