Building Observability Infrastructure with OpenTelemetry and SaaS

Transcript

1. OpenTelemetryとSaaSの “良いとこ取り”で構築する 柔軟なオブザーバビリティ基盤 2024.11.20 Wed. OpenTelemetry Meetup 2024-11 @日本オラクル株式会社 オラクル青山センター 株式会社SmartHR Yosuke MATSUDA（@ymtdzzz）
2. はじめまして！ Yosuke MATSUDA（@ymtdzzz） 株式会社SmartHR プロダクトエンジニア 2024年6月までGolangで認証・OIDC周りのマイクロ サービスを書いていました。 SmartHRにジョイン後は、色々なアプリから参照される データを扱うチームで仕事をしています。 ﾜｲﾏﾂﾀﾞと読みますが、最近はﾜｲﾏﾂさんと呼ばれています。 2
3. 私とOpenTelemetryの関係 3
4. 社内でのOpenTelemetry導入（2022年頃） 記事を書いたりDatadogさんのアドカレに参加したり • 某事業会社 • チームでも取り組みつつ、 サイドプロジェクトとして 2年ほど活動 • 今日の事例1でのお話 4
5. Contributorとしての活動 5
6. Kaigi on Rails 2024+関連イベントで登 壇 資料：モノリスでも使える！ OpenTelemetryでRailsアプリのパフォーマンス分 析を始めてみよう from Kaigi on Rails 2024 資料：OpenTelemetryによるRailsアプリの計装を支える ActiveSupport::Notifications from Kaigi on Rails 2024事後勉強会 6
7. 個人開発ツール「otel-tui」 7
8. 相互運用性、標準仕様 リッチな機能、フルマネージ ド OpenTelemetry 今日話すこと SaaS 柔軟かつお手軽なオブザーバビリティ基盤 8
9. 柔軟かつお手軽 is … オブザーバビリティ基盤における • 柔軟さ with OpenTelemetry ◦ Agility：不確実性やリスクに素早く対応できる ◦ Flexibility：ベンダーやプロダクトの違いを吸収 （Agilityの前提） • お手軽さ with SaaS ◦ 運用の手間がかからない 9
10. モニタリングに限界を感じ、トレースの導入やテレメトリの関連 付けなどを検証し始めた オブザーバビリティの領域に一歩踏み出したフェーズ （知見があまりない、不安定） 今日の話のメインターゲット 特に”柔軟さとお手軽さ”が求められるフェーズ 10
11. 特に”柔軟さとお手軽さ”が求められるフェーズ 出典：AWS オブザーバビリティ成熟度モデル ※本スライドの作成者により一部修正 ログとメトリクスを収集 / 統一されていないプロダ クト / 推測に頼る調査 トレースを含むテレメトリ収 集 / アラート戦略 / デバッ グに時間がかかる テレメトリの相関 / ボトル ネックを即座に特定 / ほぼ リアルタイムに対応 問題が起こる前に対応 / シ ステムやAIによる自動分析・ 調査 11
12. 特に”柔軟さとお手軽さ”が求められるフェーズ 出典：AWS オブザーバビリティ成熟度モデル ※本スライドの作成者により一部修正 ログとメトリクスを収集 / 統一されていないプロダ クト / 推測に頼る調査 トレースを含むテレメトリ収 集 / アラート戦略 / デバッ グに時間がかかる テレメトリの相関 / ボトル ネックを即座に特定 / ほぼ リアルタイムに対応 問題が起こる前に対応 / シ ステムやAIによる自動分析・ 調査 テレメトリの関連付け トレース導入 12
13. 補足：オブザーバビリティ成熟度モデル from AWS （Observability Maturity Model） Stage 1：基礎的なモニタリング （テレメトリデータの収集） 各チームが各自でテレメトリを収集している（利用製品も統一されていない）。メトリクスとログを定義 し、収集を行っている。 推測に頼ったアラート対応。 Stage 2：中級モニタリング （テレメトリ分析とインサイト） トレースを含むテレメトリ収集を行い、それを用いたアクション可能なアラート戦略が存在する。しか し、デバッグに時間がかかり、アラート疲れの兆候もある。 このステージに留まっている企業や組織は多い。 Stage 3：高度なオブザーバビリ ティ（相関関係と異常検知） テレメトリやコンポーネント間が相関し、問題の根本原因を即座に特定できる。アノマリーの検知も行 い、問題もリアルタイムに発見し対応できる。 Stage 4：プロアクティブなオブザー バビリティ （自動的かつ事前の根本原因特 定） 問題が起こる「前」にその発生を予測し未然に防止する。システムにより自動的にテレメトリを分析 し、動的なダッシュボードにより必要な情報が提供され、関連チームは情報の取捨選択の作業が不 要になる。 出典：AWS オブザーバビリティ成熟度モデル ※表の内容は本登壇資料の作成者による要約 13
14. 使いこなせ る？ 投資効果はあ る？ 後戻りでき る？ 柔軟でない、手のかかるオブザーバビリティ基盤 14
15. Sampling Correlation Trace とりあえず 使ってみよ 柔軟かつお手軽なオブザーバビリティ基盤 15
16. Let’s play with OpenTelemetry! • 事例1：OpenTelemetryとDatadog APMで最小限のリスクでオブザーバビリティを使 い始めて普及させる [某事業会社] ◦ 概要と背景 ◦ OpenTelemetryによる計装を選ぶ理由 ◦ 構成とその注意点 ◦ 導入成果と普及活動 ◦ OpenTelemetry+Datadogの難しいところ • 事例2：ベンダーの壁をOpenTelemetry Collectorの仕組みでシュッと乗り越える [SmartHR] ◦ 概要と背景 ◦ 直面した課題 ◦ OpenTelemetry Collectorの導入（Reveiver, Exporter, Processor） ◦ 導入成果 Agility Flexibility 16
17. ご注意：用語について SaaS ベンダー独自のテレメトリ収集プロコトルが存在するSaaSの ことを指します 例：NewRelicやDatadogなど 17
18. ご注意：事例について 事例1については半年〜1年前のお話であることをご了承くだ さい ※適宜キャッチアップはしていますが、アップデートがありましたら是非お知らせください！ ベンダーへの依存を過度に避けよう！という意図はありませ ん ※あくまでも事例の一つとしてご認識くだされば幸いです 18
19. OpenTelemetryとDatadog APMで最小限のリ スクでオブザーバビリティを使い始めて普及させる 事例1 19 Agility
20. 概要 • プロダクト：ECサイト（数百~数千req/sec） • サービス構成：モノリス（PHP+Nginx）＋マイクロサービス（Golang） • 期間：2022年上旬〜2024年6月 • やったこと：OpenTelemetry+Datadog APMの導入及び推進 ※サイドプロジェクト＋自チームでの取り組みとして 20
21. 当時の構成 21
22. 当時の構成（自チームのオーナーシップ） ※モノリスは認証領域 22
23. トレース導入のきっかけ SLOやアラート調査時、サービスを跨いだ調査に時間がかかる課題 新規登録時に エラー SNSログインが遅 い OAuth開始時？ 連携後のデータ作 成？ 外部IdPへの問い合わせ？ 認証サービスへの通信？ 23
24. 何に時間がかかっていたのか 24 ログは手動で紐付け… （タブ職人）
25. 何に時間がかかっていたのか 25 トレースがそもそも無い、繋がっ ていない （ボトルネック特定に使い捨ての 計測コードを使用） ほとんど使われていない モノリス側のトレース
26. 当時の成熟度：1.5くらい？ 出典：AWS オブザーバビリティ成熟度モデル ※本スライドの作成者により一部修正 ログとメトリクスを収集 / 統一されていないプロダ クト / 推測に頼る調査 トレースを含むテレメトリ収 集 / アラート戦略 / デバッ グに時間がかかる テレメトリの相関 / ボトル ネックを即座に特定 / ほぼ リアルタイムに対応 問題が起こる前に対応 / シ ステムやAIによる自動分析・ 調査 26
27. トレース周りを整えたい！ 27
28. ざっくりロードマップ • トレースの導入と評価（使ってみる） ◦ トレースの出力、サービス間のつなぎ込み ◦ テレメトリの関連付け • （成果が出た場合）開発組織全体に横展開 →みんなが当たり前に使っている状態へ（理想） 28
29. ざっくりロードマップ • トレースの導入と評価（使ってみる） ◦ トレースの出力、サービス間のつなぎ込み ◦ テレメトリの関連付け • （成果が出た場合）開発組織全体に横展開 →みんなが当たり前に使っている状態へ（理想） 29 知見があまりない状態 からのスタート
30. スモールに始めたい！ →何で計装する？ 30
31. コンテナ 従来のログ収集（構造化ログの出力） 従来のログ収集と比べて 計装はベンダーへの実装依存度が高い 実装コード（ Golang） 任意のLoggerライブラリ （slogやzapなど） コンテナ Agent / Collector stdout stderr 31
32. コンテナ テレメトリ収集（計装） 従来のログ収集と比べて 計装はベンダーへの実装依存度が高い 実装コード（ Golang） SDK コンテナ Agent / Collector OTLP or Other formats 計装ライブラリ（ net/http） 計装ライブラリ（ sqlx） 計装ライブラリ（ redigo） 32
33. 従来のログ収集と比べて 計装はベンダーへの実装依存度が高い 計装するライブラリ数 サービス数 33
34. ベンダー切り替え時の想定作業 • 必ず生じる作業 ◦ Agentの切り替え ◦ 環境変数の変更など • 実装に依存している場合に必要な作業 ◦ 実装の修正や検証 ◦ アプリレイヤーの性能試験 ▪ テレメトリのバッファリング、送信ロ ジックの差異より 監視ベンダー切り替えや構成変更時の 移行コストが大きくなる サービス数 34
35. 1~2年後に今と同じ構成かはわからない • つい1,2年前に別の監視SaaSから乗り換えたばかり • 費用対効果が見合わないと判断される可能性 ◦ 誰も使ってくれなかった……とか ◦ 実はそこまで便利にならなかった……とか ※APM以外の機能も同様 いざというときのアジリティを損なわずに 導入検証を進めるためには？ ＋不安定なフェーズ （当時の開発組織特有の状況） 35
36. 知見の乏しい、不安定なフェーズだか らこそOpenTelemetryによる計装 を選ぶ 36
37. 計装のうち、実装に関わる部分を 標準仕様（OTel）にしておく ベンダー切り替え時の想定作業 • 必ず生じる作業 ◦ Agentの切り替え ◦ 環境変数の変更など • 実装に依存している場合に必要な作業 ◦ 実装の修正や検証 ◦ アプリレイヤーの性能試験 ▪ テレメトリのバッファリング、送信ロ ジックの差異より サービス数 37
38. ベンダー切り替え時の想定作業 • 必ず生じる作業 ◦ Agentの切り替え ◦ 環境変数の変更など • 実装に依存している場合に必要な作業 ◦ 実装の修正や検証 ◦ アプリレイヤーの性能試験 ▪ テレメトリのバッファリング、送信ロ ジックの差異より 計装のうち、実装に関わる部分を 標準仕様（OTel）にしておく サービス数 38 移行先がOTel互換であ れば実装修正不要
39. 当時の基本的なスタンス • Zero-code計装可能：どちらでも良い ◦ モノリスAppは既にDatadog計装済みなのでそれを踏襲 • Zero-code計装不可：可能な限りOTelを使う 計装のうち、実装に関わる部分を 標準仕様（OTel）にしておく 39
40. GolangのZero-code計装も進歩してきてはいる • open-telemetry/opentelemetry-go-instrumentation ◦ eBPFを利用 • alibaba/opentelemetry-go-auto-instrumentation ◦ コンパイル時に計装コードを差し込み 補足：Zero-code計装可否が全てなのか？→No 40
41. 例：スパンを手動でグルーピングしたいケース 補足：Zero-code計装可否が全てなのか？→No 以前見かけた、複雑なロジックで大量データを捌く バッチ処理のトレース 出典：Tuning GraphQL on Rails (p.37) from Kaigi on Rails 2024 41 手動計装したいケースは出てくるので、 それらの可能性を考慮した技術選定が大事
42. 構成 42
43. 構成 既にDatadog計装済み Agentはそのまま使う Agent内部でOTel→dd 形式に変換（ソース） OTelで計装 43
44. 構成 既存の計装を踏襲 （問題が起きたら置き替 えを検討） 既にDatadog計装済み Agentはそのまま使う Agent内部でOTel→dd 形式に変換（ソース） OTelで計装 44 既存のAgentを踏襲（問 題が起きたら置き替えを 検討）
45. ベンダーの境界を乗り越える プロトコルの差異 トレースコンテキスト フォーマットの差異 45
46. プロトコルの差異 46
47. プロトコルの差異 出典：OTLP Ingestion by the Datadog Agent • プロトコルの違い ◦ Datadog：独自プロトコル ◦ OpenTelemetry：OpenTelemetr y Protocol（OTLP） • Datadog AgentはOTLP互換👏 ◦ 特段障壁にならず ◦ 環境変数設定で終わり 47
48. トレースコンテキストフォーマットの差異 48
49. • トレースコンテキスト ◦ サービスを跨いだトレース伝搬（Context Propagation）のため に必要な情報（Trace IDやSpan IDなどの情報） ◦ 各サービスでコンテキストをInject, Extractして伝搬させる トレースコンテキストフォーマットの差異 伝搬できている 伝搬できていない 49
50. • 通信方向に応じたInject, Extractを考慮する必要がある トレースコンテキストフォーマットの差異 50 Datadog計装 （モノリス App） OTel計装 （マイクロサービス） Inject Extract Extract Inject Message （HTTP, gRPC etc.） Message （HTTP, gRPC etc.） Context Context
51. • できれば標準仕様のW3C Trace Contextを使いたい • 当時はDatadog計装では非対応… トレースコンテキストフォーマットの差異 51 W3C Trace Contextによるヘッダー例 Datadog計装 （モノリス App） Inject, Extract不可 （≒トレース繋がらない）
52. • dd-trace-phpにIssueを投げました（2022年11月頃） トレースコンテキストフォーマットの差異 52 Datadog計装でW3C Trace Contextを理解 できるようにして！
53. • 爆速で対応いただいた（2023年1月）👏 ◦ ロードマップに入ってたっぽい トレースコンテキストフォーマットの差異 53
54. • Datadog側の対応のおかげで、双方向でW3C Trace Contextを利用 トレース繋がった👍 トレースコンテキストフォーマットの差異 54
55. • Datadog側でログのTrace IDとSpan IDを紐付けてもらう • OTel計装のTrace IDとSpan IDは変換が必要 ※今は不要になってそうです（後述） トレースとログの紐付け 55 Log (JSON) Trace ID: 32Hex（uint128） Span: 16Hex（uint64） Log (JSON) Trace ID: uint64 Span: uint64
56. Golang（OTel計装） • OTel SDKと構造化 Loggerで変換したTrace IDとSpan IDを差し込む トレースとログの紐付け 56
57. PHP（Datadog計装） • 変換は不要 • 構造化されていないので DatadogのGrok Parserでマッピング トレースとログの紐付け 57
58. Nginx（openresty） • アクセスログと紐付けたい ◦ 500エラーから根本原因を知る ◦ アプリエラーからユーザー影響を知る トレースとログの紐付け 58
59. Nginx（openresty） • Datadog Nginx moduleをまず検討→Openrestyでは上手く動かず OpenTelemetry Nginx moduleを使うことにした トレースとログの紐付け 59
60. Nginx（openresty） • バージョン合わず結局ソースビルドorz • 長大なDockerfileで頑張る 血と涙の結晶1（当時書いたブログより）→ トレースとログの紐付け 60
61. Nginx（openresty） • Datadog形式への変換どうする？ ◦ Luaを書くorz ◦ confでmoduleとLuaを読み込ん でLogに出力（記憶が完全に揮発し たのでコード割愛） • 負荷試験をした上でリリース（CPU使用 率が微増した程度） 血と涙の結晶2（記憶を頼りにLuaを復活 w/ ChatGPT）→ ※多分間違っているので雰囲気だけ トレースとログの紐付け 61
62. nginxinc/nginx-otel • 公式という安心感 • パフォーマンスの向上（3rd-partyと比較して） • パッケージマネージャーで簡単に導入可能 ※Openrestyを使っていたり、サポートバージョン次第では相変わらず ソースビルドは必要になるかも（未検証） 補足：今は公式のnginx-otelを使いましょう 62
63. 補足：TraceIDとSpanIDの変換は もう不要になっているかも 出典：Correlating OpenTelemetry Traces and Logs 63
64. ログとトレースが繋がった！ 64
65. 導入後の話 65
66. 調査のつらみが軽減 • つらみ1：トレース情報が無く、計測コードを手動で仕込んでいる ◦ パフォーマンス上のボトルネックが一目でわかるようになった ◦ 改善効果など確度の高い状態で改善を行える • つらみ2：ログを手動で関連付けている ◦ 欲しい情報が一発で手に入るようになった APM用途よりもログ紐付けで役立つ場面が多かった印象 66
67. 開発組織への浸透 67 • アラートチャンネルを見張って調査スレに突撃した ◦ 自分も調査に参加してトレースや関連付けを認知してもらう ◦ PHPアップデートの並行稼働時のエラー調査で大活躍 • サイドプロジェクトにメンバーを募り、持ち帰ってもらう ◦ ガイドラインの作成 ◦ 決済サービスなど他チームにも波及 • （前職の同僚のXを見てても）多分ガッツリ使ってくれてそう！
68. 成熟度の前進：2.1くらい？ 出典：AWS オブザーバビリティ成熟度モデル ※本スライドの作成者により一部修正 ログとメトリクスを収集 / 統一されていないプロダ クト / 推測に頼る調査 トレースを含むテレメトリ収 集 / アラート戦略 / デバッ グに時間がかかる テレメトリの相関 / ボトル ネックを即座に特定 / ほぼ リアルタイムに対応 問題が起こる前に対応 / シ ステムやAIによる自動分析・ 調査 68
69. 成熟度の前進：2.1くらい？ 出典：AWS オブザーバビリティ成熟度モデル ※本スライドの作成者により一部修正 ログとメトリクスを収集 / 統一されていないプロダ クト / 推測に頼る調査 トレースを含むテレメトリ収 集 / アラート戦略 / デバッ グに時間がかかる テレメトリの相関 / ボトル ネックを即座に特定 / ほぼ リアルタイムに対応 問題が起こる前に対応 / シ ステムやAIによる自動分析・ 調査 オブザーバビリティの一歩を踏み出せた！ 69
70. 運用 • OTel SDKのアップデート、Deprecated対応（他ライブラリと同様） ◦ gRPC stats handlerへの移行時にFilterが無かったのでPRを 投げたり 70
71. 運用 • OpenTelemetry bridgeによるCloud SDKのトレース対応 ◦ Spannerのトランザクション中のリトライイベントなどを追う ※現在のSpanner ClientはOpenTelemetry対応済みなのでbridge不要 71
72. ベンダー毎のサンプリングを考慮しなければならない • ミスると正しいデータが取れなくなる恐れがある ベンダーのドキュメントをちゃんと読みましょう！ OpenTelemetry+Datadogの難しいと ころ APM（Trace）Metricsの測定対象 72
73. ベンダー毎のサンプリングを考慮しなければならない • 当時の運用 できるだけ後ろから絞るようにする（コントロールしやすい） OpenTelemetry+Datadogの難しいと ころ 73 フィルタリングのみ サンプリング無し デフォルト運用 （DD_APM_MAX_TPS） ・インテリジェント保持フィルター ・必要に応じてカスタム保持フィルター
74. 互換性の問題 • net/httpのOTel計装ライブラリで出したSpan名が上手く出てくれな い • EchoのOTel計装ライブラリだと{method} {path}で出てくれる OpenTelemetry+Datadogの難しいと ころ 74
75. 互換性の問題 • ローカルのJaeger等で表示しても、UIにマッピングされているの で他計装との違いがわかりにくい • Debug Exporterならある程度可読性は高いが、Collectorの設 定が必要（config.yaml書いたり） プリミティブなOTLPをサクッと確認したい →otel-tui開発のきっかけ OpenTelemetry+Datadogの難しいと ころ 75
76. 補足：otel-tuiで計装差分をデバッグする net/http（上手く表示されない） echo（上手く表示される） http.routeがある http.routeがない 76
77. 結局移行は発生したの？ 77
78. 執筆時点でDatadogをやめたという話は 聞いておりません👍 78
79. Kaigi on Rails事後勉強会での雑談時に聞いた事例 • Rails+Goのマイクロサービス構成 • ある監視SaaSに、OpenTelemetryで計装（今回の事例と同じ） でも…… 79
80. Kaigi on Rails事後勉強会での雑談時に聞いた事例 • Rails+Goのマイクロサービス構成 • ある監視SaaSに、OpenTelemetryで計装（今回の事例と同じ） • 活用のされ方などを鑑みて、そのSaaSをやめてCloud Traceに 移行 でも…… 80
81. Kaigi on Rails事後勉強会での雑談時に聞いた事例 • Rails+Goのマイクロサービス構成 • ある監視SaaSに、OpenTelemetryで計装（今回の事例と同じ） • 活用のされ方などを鑑みて、そのSaaSをやめてCloud Traceに 移行 ゴクリ…… でも…… 81
82. 事例1：まとめ • OpenTelemetryとSaaSを組み合わせて運用することは十分可能 ◦ 知見の少ない、不安定なフェーズで採用するのはむしろあり ◦ 今はもっとスムーズな連携ができるようになっています（ログ周りなど） • 互換性については下記の点を要チェック ◦ トレースフォーマット（SaaS側がOTLPに対応しているか？） ◦ トレースコンテキストフォーマット ▪ 双方向の通信でそれぞれInject, Extract可能か？ ▪ W3C Trace Contextに対応していれば基本大丈夫です • 前のめりに活用して浸透させましょう✌ 82
83. ベンダーの壁をOpenTelemetry Collectorの 仕組みで乗り越える 事例2 83 Flexibility
84. • SmartHRでの事例 ◦ 社内でのアプリケーションの計装はNewRelic（独自 フォーマットによる計装） • 2024年7月にプロダクトサイドのエンジニアとして入社 OpenTelemetryとの接点はあまりない 84
85. 気付いたらOpenTelemetryのCustom Collectorをビルドしていた！！ 入社後数ヶ月程経ったある日 …… 85
86. きっかけ 86
87. きっかけ コネクションプーラーの 導入 87
88. きっかけ • プロセス単位のプーリング、PostgreSQLサイドのコネク ション数緩和の限界 • 様々な背景から緊急度が高まり、スピーディーな導入が求 められる状況 88
89. 技術構成 • Software: postgresml/pgcat ◦ Rust製のコネクションプーラー • VM: Compute Engine ◦ TCP接続が必要なため ◦ Blue/Green構成（Managed Instance Group） • Platform: Docker Container on Container-Optimized OS • Monitoring: Cloud Monitoring 89
90. 課題：pgcatのメトリクス収集 • pgcatのメトリクスはPrometheus Endpointで公開 • Compute Engineではメトリクス収集にはOps Agentの利 用が推奨されている 出典：Google Cloud Observability エージェント 90
91. 課題：pgcatのメトリクス収集 • しかし、Container-Optimized OS上でOps Agentは動かない 出典：Ops エージェントの概要 出典：Github issue: Support for Google Container-Optimized OS 91
92. 課題：pgcatのメトリクス収集 • なんかいい方法無い？と相談される（ここからサポート役として参戦） • OTel Collector使えばできそうだったので検証する ◦ できたので記事を書いた 出典：COS上のアプリのPrometheus MetricsをCloud Monitoringに送る 92
93. OpenTelemetry Collector 出典：Collector | OpenTelemetry 93
94. 可能性は無限大 • Receivers：99+ • Processors：27+ • Exporters：127+ ※opentelemetry.io repoで下記のコマンドで集計（2024/11/10） yq '. | select(.registryType == "receiver")' ./data/registry/*.yml | yq ea '[.] | length' 94
95. • Google Cloud Exporter • AWS CloudWatch Logs Exporter 多くのComponentで関連企業のエンジニアが Code Ownerになっているので安心！ 出典：Contrib repository for the OpenTelemetry Collector ←googlerがいる ←AWSの人がいる 95
96. 今回の構成 96
97. OpenTelemetry Collector BuilderによるCollector作成 97
98. OpenTelemetry Collector BuilderによるCollector作成 ※最小の構成例 98
99. OpenTelemetry Collector BuilderによるCollecor作成 99
100. デプロイ（サイドカー構成） • cloud-initでsystemdのユニット ファイルを定義（1コンテナ1サービ ス） 出典：COS上のアプリのPrometheus MetricsをCloud Monitoringに送る 100
101. Resource Detection Processor 101
102. Resource Detection Processor • OSやPlatformなど、動作環境に関わる情報を自動取得しResource Attributesとしてテレメトリにセット（AWSやAzure、k8sなど） ※参考画像：opentelemetry-demoのテレメトリをotel-tuiで表示 102
103. Resource Detection Processor • Cloud Monitoring側でリソースとして自動認識👍 103
104. Resource Detection Processor • 最低限のDimensionも自動で識別 ◦ MIG単位（Blue / Green） ◦ Role単位（Primary / Replica） ◦ Host単位 ◦ など 104
105. 推奨パターンから外れる懸念について • Google Cloudのサポートにもご相談したところ OpenTelemetry Collectorをおすすめされる ◦ 回答の参考資料に自分が書いたブログを引用いただくとい うエピソードもありました✨ 105
106. OpenTelemetryの予備知識のおかげで シュッと導入できた • 相談が来てから大体2週間くらいでメトリクス収集＋デプ ロイ可能な状態になっていた ◦ 並行でVMのリリースフロー整備や負荷試験等も行っ ていたので実働時間はもっと少なそう！ 106
107. OpenTelemetry Collectorが無かっ たら…… • Container-Optimized OS以外のOSを利用 ◦ Docker Engine、VM Managerなど構成管理が複雑化 ◦ 設定漏れ等によるセキュリティリスク 出典：Container-Optimized OS の概要 | Google Cloud 107
108. ありがとうOpenTelemetry✨ 108
109. 事例2：まとめ • OpenTelemetryの豊富なComponentを組み合わせることで、プロダ クトやベンダーの差異を吸収しテレメトリ収集することが可能になる ◦ Receiver（Pull, Push問わず）, Exporter ◦ Resource Detection Processorでプロダクトやベンダー特有の 情報もよしなに収集→Cloud Monitoringと調和 • OpenTelemetryでできることを知っておけば、いざというときに武器 になる💪 109
110. OpenTelemetryがもたらす柔軟さ ◦ Agility：不確実性やリスクに素早く対応できる →事例1：OpenTelemetry+Datadogの話 ◦ Flexibility：ベンダーやプロダクトの違いを吸収（相互 運用性） →事例2：OpenTelemtry Collectorの話 今日話したこと 110
111. OpenTelemetryがもたらす柔軟さ ◦ Agility：不確実性やリスクに素早く対応できる →事例1：OpenTelemetry+Datadogの話 ◦ Flexibility：ベンダーやプロダクトの違いを吸収（相互 運用性） →事例2：OpenTelemtry Collectorの話 柔軟かつお手軽なオブザーバビリティ基盤を作って…… 今日話したこと 111
112. Sampling Correlation Trace 気軽に使っていきましょう！ 112 柔軟かつお手軽なオブザーバビリティ基盤
113. ありがとうございました！ 113