Building Observability Infrastructure with OpenTelemetry and SaaS

Slide 1

Slide 1 text

OpenTelemetryとSaaSの “良いとこ取り”で構築する柔軟なオブザーバビリティ基盤 2024.11.20 Wed. OpenTelemetry Meetup 2024-11 @日本オラクル株式会社オラクル青山センター株式会社SmartHR Yosuke MATSUDA（@ymtdzzz）

Slide 2

Slide 2 text

はじめまして！ Yosuke MATSUDA（@ymtdzzz）株式会社SmartHR プロダクトエンジニア 2024年6月までGolangで認証・OIDC周りのマイクロサービスを書いていました。 SmartHRにジョイン後は、色々なアプリから参照されるデータを扱うチームで仕事をしています。ﾜｲﾏﾂﾀﾞと読みますが、最近はﾜｲﾏﾂさんと呼ばれています。 2

Slide 3

Slide 3 text

私とOpenTelemetryの関係 3

Slide 4

Slide 4 text

社内でのOpenTelemetry導入（2022年頃）記事を書いたりDatadogさんのアドカレに参加したり ● 某事業会社 ● チームでも取り組みつつ、サイドプロジェクトとして 2年ほど活動 ● 今日の事例1でのお話 4

Slide 5

Slide 5 text

Contributorとしての活動 5

Slide 6

Slide 6 text

Kaigi on Rails 2024+関連イベントで登壇資料：モノリスでも使える！ OpenTelemetryでRailsアプリのパフォーマンス分析を始めてみよう from Kaigi on Rails 2024 資料：OpenTelemetryによるRailsアプリの計装を支える ActiveSupport::Notiﬁcations from Kaigi on Rails 2024事後勉強会 6

Slide 7

Slide 7 text

個人開発ツール「otel-tui」 7

Slide 8

Slide 8 text

相互運用性、標準仕様リッチな機能、フルマネージド OpenTelemetry 今日話すこと SaaS 柔軟かつお手軽なオブザーバビリティ基盤 8

Slide 9

Slide 9 text

柔軟かつお手軽 is … オブザーバビリティ基盤における ● 柔軟さ with OpenTelemetry ○ Agility：不確実性やリスクに素早く対応できる ○ Flexibility：ベンダーやプロダクトの違いを吸収（Agilityの前提） ● お手軽さ with SaaS ○ 運用の手間がかからない 9

Slide 10

Slide 10 text

モニタリングに限界を感じ、トレースの導入やテレメトリの関連付けなどを検証し始めたオブザーバビリティの領域に一歩踏み出したフェーズ（知見があまりない、不安定）今日の話のメインターゲット特に”柔軟さとお手軽さ”が求められるフェーズ 10

Slide 11

Slide 11 text

特に”柔軟さとお手軽さ”が求められるフェーズ出典：AWS オブザーバビリティ成熟度モデル ※本スライドの作成者により一部修正ログとメトリクスを収集 / 統一されていないプロダクト / 推測に頼る調査トレースを含むテレメトリ収集 / アラート戦略 / デバッグに時間がかかるテレメトリの相関 / ボトルネックを即座に特定 / ほぼリアルタイムに対応問題が起こる前に対応 / システムやAIによる自動分析・調査 11

Slide 12

Slide 12 text

Slide 13

Slide 13 text

補足：オブザーバビリティ成熟度モデル from AWS （Observability Maturity Model） Stage 1：基礎的なモニタリング（テレメトリデータの収集）各チームが各自でテレメトリを収集している（利用製品も統一されていない）。メトリクスとログを定義し、収集を行っている。推測に頼ったアラート対応。 Stage 2：中級モニタリング（テレメトリ分析とインサイト）トレースを含むテレメトリ収集を行い、それを用いたアクション可能なアラート戦略が存在する。しかし、デバッグに時間がかかり、アラート疲れの兆候もある。このステージに留まっている企業や組織は多い。 Stage 3：高度なオブザーバビリティ（相関関係と異常検知）テレメトリやコンポーネント間が相関し、問題の根本原因を即座に特定できる。アノマリーの検知も行い、問題もリアルタイムに発見し対応できる。 Stage 4：プロアクティブなオブザーバビリティ（自動的かつ事前の根本原因特定）問題が起こる「前」にその発生を予測し未然に防止する。システムにより自動的にテレメトリを分析し、動的なダッシュボードにより必要な情報が提供され、関連チームは情報の取捨選択の作業が不要になる。出典：AWS オブザーバビリティ成熟度モデル ※表の内容は本登壇資料の作成者による要約 13

Slide 14

Slide 14 text

使いこなせる？投資効果はある？後戻りできる？柔軟でない、手のかかるオブザーバビリティ基盤 14

Slide 15

Slide 15 text

Sampling Correlation Trace とりあえず使ってみよ柔軟かつお手軽なオブザーバビリティ基盤 15

Slide 16

Slide 16 text

Let’s play with OpenTelemetry! ● 事例1：OpenTelemetryとDatadog APMで最小限のリスクでオブザーバビリティを使い始めて普及させる [某事業会社] ○ 概要と背景 ○ OpenTelemetryによる計装を選ぶ理由 ○ 構成とその注意点 ○ 導入成果と普及活動 ○ OpenTelemetry+Datadogの難しいところ ● 事例2：ベンダーの壁をOpenTelemetry Collectorの仕組みでシュッと乗り越える [SmartHR] ○ 概要と背景 ○ 直面した課題 ○ OpenTelemetry Collectorの導入（Reveiver, Exporter, Processor） ○ 導入成果 Agility Flexibility 16

Slide 17

Slide 17 text

ご注意：用語について SaaS ベンダー独自のテレメトリ収集プロコトルが存在するSaaSのことを指します例：NewRelicやDatadogなど 17

Slide 18

Slide 18 text

ご注意：事例について事例1については半年〜1年前のお話であることをご了承ください ※適宜キャッチアップはしていますが、アップデートがありましたら是非お知らせください！ベンダーへの依存を過度に避けよう！という意図はありません ※あくまでも事例の一つとしてご認識くだされば幸いです 18

Slide 19

Slide 19 text

OpenTelemetryとDatadog APMで最小限のリスクでオブザーバビリティを使い始めて普及させる事例1 19 Agility

Slide 20

Slide 20 text

概要 ● プロダクト：ECサイト（数百~数千req/sec） ● サービス構成：モノリス（PHP+Nginx）＋マイクロサービス（Golang） ● 期間：2022年上旬〜2024年6月 ● やったこと：OpenTelemetry+Datadog APMの導入及び推進 ※サイドプロジェクト＋自チームでの取り組みとして 20

Slide 21

Slide 21 text

当時の構成 21

Slide 22

Slide 22 text

当時の構成（自チームのオーナーシップ） ※モノリスは認証領域 22

Slide 23

Slide 23 text

トレース導入のきっかけ SLOやアラート調査時、サービスを跨いだ調査に時間がかかる課題新規登録時にエラー SNSログインが遅い OAuth開始時？連携後のデータ作成？外部IdPへの問い合わせ？認証サービスへの通信？ 23

Slide 24

Slide 24 text

何に時間がかかっていたのか 24 ログは手動で紐付け… （タブ職人）

Slide 25

Slide 25 text

何に時間がかかっていたのか 25 トレースがそもそも無い、繋がっていない（ボトルネック特定に使い捨ての計測コードを使用）ほとんど使われていないモノリス側のトレース

Slide 26

Slide 26 text

当時の成熟度：1.5くらい？出典：AWS オブザーバビリティ成熟度モデル ※本スライドの作成者により一部修正ログとメトリクスを収集 / 統一されていないプロダクト / 推測に頼る調査トレースを含むテレメトリ収集 / アラート戦略 / デバッグに時間がかかるテレメトリの相関 / ボトルネックを即座に特定 / ほぼリアルタイムに対応問題が起こる前に対応 / システムやAIによる自動分析・調査 26

Slide 27

Slide 27 text

トレース周りを整えたい！ 27

Slide 28

Slide 28 text

ざっくりロードマップ ● トレースの導入と評価（使ってみる） ○ トレースの出力、サービス間のつなぎ込み ○ テレメトリの関連付け ● （成果が出た場合）開発組織全体に横展開 →みんなが当たり前に使っている状態へ（理想） 28

Slide 29

Slide 29 text

ざっくりロードマップ ● トレースの導入と評価（使ってみる） ○ トレースの出力、サービス間のつなぎ込み ○ テレメトリの関連付け ● （成果が出た場合）開発組織全体に横展開 →みんなが当たり前に使っている状態へ（理想） 29 知見があまりない状態からのスタート

Slide 30

Slide 30 text

スモールに始めたい！ →何で計装する？ 30

Slide 31

Slide 31 text

コンテナ従来のログ収集（構造化ログの出力）従来のログ収集と比べて計装はベンダーへの実装依存度が高い実装コード（ Golang）任意のLoggerライブラリ（slogやzapなど）コンテナ Agent / Collector stdout stderr 31

Slide 32

Slide 32 text

コンテナテレメトリ収集（計装）従来のログ収集と比べて計装はベンダーへの実装依存度が高い実装コード（ Golang） SDK コンテナ Agent / Collector OTLP or Other formats 計装ライブラリ（ net/http）計装ライブラリ（ sqlx）計装ライブラリ（ redigo） 32

Slide 33

Slide 33 text

従来のログ収集と比べて計装はベンダーへの実装依存度が高い計装するライブラリ数サービス数 33

Slide 34

Slide 34 text

ベンダー切り替え時の想定作業 ● 必ず生じる作業 ○ Agentの切り替え ○ 環境変数の変更など ● 実装に依存している場合に必要な作業 ○ 実装の修正や検証 ○ アプリレイヤーの性能試験 ■ テレメトリのバッファリング、送信ロジックの差異より監視ベンダー切り替えや構成変更時の移行コストが大きくなるサービス数 34

Slide 35

Slide 35 text

1~2年後に今と同じ構成かはわからない ● つい1,2年前に別の監視SaaSから乗り換えたばかり ● 費用対効果が見合わないと判断される可能性 ○ 誰も使ってくれなかった……とか ○ 実はそこまで便利にならなかった……とか ※APM以外の機能も同様いざというときのアジリティを損なわずに導入検証を進めるためには？＋不安定なフェーズ（当時の開発組織特有の状況） 35

Slide 36

Slide 36 text

知見の乏しい、不安定なフェーズだからこそOpenTelemetryによる計装を選ぶ 36

Slide 37

Slide 37 text

計装のうち、実装に関わる部分を標準仕様（OTel）にしておくベンダー切り替え時の想定作業 ● 必ず生じる作業 ○ Agentの切り替え ○ 環境変数の変更など ● 実装に依存している場合に必要な作業 ○ 実装の修正や検証 ○ アプリレイヤーの性能試験 ■ テレメトリのバッファリング、送信ロジックの差異よりサービス数 37

Slide 38

Slide 38 text

ベンダー切り替え時の想定作業 ● 必ず生じる作業 ○ Agentの切り替え ○ 環境変数の変更など ● 実装に依存している場合に必要な作業 ○ 実装の修正や検証 ○ アプリレイヤーの性能試験 ■ テレメトリのバッファリング、送信ロジックの差異より計装のうち、実装に関わる部分を標準仕様（OTel）にしておくサービス数 38 移行先がOTel互換であれば実装修正不要

Slide 39

Slide 39 text

当時の基本的なスタンス ● Zero-code計装可能：どちらでも良い ○ モノリスAppは既にDatadog計装済みなのでそれを踏襲 ● Zero-code計装不可：可能な限りOTelを使う計装のうち、実装に関わる部分を標準仕様（OTel）にしておく 39

Slide 40

Slide 40 text

GolangのZero-code計装も進歩してきてはいる ● open-telemetry/opentelemetry-go-instrumentation ○ eBPFを利用 ● alibaba/opentelemetry-go-auto-instrumentation ○ コンパイル時に計装コードを差し込み補足：Zero-code計装可否が全てなのか？→No 40

Slide 41

Slide 41 text

例：スパンを手動でグルーピングしたいケース補足：Zero-code計装可否が全てなのか？→No 以前見かけた、複雑なロジックで大量データを捌くバッチ処理のトレース出典：Tuning GraphQL on Rails (p.37) from Kaigi on Rails 2024 41 手動計装したいケースは出てくるので、それらの可能性を考慮した技術選定が大事

Slide 42

Slide 42 text

構成 42

Slide 43

Slide 43 text

構成既にDatadog計装済み Agentはそのまま使う Agent内部でOTel→dd 形式に変換（ソース） OTelで計装 43

Slide 44

Slide 44 text

構成既存の計装を踏襲（問題が起きたら置き替えを検討）既にDatadog計装済み Agentはそのまま使う Agent内部でOTel→dd 形式に変換（ソース） OTelで計装 44 既存のAgentを踏襲（問題が起きたら置き替えを検討）

Slide 45

Slide 45 text

ベンダーの境界を乗り越えるプロトコルの差異トレースコンテキストフォーマットの差異 45

Slide 46

Slide 46 text

プロトコルの差異 46

Slide 47

Slide 47 text

プロトコルの差異出典：OTLP Ingestion by the Datadog Agent ● プロトコルの違い ○ Datadog：独自プロトコル ○ OpenTelemetry：OpenTelemetr y Protocol（OTLP） ● Datadog AgentはOTLP互換👏 ○ 特段障壁にならず ○ 環境変数設定で終わり 47

Slide 48

Slide 48 text

トレースコンテキストフォーマットの差異 48

Slide 49

Slide 49 text

● トレースコンテキスト ○ サービスを跨いだトレース伝搬（Context Propagation）のために必要な情報（Trace IDやSpan IDなどの情報） ○ 各サービスでコンテキストをInject, Extractして伝搬させるトレースコンテキストフォーマットの差異伝搬できている伝搬できていない 49

Slide 50

Slide 50 text

● 通信方向に応じたInject, Extractを考慮する必要があるトレースコンテキストフォーマットの差異 50 Datadog計装（モノリス App） OTel計装（マイクロサービス） Inject Extract Extract Inject Message （HTTP, gRPC etc.） Message （HTTP, gRPC etc.） Context Context

Slide 51

Slide 51 text

● できれば標準仕様のW3C Trace Contextを使いたい ● 当時はDatadog計装では非対応… トレースコンテキストフォーマットの差異 51 W3C Trace Contextによるヘッダー例 Datadog計装（モノリス App） Inject, Extract不可（≒トレース繋がらない）

Slide 52

Slide 52 text

● dd-trace-phpにIssueを投げました（2022年11月頃）トレースコンテキストフォーマットの差異 52 Datadog計装でW3C Trace Contextを理解できるようにして！

Slide 53

Slide 53 text

● 爆速で対応いただいた（2023年1月）👏 ○ ロードマップに入ってたっぽいトレースコンテキストフォーマットの差異 53

Slide 54

Slide 54 text

● Datadog側の対応のおかげで、双方向でW3C Trace Contextを利用トレース繋がった👍 トレースコンテキストフォーマットの差異 54

Slide 55

Slide 55 text

● 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

Slide 56

Slide 56 text

Golang（OTel計装） ● OTel SDKと構造化 Loggerで変換したTrace IDとSpan IDを差し込むトレースとログの紐付け 56

Slide 57

Slide 57 text

PHP（Datadog計装） ● 変換は不要 ● 構造化されていないので DatadogのGrok Parserでマッピングトレースとログの紐付け 57

Slide 58

Slide 58 text

Nginx（openresty） ● アクセスログと紐付けたい ○ 500エラーから根本原因を知る ○ アプリエラーからユーザー影響を知るトレースとログの紐付け 58

Slide 59

Slide 59 text

Nginx（openresty） ● Datadog Nginx moduleをまず検討→Openrestyでは上手く動かず OpenTelemetry Nginx moduleを使うことにしたトレースとログの紐付け 59

Slide 60

Slide 60 text

Nginx（openresty） ● バージョン合わず結局ソースビルドorz ● 長大なDockerfileで頑張る血と涙の結晶1（当時書いたブログより）→ トレースとログの紐付け 60

Slide 61

Slide 61 text

Nginx（openresty） ● Datadog形式への変換どうする？ ○ Luaを書くorz ○ confでmoduleとLuaを読み込んでLogに出力（記憶が完全に揮発したのでコード割愛） ● 負荷試験をした上でリリース（CPU使用率が微増した程度）血と涙の結晶2（記憶を頼りにLuaを復活 w/ ChatGPT）→ ※多分間違っているので雰囲気だけトレースとログの紐付け 61

Slide 62

Slide 62 text

nginxinc/nginx-otel ● 公式という安心感 ● パフォーマンスの向上（3rd-partyと比較して） ● パッケージマネージャーで簡単に導入可能 ※Openrestyを使っていたり、サポートバージョン次第では相変わらずソースビルドは必要になるかも（未検証）補足：今は公式のnginx-otelを使いましょう 62

Slide 63

Slide 63 text

補足：TraceIDとSpanIDの変換はもう不要になっているかも出典：Correlating OpenTelemetry Traces and Logs 63

Slide 64

Slide 64 text

ログとトレースが繋がった！ 64

Slide 65

Slide 65 text

導入後の話 65

Slide 66

Slide 66 text

調査のつらみが軽減 ● つらみ1：トレース情報が無く、計測コードを手動で仕込んでいる ○ パフォーマンス上のボトルネックが一目でわかるようになった ○ 改善効果など確度の高い状態で改善を行える ● つらみ2：ログを手動で関連付けている ○ 欲しい情報が一発で手に入るようになった APM用途よりもログ紐付けで役立つ場面が多かった印象 66

Slide 67

Slide 67 text

開発組織への浸透 67 ● アラートチャンネルを見張って調査スレに突撃した ○ 自分も調査に参加してトレースや関連付けを認知してもらう ○ PHPアップデートの並行稼働時のエラー調査で大活躍 ● サイドプロジェクトにメンバーを募り、持ち帰ってもらう ○ ガイドラインの作成 ○ 決済サービスなど他チームにも波及 ● （前職の同僚のXを見てても）多分ガッツリ使ってくれてそう！

Slide 68

Slide 68 text

成熟度の前進：2.1くらい？出典：AWS オブザーバビリティ成熟度モデル ※本スライドの作成者により一部修正ログとメトリクスを収集 / 統一されていないプロダクト / 推測に頼る調査トレースを含むテレメトリ収集 / アラート戦略 / デバッグに時間がかかるテレメトリの相関 / ボトルネックを即座に特定 / ほぼリアルタイムに対応問題が起こる前に対応 / システムやAIによる自動分析・調査 68

Slide 69

Slide 69 text

Slide 70

Slide 70 text

運用 ● OTel SDKのアップデート、Deprecated対応（他ライブラリと同様） ○ gRPC stats handlerへの移行時にFilterが無かったのでPRを投げたり 70

Slide 71

Slide 71 text

運用 ● OpenTelemetry bridgeによるCloud SDKのトレース対応 ○ Spannerのトランザクション中のリトライイベントなどを追う ※現在のSpanner ClientはOpenTelemetry対応済みなのでbridge不要 71

Slide 72

Slide 72 text

ベンダー毎のサンプリングを考慮しなければならない ● ミスると正しいデータが取れなくなる恐れがあるベンダーのドキュメントをちゃんと読みましょう！ OpenTelemetry+Datadogの難しいところ APM（Trace）Metricsの測定対象 72

Slide 73

Slide 73 text

ベンダー毎のサンプリングを考慮しなければならない ● 当時の運用できるだけ後ろから絞るようにする（コントロールしやすい） OpenTelemetry+Datadogの難しいところ 73 フィルタリングのみサンプリング無しデフォルト運用（DD_APM_MAX_TPS）・インテリジェント保持フィルター・必要に応じてカスタム保持フィルター

Slide 74

Slide 74 text

互換性の問題 ● net/httpのOTel計装ライブラリで出したSpan名が上手く出てくれない ● EchoのOTel計装ライブラリだと{method} {path}で出てくれる OpenTelemetry+Datadogの難しいところ 74

Slide 75

Slide 75 text

互換性の問題 ● ローカルのJaeger等で表示しても、UIにマッピングされているので他計装との違いがわかりにくい ● Debug Exporterならある程度可読性は高いが、Collectorの設定が必要（config.yaml書いたり）プリミティブなOTLPをサクッと確認したい →otel-tui開発のきっかけ OpenTelemetry+Datadogの難しいところ 75

Slide 76

Slide 76 text

補足：otel-tuiで計装差分をデバッグする net/http（上手く表示されない） echo（上手く表示される） http.routeがある http.routeがない 76

Slide 77

Slide 77 text

結局移行は発生したの？ 77

Slide 78

Slide 78 text

執筆時点でDatadogをやめたという話は聞いておりません👍 78

Slide 79

Slide 79 text

Kaigi on Rails事後勉強会での雑談時に聞いた事例 ● Rails+Goのマイクロサービス構成 ● ある監視SaaSに、OpenTelemetryで計装（今回の事例と同じ）でも…… 79

Slide 80

Slide 80 text

Kaigi on Rails事後勉強会での雑談時に聞いた事例 ● Rails+Goのマイクロサービス構成 ● ある監視SaaSに、OpenTelemetryで計装（今回の事例と同じ） ● 活用のされ方などを鑑みて、そのSaaSをやめてCloud Traceに移行でも…… 80

Slide 81

Slide 81 text

Kaigi on Rails事後勉強会での雑談時に聞いた事例 ● Rails+Goのマイクロサービス構成 ● ある監視SaaSに、OpenTelemetryで計装（今回の事例と同じ） ● 活用のされ方などを鑑みて、そのSaaSをやめてCloud Traceに移行ゴクリ…… でも…… 81

Slide 82

Slide 82 text

事例1：まとめ ● OpenTelemetryとSaaSを組み合わせて運用することは十分可能 ○ 知見の少ない、不安定なフェーズで採用するのはむしろあり ○ 今はもっとスムーズな連携ができるようになっています（ログ周りなど） ● 互換性については下記の点を要チェック ○ トレースフォーマット（SaaS側がOTLPに対応しているか？） ○ トレースコンテキストフォーマット ■ 双方向の通信でそれぞれInject, Extract可能か？ ■ W3C Trace Contextに対応していれば基本大丈夫です ● 前のめりに活用して浸透させましょう✌ 82

Slide 83

Slide 83 text

ベンダーの壁をOpenTelemetry Collectorの仕組みで乗り越える事例2 83 Flexibility

Slide 84

Slide 84 text

● SmartHRでの事例 ○ 社内でのアプリケーションの計装はNewRelic（独自フォーマットによる計装） ● 2024年7月にプロダクトサイドのエンジニアとして入社 OpenTelemetryとの接点はあまりない 84

Slide 85

Slide 85 text

気付いたらOpenTelemetryのCustom Collectorをビルドしていた！！入社後数ヶ月程経ったある日 …… 85

Slide 86

Slide 86 text

きっかけ 86

Slide 87

Slide 87 text

きっかけコネクションプーラーの導入 87

Slide 88

Slide 88 text

きっかけ ● プロセス単位のプーリング、PostgreSQLサイドのコネクション数緩和の限界 ● 様々な背景から緊急度が高まり、スピーディーな導入が求められる状況 88

Slide 89

Slide 89 text

技術構成 ● Software: postgresml/pgcat ○ Rust製のコネクションプーラー ● VM: Compute Engine ○ TCP接続が必要なため ○ Blue/Green構成（Managed Instance Group） ● Platform: Docker Container on Container-Optimized OS ● Monitoring: Cloud Monitoring 89

Slide 90

Slide 90 text

課題：pgcatのメトリクス収集 ● pgcatのメトリクスはPrometheus Endpointで公開 ● Compute Engineではメトリクス収集にはOps Agentの利用が推奨されている出典：Google Cloud Observability エージェント 90

Slide 91

Slide 91 text

課題：pgcatのメトリクス収集 ● しかし、Container-Optimized OS上でOps Agentは動かない出典：Ops エージェントの概要出典：Github issue: Support for Google Container-Optimized OS 91

Slide 92

Slide 92 text

課題：pgcatのメトリクス収集 ● なんかいい方法無い？と相談される（ここからサポート役として参戦） ● OTel Collector使えばできそうだったので検証する ○ できたので記事を書いた出典：COS上のアプリのPrometheus MetricsをCloud Monitoringに送る 92

Slide 93

Slide 93 text

OpenTelemetry Collector 出典：Collector | OpenTelemetry 93

Slide 94

Slide 94 text

可能性は無限大 ● Receivers：99+ ● Processors：27+ ● Exporters：127+ ※opentelemetry.io repoで下記のコマンドで集計（2024/11/10） yq '. | select(.registryType == "receiver")' ./data/registry/*.yml | yq ea '[.] | length' 94

Slide 95

Slide 95 text

● Google Cloud Exporter ● AWS CloudWatch Logs Exporter 多くのComponentで関連企業のエンジニアが Code Ownerになっているので安心！出典：Contrib repository for the OpenTelemetry Collector ←googlerがいる ←AWSの人がいる 95

Slide 96

Slide 96 text

今回の構成 96

Slide 97

Slide 97 text

OpenTelemetry Collector BuilderによるCollector作成 97

Slide 98

Slide 98 text

OpenTelemetry Collector BuilderによるCollector作成 ※最小の構成例 98

Slide 99

Slide 99 text

OpenTelemetry Collector BuilderによるCollecor作成 99

Slide 100

Slide 100 text

デプロイ（サイドカー構成） ● cloud-initでsystemdのユニットファイルを定義（1コンテナ1サービス）出典：COS上のアプリのPrometheus MetricsをCloud Monitoringに送る 100

Slide 101

Slide 101 text

Resource Detection Processor 101

Slide 102

Slide 102 text

Resource Detection Processor ● OSやPlatformなど、動作環境に関わる情報を自動取得しResource Attributesとしてテレメトリにセット（AWSやAzure、k8sなど） ※参考画像：opentelemetry-demoのテレメトリをotel-tuiで表示 102

Slide 103

Slide 103 text

Resource Detection Processor ● Cloud Monitoring側でリソースとして自動認識👍 103

Slide 104

Slide 104 text

Resource Detection Processor ● 最低限のDimensionも自動で識別 ○ MIG単位（Blue / Green） ○ Role単位（Primary / Replica） ○ Host単位 ○ など 104

Slide 105

Slide 105 text

推奨パターンから外れる懸念について ● Google Cloudのサポートにもご相談したところ OpenTelemetry Collectorをおすすめされる ○ 回答の参考資料に自分が書いたブログを引用いただくというエピソードもありました✨ 105

Slide 106

Slide 106 text

OpenTelemetryの予備知識のおかげでシュッと導入できた ● 相談が来てから大体2週間くらいでメトリクス収集＋デプロイ可能な状態になっていた ○ 並行でVMのリリースフロー整備や負荷試験等も行っていたので実働時間はもっと少なそう！ 106

Slide 107

Slide 107 text

OpenTelemetry Collectorが無かったら…… ● Container-Optimized OS以外のOSを利用 ○ Docker Engine、VM Managerなど構成管理が複雑化 ○ 設定漏れ等によるセキュリティリスク出典：Container-Optimized OS の概要 | Google Cloud 107

Slide 108

Slide 108 text

ありがとうOpenTelemetry✨ 108

Slide 109

Slide 109 text

事例2：まとめ ● OpenTelemetryの豊富なComponentを組み合わせることで、プロダクトやベンダーの差異を吸収しテレメトリ収集することが可能になる ○ Receiver（Pull, Push問わず）, Exporter ○ Resource Detection Processorでプロダクトやベンダー特有の情報もよしなに収集→Cloud Monitoringと調和 ● OpenTelemetryでできることを知っておけば、いざというときに武器になる💪 109

Slide 110

Slide 110 text

OpenTelemetryがもたらす柔軟さ ○ Agility：不確実性やリスクに素早く対応できる →事例1：OpenTelemetry+Datadogの話 ○ Flexibility：ベンダーやプロダクトの違いを吸収（相互運用性） →事例2：OpenTelemtry Collectorの話今日話したこと 110

Slide 111

Slide 111 text

OpenTelemetryがもたらす柔軟さ ○ Agility：不確実性やリスクに素早く対応できる →事例1：OpenTelemetry+Datadogの話 ○ Flexibility：ベンダーやプロダクトの違いを吸収（相互運用性） →事例2：OpenTelemtry Collectorの話柔軟かつお手軽なオブザーバビリティ基盤を作って…… 今日話したこと 111

Slide 112

Slide 112 text

Sampling Correlation Trace 気軽に使っていきましょう！ 112 柔軟かつお手軽なオブザーバビリティ基盤

Slide 113

Slide 113 text

ありがとうございました！ 113