Accelerating the Feedback Loop of OpenTelemetry Instrumentation with otel-tui

Transcript

1. @ymtdzzz otel-tuiでOpenTelemetry 計装のフィードバックサイクルを 高速化する 2025.05.14 Wed. Jagu'e'r オブザービリティ分科会 Meetup#2
2. Yosuke MATSUDA (@ymtdzzz) 株式会社SmartHR プロダクトエンジニア • 仕事ではRubyを書いています（その前はGolangを3年程） • プライベートではOpenTelemetryにコントリビュートしたり 関連ツールを作ったりしています • OpenTelemetryに関連した登壇など 2
3. 突然ですが
4. Production環境で OpenTelemetryを利用して いる人󰢧󰢨
5. OpenTelemetryの採用事例の増加 5 • 成熟してきたAPIや言語別SDK、ドキュメント • オブザーバビリティSaaSのOTLP対応 • OpenTelemetry関連の技術書 • ミドルウェアや各種ライブラリのネイティブ計装
6. OpenTelemetryの採用事例の増加 • 成熟してきたAPIや言語別SDK、ドキュメント • オブザーバビリティSaaSのOTLP対応 • OpenTelemetry関連の技術書 • ミドルウェアや各種ライブラリのネイティブ計装 その先に待ち受けているものは？ 6
7. OpenTelemetryの運用！
8. • SREやPlatform Engineer ◦ 組織全体のテレメトリーパイプラインや分析基盤の整備 ◦ サンプリングやフィルタリング方針の検討や共通化 • アプリケーション開発者 ◦ 計装ライブラリの設定調整（アプリレイヤーでのフィルタリ ングなど） ◦ ドメインに即したテレメトリー属性の設定 ◦ 必要に応じてマニュアル計装 継続的な改善 8
9. トラブルシューティング 9 • トレースの不具合 ◦ 不完全なトレース • バックエンドやフォーマット関連の不具合 ◦ 計装によってスパンの表示のされ方が異なる ◦ 変換が上手くいかない（Prometheus→OTelなど）
10. トラブルシューティング 10 • トレースの不具合 ◦ 不完全なトレース • バックエンドやフォーマット関連の不具合 ◦ 計装によってスパンの表示のされ方が異なる ◦ 変換が上手くいかない（Prometheus→OTelなど） 解決に時間がかかるケースも・・・
11. OpenTelemetryの難しさ
12. 「不完全なトレース」のケース 12
13. 「不完全なトレース」のケース 13 RPS制限超過 取り込み上限超過 Sampled flagの伝 搬ができていない 実装内部で Contextを 引き回せていない middlewareや言語 毎の計装の設定不備
14. 「不完全なトレース」のケース 14 RPS制限超過 取り込み上限超過 Sampled flagの伝 搬ができていない 実装内部で Contextを 引き回せていない middlewareや言語 毎の計装の設定不備 関連するコンポーネントが多い・・・
15. 「計装によってスパンの表示のされ方が異なる」ケース 15 実際の事例（Golang） • net/httpのOTel計装ライブラリで出したSpan名が上手く出てくれない • EchoのOTel計装ライブラリだと{method} {path}で出てくれる
16. 「計装によってスパンの表示のされ方が異なる」ケース 16 想定外の見え方 計装ライブラリ間の実 装差異 ？ ？ ？
17. 「計装によってスパンの表示のされ方が異なる」ケース 17 計装ライブラリ間の実 装差異 ブラックボックス化されたテレメトリー生成 ？ ？ ？ 想定外の見え方
18. どうすればいい？
19. テレメトリー生成に近いところから可能性を潰す 19 RPS制限超過 取り込み上限超過 Sampled flagの伝 搬ができていない 実装内部で Contextを 引き回せていない middlewareや言語 毎の計装の設定不備 「不完全なトレース」のケース
20. テレメトリー生成に近いところから可能性を潰す 20 RPS制限超過 取り込み上限超過 Sampled flagの伝 搬ができていない 実装内部で Contextを 引き回せていない middlewareや言語 毎の計装の設定不備 「不完全なトレース」のケース 生成から遠くなるほど検証コストが高くつく
21. ローカルで素早くフィードバックを得たい 21 • ローカルからSaaSやクラウド上に構築したバックエン ドに送信する ◦ APIキーの管理やコストの問題 • ローカルでバックエンドを立ち上げる ◦ 今日のテーマ！
22. 既存プロダクトを用いた ローカルデバッグの課題
23. • セットアップが結構大変 ◦ volume、データソースの設定（Jaegerとかは楽） • リッチで高コストな機能とUI ◦ 各種テレメトリを見に行くための導線が長い ◦ テレメトリー（OTLP）がどのようにUIとして表現されるかを理 解するために時間が必要 • Webベースなのでリロードが必要 ◦ トライアンドエラーが必要なローカル開発では無視できない 既存OSSプロダクト（Grafanaなど）をローカルで動かす 23
24. • セットアップが結構大変 ◦ volume、データソースの設定（Jaegerとかは楽） • リッチで高コストな機能とUI ◦ 各種テレメトリを見に行くための導線が長い ◦ テレメトリー（OTLP）がどのようにUIとして表現されるかを理 解するために時間が必要 • Webベースなのでリロードが必要 ◦ トライアンドエラーが必要なローカル開発では無視できない →徐々にMP(?)が削られていく... 既存OSSプロダクト（Grafanaなど）をローカルで動かす 24
25. 用途が違うのでそれはそう 25 • 出力されるテレメトリーをリアルタイムで確認したい • テレメトリーはOTLPレベルである程度の見やすさで確認 したい • 面倒な設定なしで手軽に開発フローに組み込みたい 計装を調整する開発者 既存OSSプロダクト • 豊富でリッチな分析機能及びUI • データの永続化、様々な運用に耐えうる多様なオプション
26. otel-desktop-viewerも良さそうだったが･･･ 26 https://github.com/CtrlSpice/otel-desktop-viewer • Webベースなのでリア ルタイム更新不可 • 件数が増えると激重に なる→雑に垂れ流すこ とができない
27. debug-exporterは？ 27 https://opentelemetry.io/docs/collector/troubleshooting/ • 手軽だけど可視性はいまい ち • 「トレースが出ているか？」 の確認なら使えそう • どちらかというと計装ライ ブラリの開発者向けな印象
28. 無いなら作るぞ！ ターミナルでトレース表示できたらかっこよさそうだし...
29. otel-tuiの紹介
30. 30 計装の動作確認を最速で行うため のターミナルアプリ
31. 想定ユーザー 31 • OTel SDKや計装ライブラリの開発者 ◦ opentelemetry-go(-contrib)など • 自アプリの計装の調整やデバッグをしたい開発者 ◦ contextの伝搬、カスタム属性の付与、フィルタリング な ど • OTel collectorの調整をしたいSRE ◦ 主にreceiverとprocessor周り
32. 基本的な使い方
33. ホストマシン上で動かす 33 インストール $ go install github.com/ymtdzzz/otel-tui@latest $ brew install ymtdzzz/tap/otel-tui $ nix develop github:ymtdzzz/otel-tui 起動 $ otel-tui テレメトリーの送信 $ OTEL_EXPORTER_OTLP_ENDPOINT=localhost:4317 otel-cli exec --service my-service --name "curl google" curl https://google.com
34. Dockerで開発環境に組み込む docker-compose.yml oteltui: image: ymtdzzz/otel-tui:latest container_name: otel-tui stdin_open: true tty: true collectorやexporterの向き先を修正 exporters: otlp: endpoint: oteltui:4317 service: pipelines: traces: exporters: [otlp] 34
35. 確認したいタイミングでattach （中断はCtrl+p -> Ctrl+q） $ docker compose attach oteltui Dockerで開発環境に組み込む 35 すぐに利用開始！
36. こだわりポイント
37. • 開発フローに組み込みやすい ◦ yamlを数行編集するだけ ◦ debug exporterと同じようなノリで組み込める • otel-tui自体の汎用性向上 ◦ receiverなどOTelの資産をそのまま使える ◦ prometheusやzipkin統合可のため移行検証にも◦ OTel custom collectorとして実装 37
38. リアルタイム更新とローテーション • テレメトリー受信したら即反映 ◦ リロードは不要 ◦ powered by rivo/tview • ローテーションでメモリに優しく ◦ 1000件のサービスエントリースパンまでインメモリに保持 ◦ Ctrl+Lで即時Flushも可 38
39. リアルタイム更新とローテーション 39 リアルタイム更新 検索機能 サービスエントリー スパンの情報
40. OTLPの生データに近い情報表示 • 「計装によってどのようなデータが生成されたかが」が 一目でわかる ◦ ツリー表示で折りたたみ可能 ◦ jsonのpretty printもサポート 40
41. トレースの確認に不可欠なフレームグラフ 41 フレームグラフ （折りたたみ可） スパンの情報 （OTLP準拠） スパンの関連ログ
42. その他の機能 42 • ログやメトリクスの表示（WIP） • トレースの関連ログの表示 • ログから関連スパンへのジャンプ • 各領域のサイズ変更 • サービストポロジー（WIP）
43. otel-tuiの活用例
44. （再掲） 「計装によってスパンの表示のされ方が異なる」ケース 44 実際の事例（Golang） • net/httpのOTel計装ライブラリで出したSpan名が上手く出てくれない • EchoのOTel計装ライブラリだと{method} {path}で出てくれる
45. 計装の違いが一目でわかる 45 net/http（上手く表示されない） echo（上手く表示される） http.routeがある http.routeがない
46. Prometheus→OTel→Google Cloudの変換 46 • PrometheusをOTelで取得してどこかに送信したい ◦ 例：COS上のアプリのPrometheus MetricsをCloud Monitoringに 送る • PrometheusをOpenTelemetryに移行する際の影響調査 上手く出てくれない OTel上はどんなメトリク スになる？
47. otel-tuiで可視化 47 Prometheus endpoint otel-tui • Resource Detectorはどのような属性を付与する？ • Transform Processorは想定通り変換している？ などなど
48. その他の例 48 • LBからのヘルスチェックを除外→フィルタリング設定 の動作確認 • ParentBasedSamplerの動作確認 • contextの渡し漏れ（計装ミス）の修正確認（Golang など）
49. PRの証跡としても貼りやすい👍 49 https://github.com/open-telemetry/opentelemetry-ruby-contrib/pull/1313
50. カンファレンスでのデモにも是非お使いください 50 Simplifying OpenTelemetry with Configuration - Alex Boten, Honeycomb & Jack Berg, New Relic （逆井 sanのツイートで知りました）
51. まとめ
52. OTel計装修正時の動作確認や検証を快適にする 52 • 可能な限りローカルで完結させる • 雑にテレメトリーを投げられる環境を作る • OTLPの生データに近い情報を確認する
53. OTel計装修正時の動作確認や検証を快適にする 53 • 可能な限りローカルで完結させる • 雑にテレメトリーを投げられる環境を作る • OTLPの生データに近い情報を確認する otel-tuiがお役に立てるかも！
54. フィードバック&PRお待ちしています！ 54 • TODOはまだまだあります ◦ メトリクスの改善 ◦ 全体的なUIの改善 ◦ 柔軟な設定 ◦ 自動テストが足りてない箇所がある
55. 最後に少しだけ宣伝🙏
56. SmartHRでもOpenTelemetryの波がｷﾀ 56 • アプリはNewRelic計装が多いものの • ミドルウェアのネイティブ計装起因でOTelを送信する ケースが出てきた！ • NewRelic計装との相互運用性も良さそうなので 本格運用に期待
57. そんなSmartHRはエンジニアを募集しています！ 57 エンジニア採用サイト https://hello-world.smarthr.co.jp/ SmartHR Tech Blog https://tech.smarthr.jp/
58. ありがとうございました！