OpenTelemetry実践 はじめの一歩

Transcript

1. OpenTelemetry実践 はじめの一歩 id:taxintt / @taxin_tt 2024/03/25 OpenTelemetry Casual Talk 1
2. 自己紹介 • 西川 拓志 ◦ id: taxintt / @taxin_tt • Mackerel開発チーム SRE 2
3. 今日の話 • OpenTelemetry 入門 • 自社サービスでのOpenTelemetry実践について ◦ OpenTelemetry 導入の進め方 ◦ 導入にあたっての考慮事項 3
4. 4 1.OpenTelemetry 入門
5. OpenTelemetryとは? • テレメトリデータの計装・収集の標準化を 目的としたプロジェクト ◦ e.g.) Log, Trace, Metric • 特定のベンダーに依存しないAPI、SDK、 ツール群を提供している 5
6. 6 🧐
7. OpenTelemetry “以前” の世界 • シンプルで少ないコンポーネントで構成 されたシステム • Known-unknowns ◦ 既知の (もしくは予期できる) 問題に対して 監視を設定していた 7
8. 世界の変化 • ビジネス要件の複雑化に比例して、システム / アプリケーションの複雑度が高まる • “Unknown”-unknowns ◦ 未知の (予期できない) 問題に向き合う必要がある 8
9. 世界の変化 9 https://blog.twitter.com/engineering/en_us/a/2013/observability-at-twitter
10. OpenTelemetry のコンセプト • make a system observable ◦ システムの内部状態を理解・把握する能力 = Observability ◦ 󰢄「動いている / 動いていない」 ◦ 󰢐「何がどのように動いてるのか」 テレメトリを活用しObservabilityを高める 10
11. OpenTelemetry のコンセプト • “Unknown”-unknownsへの対応 ◦ システムの内部状態を表現するテレメトリデータを 生成すること= 計装 (Instrumentation) ◦ 「どう動いている」がわかると未知の事象に対する 解像度があがる テレメトリを計装し内部状態を表現する 11
12. OpenTelemetry のコンセプト 12 https://opentelemetry.io/docs/what-is-opentelemetry/#what-is-observability
13. OpenTelemetry のコンセプト • vendor-neutral ◦ テレメトリごとに仕様が定義 ▪ ツールごとに異なるフォーマットのデータを突き合わせて... みたいなことを避けられる ◦ 学習コストも抑えられる 共通フォーマットのテレメトリを扱う 13
14. 14 「勘と経験」 から脱却する
15. OpenTelemetry のコンセプト 15 https://opentelemetry.io/community/mission/
16. 16 2.自社サービスでの OpenTelemetry実践について
17. 概要 • MackerelではOTel対応を進めています ◦ Mackerel = テレメトリ (Metric) の送信先の一つ • 社内検証(dogfooding)の一環でブックマーク チームのシステムにOTelを導入する ◦ ブックマークチームのSREと共同で実施 17
18. 18 OpenTelemetry 導入の進め方
19. OpenTelemetry 導入の進め方 • 小さく実装のサイクルを回す ◦ 監視 ≠ Observability ▪ 「既存のアラート設定をただ移行する」では不十分 ◦ 最小構成でOTelの登場人物や全体像を把握する ▪ 初手でテレメトリ送信のための仕組みを整備する ▪ その上で、計装やテレメトリ間の連携に 19
20. OpenTelemetry 導入の進め方 • 実際の進め方 ◦ 1. 事前準備 ▪ テレメトリの取得対象であるシステムの確認 ▪ テレメトリの取得方法を決める ▪ OpenTelemetry Collector / maprobeのデプロイ (ECS sidecar / stand-alone) ◦ 2. テレメトリデータ (Metric) の確認 ◦ 3. アラート・ダッシュボードの作成 20
21. 21 https://opentelemetry.io/docs/
22. OpenTelemetry Collector • データの受信、加工、送信を行うproxy ◦ アプリケーションはCollectorにデータを送る = 送信先を意識せずに済む ◦ コンテナとしてデプロイもできるので、ECSなら sidecar構成にできる 22
24. 24 導入にあたっての考慮事項
25. 導入にあたっての考慮事項 • とにかく小さく始める ◦ 小さく始めるための方法を調べる ▪ OpenTelemetry Collector (w/ ECS sidecar) ▪ 自動計装 (Auto Instrumentation) ◦ 徐々にテレメトリでカバーする範囲を増やす ▪ Collectorで取得するMetricを増やす → receiverを調べる 25
26. 自動計装 (Auto Instrumentation) • 自動計装用の Java-Agent を導入 ◦ アプリケーションを触らずに、response timeやDB へのクエリ時間、 JVMの情報などを計装できた 26
27. receiver • テレメトリデータを 受信するためのコン ポーネント e.g.) OTLP receiver, awsecscontainermetr ics, redis, mysql etc… 27
28. 28 OpenTelemetry導入後の変化
29. 導入後の変化 • 原因調査が低コストで解像度高くできる ◦ ラベルを利用した絞り込み、集計ができる ▪ e.g.) request path, zone etc… ◦ 「どのリクエストがどう遅いか」のような粒度で見れる ▪ ALBのログをAthenaでクエリ叩かなくても良い ◦ 逆にラベルの数が多く、有用なラベルを見つけて絞る際 には苦労した 29
30. 実践できていないこと • Traceなど他のテレメトリも計装する ◦ “connect metrics to other signals” • OTel Collectorも自前でビルドしたい ◦ ref: OpenTelemetry Collector Antipatterns • OTel Collector自体の監視も考える必要がある 30
31. 31 終わり (OTelの実践は続く)