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
2
5.9k
オブザーバビリティの 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
強いチームと開発生産性
onk
PRO
40
17k
ADRを運用して3年経った僕らの現在地
onk
PRO
21
22k
1文字エイリアスのすゝめ
onk
PRO
0
58
すこやかなサービス運営のための PWG (Performance Working Group)
onk
PRO
0
920
Cache Stampede
onk
PRO
1
2.2k
ORM - Object-relational mapping
onk
PRO
2
3.7k
デュアルトラックアジャイルとの向き合い方
onk
PRO
5
12k
技術記事を書く&楽しむチームの作り方
onk
PRO
0
1.9k
熊とワルツを
onk
PRO
0
8
Other Decks in Technology
See All in Technology
[SRE NEXT 2025] すみずみまで暖かく照らすあなたの太陽でありたい
carnappopper
2
470
AWS 怖い話 WAF編 @fillz_noh #AWSStartup #AWSStartup_Kansai
fillznoh
0
130
Rethinking Incident Response: Context-Aware AI in Practice
rrreeeyyy
2
940
スタックチャン家庭用アシスタントへの道
kanekoh
0
120
Copilot coding agentにベットしたいCTOが開発組織で取り組んだこと / GitHub Copilot coding agent in Team
tnir
0
190
AWS CDK 入門ガイド これだけは知っておきたいヒント集
anank
5
750
マルチプロダクト環境におけるSREの役割 / SRE NEXT 2025 lunch session
sugamasao
1
730
SRE with AI:実践から学ぶ、運用課題解決と未来への展望
yoshiiryo1
0
300
Snowflake Intelligenceという名のAI Agentが切り開くデータ活用の未来とその実現に必要なこと@SnowVillage『Data Management #1 Summit 2025 Recap!!』
ryo_suzuki
1
160
ClaudeCodeにキレない技術
gtnao
1
860
ゼロから始めるSREの事業貢献 - 生成AI時代のSRE成長戦略と実践 / Starting SRE from Day One
shinyorke
PRO
0
110
AI時代にも変わらぬ価値を発揮したい: インフラ・クラウドを切り口にユーザー価値と非機能要件に向き合ってエンジニアとしての地力を培う
netmarkjp
0
130
Featured
See All Featured
Code Reviewing Like a Champion
maltzj
524
40k
Bash Introduction
62gerente
613
210k
Unsuck your backbone
ammeep
671
58k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3.1k
Designing Experiences People Love
moore
142
24k
Producing Creativity
orderedlist
PRO
346
40k
RailsConf 2023
tenderlove
30
1.1k
Speed Design
sergeychernyshev
32
1k
A better future with KSS
kneath
238
17k
Code Review Best Practice
trishagee
69
19k
The Language of Interfaces
destraynor
158
25k
Building a Modern Day E-commerce SEO Strategy
aleyda
42
7.4k
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