実践！OpenTelemetry と OSS を使った Observability 基盤の構築（CloudNative Days Tokyo 2022 発表資料）

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

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

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

(参考) 検証環境
- 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 を用いてインストールし動作確認をしています。

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

Introduction

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

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

tracing
logging
metrics
Introduction
Service
Input Output
計
装
Exp.
Telemetry
2/3
Ref: O11yCon2022
Jaeger は例です。Jaeger Clients は既に Deprecated となり、
OpenTelemetry への移行を推奨しています。
❷ 計装や Exp. は各種 OSS やサービスが
API / SDK を提供している
=> Proprietary (ベンダ依存) に繋がる

metrics
logging
tracing
Introduction
Service
Input Output
計
装
Exp.
Telemetry
3/3
Ref: O11yCon2022
❸ OpenTelemetry は
テレメトリの計装・エクスポーターの標準仕様
ライブラリやエージェントも提供
OpenTelemetry は言語やテレメトリーによって
対応状況が異なります。最新のステータスは公式で参照できます。

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

Introduction
(計装・エクスポーターを使い、テレメトリーを取得できることがわかったが、）
テレメトリーの活用には、個別だけではなく、関連性(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: 同上)

Introduction
(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 を
使って実現できるみたいなのでやってみる。

Observability 基盤の紹介

Grafana Labs のドキュメントによると、
どうやらログやメトリクスにトレース ID を付与すれば、Grafana 上でログ・メトリクス -> トレースが可能
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

ログ・メトリクスをトレースと紐付ける基盤構成（一部抜粋）
※ 時間の都合上、各モニタリング 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
今回構築した基盤

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 を付与すれば良いかをお話しします。

Metrics
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
❶ 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”

Metrics
BFF
User
API
Todo
API
Todo App
Collector Tempo
Promtail Loki
Traces
Logs
Traces
Logs
Traces
Logs
Metrics
Trace
ID
Trace
ID Trace
ID
Traces はトレース ID を持っている

Metrics
BFF
User
API
Todo
API
Todo App
Collector
Tempo
Promtail
Loki
Traces
Logs
Traces
Logs
Traces
Logs
Metrics
Trace
ID Trace
ID Trace
ID
右図の 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

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
右図の 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

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)
Metrics
(Exemplar)
Trace
ID
Trace
ID
ログ・メトリクスをトレース ID と紐付けることができた！

Demonstration

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

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

Demonstration
https://drive.google.com/ﬁle/d/13nmdxek97arMzQaQ3BEiBle_StF_gDDt/view?usp=sharing

発展：Custom OpenTelemetry Collector

発展としての取得を OpenTelemetry Collector(Otel Collector) で実施する方法について紹介します。
発展：Custom OpenTelemetry Collector
Exporter
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
よりシンプルな構成に
❌

まとめ

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

引き続き楽しんでいきましょう〜

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

実践！OpenTelemetry と OSS を使った Observability 基盤の構築（CloudNative Days Tokyo 2022 発表資料）

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 実践！OpenTelemetry と OSS を使った Observability 基盤の構築（CloudNative Days Tokyo 2022 発表資料）

Similar to 実践！OpenTelemetry と OSS を使った Observability 基盤の構築（CloudNative Days Tokyo 2022 発表資料） (20)

More from NTT DATA Technology & Innovation

More from NTT DATA Technology & Innovation (20)

Recently uploaded

Recently uploaded (11)

実践！OpenTelemetry と OSS を使った Observability 基盤の構築（CloudNative Days Tokyo 2022 発表資料）