Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
オブザーバビリティの Primary Signals
Search
Takafumi ONAKA
PRO
April 10, 2024
Technology
1
610
オブザーバビリティの Primary Signals
2024-04-10 OpenTelemetry Observability運用の実例 Lunch LT
https://findy.connpass.com/event/313260/
Takafumi ONAKA
PRO
April 10, 2024
Tweet
Share
More Decks by Takafumi ONAKA
See All by Takafumi ONAKA
Cache Stampede
onk
PRO
1
1.6k
ORM - Object-relational mapping
onk
PRO
1
3.1k
デュアルトラックアジャイルとの向き合い方
onk
PRO
4
9.5k
cpanfile が Ruby でパースできることに気づいた俺たちは
onk
PRO
0
33
Other Decks in Technology
See All in Technology
[新卒向け研修資料] テスト文字列に「うんこ」と入れるな(2024年版)
infiniteloop_inc
4
16k
アクセシビリティを考慮したUI/CSSフレームワーク・ライブラリ選定
yajihum
2
1.1k
エンジニア候補者向け資料2024.04.24.pdf
macloud
0
3.3k
20分で完全に理解するGrafanaダッシュボード
hamadakoji
4
830
Amplify 🩷 Bedrock 〜生成AI入門〜
minorun365
PRO
3
130
自己改善からチームを動かす! 「セルフエンジニアリングマネージャー」のすゝめ
shoota
6
920
require(ESM)とECMAScript仕様
uhyo
4
910
今日からできる!簡単 .NET 高速化 Tips -2024 edition-
xin9le
6
3.2k
Google Cloud Next '24 Recap(Cloud Run/k8s)
mokocm
0
290
生成AIの変革の時代に、直近1年で直面した課題とその解決策
ktc_wada
0
480
一生覚えておきたい「システム開発=コミュニケーション」〜初めての実務案件振り返りLT〜
maimyyym
2
240
LayerXにおけるLLMプロダクト開発の今までとこれから
layerx
PRO
3
550
Featured
See All Featured
Typedesign – Prime Four
hannesfritz
36
2.1k
Fashionably flexible responsive web design (full day workshop)
malarkey
398
65k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
275
13k
Infographics Made Easy
chrislema
238
18k
Web Components: a chance to create the future
zenorocha
306
41k
Testing 201, or: Great Expectations
jmmastey
29
6.4k
jQuery: Nuts, Bolts and Bling
dougneiner
59
7.1k
Intergalactic Javascript Robots from Outer Space
tanoku
266
26k
KATA
mclloyd
16
12k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
226
51k
The World Runs on Bad Software
bkeepers
PRO
61
6.7k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
222
21k
Transcript
オブザーバビリティの Primary Signals id:onk 2024-04-10 OpenTelemetry Observability運用の実例 Lunch LT 1
自己紹介 • 大仲 能史 a.k.a. id:onk • 株式会社はてな ◦ チーフエンジニア
◦ Mackerel開発チーム 2
3
4
5 今日の話
6 オブザーバビリティの Primary Signals
オブザーバビリティのPrimary Signals 7 https://github.com/cncf/tag-observability/blob/whitepaper-v1.0.0/whitepaper.md
オブザーバビリティのPrimary Signals • Metrics: システムの健康状態を高レベルで示す • Logs: イベントの詳細を提供する • Traces:
リクエストの流れを追跡する • … 8
9 Primary Signalsは、大局 から詳細までシステムを多 角的に理解するために必要
メトリックの良いところ • パフォーマンス、効率性 ◦ ログやトレースを大量に収集・分析するのは重い ◦ お金がかかる 10 https://dev.henry.jp/entry/observability-and-cost
メトリックの良いところ • 監視やトレンド分析の容易性 ◦ 数値なので異常値の検出やアラート設定が容易で、 監視しやすい、可視化しやすい ◦ ダッシュボードを構築して、システムの健康状態を 一目で把握できる ◦
長期的なパフォーマンス変化を追跡できる 11
最近目にするオブザーバビリティ • トレース・ログに重心が寄っている ◦ メトリックは既存の監視で既にカバーされている領域 ◦ オブザーバビリティを高めるには、現状のメトリックだ と詳細度が足りないことも多い • とはいえPrimary
Signalsなので大事 ◦ コストが安いし、キャパシティプランニングや ふりかえりに必要 12
Primary Signals • メトリック ◦ システム全体の健康とパフォーマンスの概要 システムが期待通りに機能しているかを把握する • ログ ◦
何が起きているか、どのように発生しているのかの詳細 • トレース ◦ システムの内部動作とリクエストの流れを理解するビュー 複雑な問題の診断に有効 13
14 OpenTelemetryで メトリックを収集する
OpenTelemetryでメトリックを収集 • 既存の監視が既に構築されている ◦ メトリックを収集できていて、直ちに困ってはいない • OpenTelemetryになるとここが嬉しい ◦ メトリックがAttributeを持つのでO11yを高めやすい ◦
将来的にOTelがメトリック収集方法の標準になる見込み ◦ 他のテレメトリーデータとの相互操作性 ▪ 例えばメトリックの異常値からトレースに簡単に遷移するとか 15
16 どうやって始めれば?
17 OpenTelemetry Collectorを使え
OpenTelemetry Collector 18 https://opentelemetry.io/docs/collector/ https://opentelemetry.io/docs/
OpenTelemetry Collector • Receiver ◦ Collectorがデータを受信する方法を提供する ◦ LISTENするだけじゃなく、ポーリングも可能 19
ホストメトリックの計装 • ホストメトリック ◦ CPU使用率 ◦ メモリ使用率 ◦ ディスク使用率 ◦
ネットワーク I/O ◦ … 20
ホストメトリックの計装 • Host Metrics Receiverを使う • OpenTelemetry Collectorのreceiversに設定 すると、自身のホストメトリックを収集できる 21
ホストメトリックの計装 22 https://mackerel.io/ja/blog/entry/tech/sending-host-metrics-to-mackerel-with-opentelemetry-collector
ミドルウェアのメトリックの計装 • ミドルウェアのメトリック ◦ nginx ◦ MySQL ◦ Redis ◦
Elasticsearch ◦ … 23
ミドルウェアのメトリックの計装 • OpenTelemetry Collector Contribにある 24
ミドルウェアのメトリックの計装 • OpenTelemetry Collector Contribにある 25 https://kmuto.hatenablog.com/entry/2024/03/24/215200
ミドルウェアのメトリックの計装 • ポーリングするReceiverの作り ◦ 既にあるエンドポイントからメトリックを収集 ▪ nginxならhttp_stub_status moduleで出力している ◦ 収集したメトリックをOpenTelemetry形式に変換
◦ 収集する頻度はカスタマイズ可能 26
アプリケーションのメトリックの計装 • アプリケーションのメトリック ◦ アクティブユーザー数 ◦ データベースの応答時間 ◦ キャッシュヒット率 ◦
… 27
アプリケーションのメトリックの計装 • 自動計装はまだまだ足りない ◦ 例えばOpenTelemetry Ruby Contribにメトリックの 自動計装は存在していない 28
アプリケーションのメトリックの計装 29
30 それでも自動計装に なるべく乗りつつ メトリックが欲しい!
31 Span Metrics Connector
Connectorとは • ReceiverとExporterの2つの役割を持つ • 異なるテレメトリーパイプラインを繋ぎ合わ せる 32 https://opentelemetry.io/docs/collector/building/connector/
Connectorとは • OpenTelemetry Casual Talkも見てね 33 https://speakerdeck.com/rnakamine/building-a-servicemap-with-service-graph-connector
Span Metrics Connectorとは • トレースからメトリックを生成する ◦ R.E.D メソッドのメトリックを収集できる ◦ Request,
Error, Duration 34
Span Metrics Connectorとは • トレースは自動計装されている ◦ 主にシステム境界でspanが切られている ▪ HTTPリクエスト ▪
SQLの実行 • トレースを集計するとメトリックになる ◦ Request数、Error数、Duration(histogram) 35
メトリックを収集したら • メトリックを集計するとダッシュボードになる ◦ どこに時間が掛かっているのか可視化したい ▪ HTTPリクエストやSQLの実行に掛かった時間を積み上げグラ フに ◦ 特定のクエリにかかった時間のパーセンタイル表示
▪ 各Durationをhistogramで保存しているので、計算可能 36
37 OpenTelemetryで メトリックを収集する その他の方法
その他の方法 • 既存のプラグインを利用する ◦ 各バックエンド向けに実装されたプラグインを活用して 今まで通りにメトリックを収集する ◦ 各バックエンド向けに実装されたReceiverに送信する と、メトリックをOpenTelemetryに加工し、ラベル付 きメトリックとしてバックエンドに送信する
38
その他の方法 39 https://sfujiwara.hatenablog.com/entry/maprobe-otel-metrics • 既存のバックエンド向けのエージェントから OTLPで送信する
40 まとめ
まとめ • 各Primary Signalの立ち位置 ◦ メトリックは引き続き大事 • OpenTelemetryでのメトリック収集の始め方 ◦ CollectorにReceiverを入れると収集できるよ
◦ SpanMetricsConnectorで始めることもできる 41