© 2022 NTT DATA Corporation 実践！ OpenTelemetry と OSS を使った Observability 基盤の構築 #CNDT2022_F 2022/11/22 15:20~15:40 逆井 啓佑 @k6s4i53rx

© 2022 NTT DATA Corporation CLOUDNATIVE DAYS TOKYO2022 Who AM I ?? 逆 井 啓 佑 さかさい belongs: ”NTT DATA” kind: ”スクラムチームの Product Owner(PO)” # CloudNative な技術スタックたくさん metadata: CloudNative 歴: ”１年くらい” # 社内の研修制度「CloudNative・k8s 塾」で修行 最近の関心事: ”Observability(O11y), CI/CD” twitter: @k6s4i53rx intro_po.yaml 1 2 3 4 5 6 7 8 9 10 11 12

© 2022 NTT DATA Corporation 今回 20分 でお話しすること CLOUDNATIVE DAYS TOKYO2022 留意点 - 構築には一部 feature flag の有効化 や Optional な機能を用いています Ex.：MetricsGenerator(Grafana Tempo), Remote Write Receiver(Prometheus) 本日お話しできないこと - Observability や OpenTelemetry の詳しいお話しは を参考！ - 基盤の “非機能” の紹介 / モニタリング OSS の比較 本日お話しすること 実践！ OpenTelmetry と OSS を使った Observability 基盤の 構築 ということで、 - 構築した 基盤の紹介・デモンストレーション メイン - 基盤の “機能” の紹介 - 構築に用いたモニタリング OSS の軽い紹介

© 2022 NTT DATA Corporation (参考) 検証環境 CLOUDNATIVE DAYS TOKYO2022 - 　　loki-stack　　　　　　　 : 2.8.3 - 　　tempo-distributed : 0.26.8 - 　　kube-prometheus-stack　 : 41.5.1 - 　　opentelemetry-operator　: 0.16.0 ※ Kubernetes : 1.22 on EKS : eks.6 ※ EKS：Elastic Kubernetes Service Observability 基盤の構築に用いたモニタリング OSS。 以下の Helm Chart を用いてインストールし動作確認 をしています。

© 2022 NTT DATA Corporation Agenda 1. Introduction ● Observability 〜 OpenTelemetry の基本のみ 2. Observability 基盤の紹介 3. Demonstration ● シナリオ ❶：ログエラーを検知した場合 ● シナリオ ❷：目標を下回るシステム挙動を検知した場合 4. (発展) Custom OpenTelemetry Collector 5. まとめ CLOUDNATIVE DAYS TOKYO2022

© 2022 NTT DATA Corporation Introduction

© 2022 NTT DATA Corporation Introduction CLOUDNATIVE DAYS TOKYO2022 ・kubernetes Observability入門 (@yosshi_ san) ・Grafana Loki getting started (@polar3130 san) クラウドネイティブ環境 において システムは動的に変化 する プラットフォームの回復力・管理力／堅牢な自動化 変化し続けてもなお、 継続的 に システムの 信頼性 を証明 できる必要がある (Observability, 可観測性) Dev の場合：AP の動作や、画面遷移の挙動など... Ops の場合：プラットフォームや CI/CD の正常性など... 信頼性を測る要素として Primary Signals がある Logging, Tracing, Metrics, Profiles, Dumps => Telemetry と呼ぶ

© 2022 NTT DATA Corporation metrics Introduction CLOUDNATIVE DAYS TOKYO2022 Service Input ❶ 計装やエクスポータ−は (基本的に) アプリに実装する必要がある Output 計 装 Exp. Telemetry logging tracing 1/3 Ref: O11yCon2022 ・OpenTelemetryのこれまでとこれから (@ymotongpoo san) (今回は logging, tracing, metrics の３つのテレメトリーに着目) テレメトリの収集/解析には、計装 (instrumentation) と エクスポーター (と ダッシュボード) が必要 ※ バックエンドは一例

© 2022 NTT DATA Corporation tracing logging metrics Introduction CLOUDNATIVE DAYS TOKYO2022 Service Input Output 計 装 Exp. Telemetry 2/3 Ref: O11yCon2022 ・OpenTelemetryのこれまでとこれから (@ymotongpoo san) (今回は logging, tracing, metrics の３つのテレメトリーに着目) テレメトリの収集/解析には、計装 (instrumentation) と エクスポーター (と ダッシュボード) が必要 ※ バックエンドは一例 Jaeger は例です。Jaeger Clients は既に Deprecated となり、 OpenTelemetry への移行を推奨しています。 ❷ 計装や Exp. は各種 OSS やサービスが API / SDK を提供している => Proprietary (ベンダ依存) に繋がる

© 2022 NTT DATA Corporation metrics logging tracing Introduction CLOUDNATIVE DAYS TOKYO2022 Service Input Output 計 装 Exp. Telemetry 3/3 Ref: O11yCon2022 ・OpenTelemetryのこれまでとこれから (@ymotongpoo san) (今回は logging, tracing, metrics の３つのテレメトリーに着目) テレメトリの収集/解析には、計装 (instrumentation) と エクスポーター (と ダッシュボード) が必要 ※ バックエンドは一例 ❸ OpenTelemetry は テレメトリの 計装・エクスポーター の標準仕様 ライブラリやエージェントも提供 OpenTelemetry は言語やテレメトリーによって 対応状況が異なります。最新のステータスは公式で参照できます。

© 2022 NTT DATA Corporation (参考) Introduction CLOUDNATIVE DAYS TOKYO2022 OpenTelemetry は アプリの 計装ライブラリ (API, SDK, ・・・など) バックエンドへの 送信プロトコル (OTLP) Otel Collector (プロキシ) を挟んでエクスポートをする の仕様を定めている Ref: O11yCon2022 ・入門 OpenTelemetry Collector (@katzchang san) 図：https://opentelemetry.io/docs/

© 2022 NTT DATA Corporation Introduction CLOUDNATIVE DAYS TOKYO2022 (計装・エクスポーターを使い、テレメトリーを取得できることがわかったが、） テレメトリーの活用 には、個別だけではなく、関連性(correlate)を持たせる ことも重要 - テレメトリーからテレメトリーに移る際に、コンテキストを維持する必要 (後述: trace id, exemplar) - 個別の場合、特にトレースにおいては、欲しいトレースを膨大なトレースの中から探し出すのは 　　　　　　　　　　　　''めっちゃ難しい''(''Avoid the needle-in-haystack.'') (Ref: Grafana Labs Paper) なので...理想的には... Logs Metrics ✔ Status OK ✔ Status OK ✔ Status OK ✔ Status OK ❌ ERROR Traces Trace Span A Span B Span C で ERROR & 遅延 「ログのエラーや、メトリクスの異常値は、 なぜそのトレースが興味深いかを教えてくれている。 => トレースを見る時点でなぜ探しているかを知っている」 (Ref: 同上)

© 2022 NTT DATA Corporation Introduction CLOUDNATIVE DAYS TOKYO2022 (logging, tracing, metrics は無事取れたが...) テレメトリーの活用 には、個別だけではなく、関連性を持たせる ことも重要 - テレメトリーからテレメトリーに移る際に、コンテキストを維持する必要 (後述: trace id, exemplar) - 特にトレースにおいては、欲しいトレースを膨大なトレースの中から探し出すのは 　　　　　　　　　　　　''めっちゃ難しい''(''Avoid the needle-in-haystack.'') (Ref: Grafana Labs Paper) なので...理想的には... Logs Metrics ✔ Status OK ✔ Status OK ✔ Status OK ✔ Status OK ❌ ERROR Traces Trace Span A Span B Span C で遅延 「ログのエラーや、メトリクスの異常値は、 なぜそのトレースが興味深いかを教えてくれている。 => トレースを見る時点でなぜ探しているかを知っている」 (Ref: 同上) Grafana Labs 要するに... ログ や メトリクス を トレース と紐付けたい Tempo や Loki Prometheus を 使って実現できるみたいなのでやってみる。

© 2022 NTT DATA Corporation Observability 基盤の紹介

© 2022 NTT DATA Corporation Grafana Labs のドキュメントによると、 どうやら ログやメトリクスにトレース ID を付与 すれば、Grafana 上で ログ・メトリクス -> トレースが可能 Observability 基盤の紹介 CLOUDNATIVE DAYS TOKYO2022 Traces Logs Metrics Trace ID Trace ID Trace ID ✔ Status OK ✔ Status OK ✔ Status OK ✔ Status OK ❌ ERROR Trace Span A Span B Span C で遅延 Trace ID Grafana Dashboard Data Source

© 2022 NTT DATA Corporation Observability 基盤の紹介 CLOUDNATIVE DAYS TOKYO2022 ログ・メトリクスをトレースと紐付ける基盤構成（一部抜粋） ※ 時間の都合上、各モニタリング OSS の概要は Appendix に盛り込みます。 BFF User API Todo API Todo App Collector Tempo Promtail Loki Traces Logs Traces Logs Traces Logs Trace ID Trace ID Trace ID Metrics Metrics 今回構築した基盤

© 2022 NTT DATA Corporation Observability 基盤の紹介 CLOUDNATIVE DAYS TOKYO2022 ログ・メトリクスをトレースと紐付ける基盤構成（一部抜粋） ※ 時間の都合上、各モニタリング OSS の概要は Appendix に盛り込みます。 BFF User API Todo API Todo App Collector Tempo Promtail Loki Traces Logs Traces Logs Traces Logs Trace ID Trace ID Trace ID Metrics Metrics 各テレメトリー（ログ・メトリクス）に どのようにトレース ID を付与すれば良いかをお話しします。

© 2022 NTT DATA Corporation Metrics Observability 基盤の紹介 CLOUDNATIVE DAYS TOKYO2022 BFF User API Todo API Todo App Collector Tempo Promtail Loki { “msg”: “ABC.”, “method”: “GET”, … “trace_id”: “XXX” } Traces Logs Traces Logs Traces Logs Metrics Trace ID Trace ID Trace ID ログ・メトリクスをトレースと紐付ける基盤構成（一部抜粋） ※ 時間の都合上、各モニタリング OSS の概要は Appendix に盛り込みます。 ❶ Loki に保存されるログのラベルセットに、トレース ID を付与すれば良い ・{method=”GET”, trace_id=”XXX”,…} “Start Service A” ・{method=”GET”, trace_id=”XXX”,…} “Start Service B” ❷ Grafana で、どのラベルを トレース ID として解釈 するかを設定 ・今回は ”trace_id” の Value (“XXX”) をトレース ID と設定 {method=”GET”, trace_id=”XXX”,…} “ABC”

© 2022 NTT DATA Corporation Metrics Observability 基盤の紹介 CLOUDNATIVE DAYS TOKYO2022 BFF User API Todo API Todo App Collector Tempo Promtail Loki Traces Logs Traces Logs Traces Logs Metrics Trace ID Trace ID Trace ID ログ・メトリクスをトレースと紐付ける基盤構成（一部抜粋） ※ 時間の都合上、各モニタリング OSS の概要は Appendix に盛り込みます。 Traces はトレース ID を持っている

© 2022 NTT DATA Corporation Metrics Observability 基盤の紹介 CLOUDNATIVE DAYS TOKYO2022 BFF User API Todo API Todo App Collector Tempo Promtail Loki Traces Logs Traces Logs Traces Logs Metrics Trace ID Trace ID Trace ID ログ・メトリクスをトレースと紐付ける基盤構成（一部抜粋） ※ 時間の都合上、各モニタリング OSS の概要は Appendix に盛り込みます。 右図の Metrics は 、 SpanMetrics = Span 情報から Tempo が生成するメトリクス。以下の４つ。 ❶ traces_spanmetrics_calls_total ❷~❹ traces_spanmetrics_latency_{bucket or count or sum} ある断面で以下のレスポンスタイムのデータ(一例) Request A : 0.1 Request B：0.04 Request C：0.3 Request D：0.6 Request E：1.2 traces_spanmetrics_latency = (*) とすると (*)_count 5 (*)_sum 2.24 (*)_bucket{“le”=0.05} 1 (*)_bucket{“le”=0.5} 3 (*)_bucket{“le”=1} 4 (*)_bucket{“le”=INF} 5 ※ le (less or equal) は histogram_buckets: [0.1, 0.5, 1, INF] Metrics Tempo → Promethesu は remote_write：/api/v1/write の エンドポイントにメトリクスを POST

© 2022 NTT DATA Corporation Observability 基盤の紹介 CLOUDNATIVE DAYS TOKYO2022 BFF User API Todo API Todo App Collector Tempo Promtail Loki Traces Logs Traces Logs Traces Logs Trace ID Trace ID Trace ID 以下の Feature を有効化。Tempo: MetrisGenerator Prometheus: remote-write-receiver, exemplar-strage ログ・メトリクスをトレースと紐付ける基盤構成（一部抜粋） ※ 時間の都合上、各モニタリング OSS の概要は Appendix に盛り込みます。 右図の Metrics は 、 SpanMetrics = Span 情報から Tempo が生成するメトリクス。以下の４つ。 ❶ traces_spanmetrics_calls_total ❷~❹ traces_spanmetrics_latency_{bucket or count or sum} ある断面で以下のレスポンスタイムのデータ(一例) Request A : 0.1 Request B：0.04 Request C：0.3 Request D：0.6 Request E：1.2 traces_spanmetrics_latency = (*) とすると (*)_count 5 (*)_sum 2.24 (*)_bucket{“le”=0.05} 1 (*)_bucket{“le”=0.5} 3 (*)_bucket{“le”=1} 4 (*)_bucket{“le”=INF} 5 {*}_bucket{“le”=0.05} # {trace_id="BBB"} 0.04 {*}_bucket{“le”=0.5} # {trace_id="AAA"} 0.1 {*}_bucket{“le”=1} # {trace_id="CCC"} 0.3 各 le に対して Exemplar(模範値) を発行 ※ le (less or equal) は histogram_buckets: [0.1, 0.5, 1, INF] Metrics Metrics (Exemplar) Metrics (Exemplar) Trace ID Trace ID Exemplar {trace_id="AAA"} Exemplar {trace_id="BBB"} Exemplar により メトリクスをトレースと紐づける ことができる Tempo → Promethesu は remote_write：/api/v1/write の エンドポイントにメトリクスを POST

© 2022 NTT DATA Corporation Observability 基盤の紹介 CLOUDNATIVE DAYS TOKYO2022 BFF User API Todo API Todo App Collector Tempo Promtail Loki Traces Logs Traces Logs Traces Logs Trace ID Trace ID Trace ID Trace ID Trace ID Trace ID Metrics (Exemplar) ログ・メトリクスをトレースと紐付ける基盤構成（一部抜粋） ※ 時間の都合上、各モニタリング OSS の概要は Appendix に盛り込みます。 Metrics (Exemplar) Trace ID Trace ID ログ・メトリクス を トレース ID と紐付けることができた！

© 2022 NTT DATA Corporation Demonstration

© 2022 NTT DATA Corporation Demonstration CLOUDNATIVE DAYS TOKYO2022 ここからは実際に　 Grafana 上でどのような動きになるのかを デモをしながら簡単にご紹介いたします。

© 2022 NTT DATA Corporation 以下の２シナリオを想定してデモを実施します。 Demonstration CLOUDNATIVE DAYS TOKYO2022 ❶コ目 ❷コ目 Todo サンプルアプリで擬似エラーを発生。 エラーログ から、関連する トレース へ遷移してみる。 Todo サンプルアプリの目標値として、 「全リクエストで 90%ile 20ms の レスポンスタイムを満たす（デモ用例）」 に反する メトリクスを検知し、関連するトレースへ遷移 してみる。 Traces Logs Metrics (Exemplar) Traces

© 2022 NTT DATA Corporation Demonstration CLOUDNATIVE DAYS TOKYO2022 https://drive.google.com/file/d/13nmdxek97arMzQaQ3BEiBle_StF_gDDt/view?usp=sharing

© 2022 NTT DATA Corporation 発展：Custom OpenTelemetry Collector

© 2022 NTT DATA Corporation 発展として 　　　　　の取得を OpenTelemetry Collector(Otel Collector) で実施する方法について紹介します。 発展：Custom OpenTelemetry Collector Exporter CLOUDNATIVE DAYS TOKYO2022 Metrics (Exemplar) - 今回 Grafana Tempo で用いた MetricsGenerator は、 Otel Collector の部品 である spanmetricsprocessor のミラーリング (参考: Grafana Labs) - spanmetricsprocessor は標準の Otel Collector distro. には現段階では含まれず、 In Development ステータス - Otel Collectrcontrib distro. には含まれている ( ：GitHub ) - OpenTelemetry Collector Builder (　 ：ocb) を用いて spanmetricsprocessor を使える Otel Collector をリビルドすることで、Tempo と同様 SpanMetrics を Prometheus に書き込むことが可能 yaml Receiver Processor spanmetrics processor otelreceiver otelexporter ocb を 使ってビルド Tempo Traces Metrics (Exemplar) Trace ID Collector (Custom) Collector (Custom) Trace ID よりシンプルな構成に ❌

© 2022 NTT DATA Corporation まとめ

© 2022 NTT DATA Corporation ● OpenTelemetry と OSS を使ってテレメトリー (ログ、トレース、メトリクス) を取得できた ● テレメトリー同士を関連付けることは Observability において重要 ● 今回は一例として Grafana Tempo などの OSS を用いることで実現 できる ● 実際のダッシュボードなどの動きを見て、 Observability について簡単にでもイメージいただければ幸いです！ まとめ CLOUDNATIVE DAYS TOKYO2022

© 2022 NTT DATA Corporation 引き続き楽しんでいきましょう〜

© 2022 NTT DATA Corporation 記載されている会社名、商品名、 またはサービス名は、各社の商標登録または商標です。