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
カスタムダッシュボードの活用方法とMackerel開発チームでの実践例
Search
taxin
October 25, 2023
Technology
0
1.4k
カスタムダッシュボードの活用方法とMackerel開発チームでの実践例
taxin
October 25, 2023
Tweet
Share
More Decks by taxin
See All by taxin
監視SaaSの運用におけるObservability改善の歩み
taxin
4
3.3k
ポストモーテム読書会のすすめ
taxin
1
2k
OpenTelemetry実践 はじめの一歩
taxin
0
2.6k
SREを「続けていく」あなたへ
taxin
1
330
Cloud runユーザーから見たk8s
taxin
0
860
ローカルk8s環境のススメ / k8s-tools-for-local
taxin
0
1.2k
EKS 101
taxin
0
900
Other Decks in Technology
See All in Technology
プロダクトエンジニア構想を立ち上げ、プロダクト志向な組織への成長を続けている話 / grow into a product-oriented organization
hiro_torii
1
290
オブザーバビリティの観点でみるAWS / AWS from observability perspective
ymotongpoo
9
1.6k
IAMポリシーのAllow/Denyについて、改めて理解する
smt7174
2
140
NFV基盤のOpenStack更新 ~9世代バージョンアップへの挑戦~
vtj
0
140
株式会社EventHub・エンジニア採用資料
eventhub
0
4.3k
Oracle Cloud Infrastructure:2025年2月度サービス・アップデート
oracle4engineer
PRO
1
320
(機械学習システムでも) SLO から始める信頼性構築 - ゆる SRE#9 2025/02/21
daigo0927
0
200
AIエージェント元年
shukob
0
110
Culture Deck
optfit
0
460
偏光画像処理ライブラリを作った話
elerac
1
110
2024.02.19 W&B AIエージェントLT会 / AIエージェントが業務を代行するための計画と実行 / Algomatic 宮脇
smiyawaki0820
14
4k
Swiftの “private” を テストする / Testing Swift "private"
yutailang0119
0
140
Featured
See All Featured
A better future with KSS
kneath
238
17k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
160
15k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
100
18k
Fontdeck: Realign not Redesign
paulrobertlloyd
83
5.4k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
4
420
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
114
50k
Documentation Writing (for coders)
carmenintech
67
4.6k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
45
9.4k
Automating Front-end Workflow
addyosmani
1368
200k
Adopting Sorbet at Scale
ufuk
74
9.2k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Testing 201, or: Great Expectations
jmmastey
42
7.2k
Transcript
Mackerel開発チームでの カスタムダッシュボードの活用例 id:taxintt / @taxin_tt 2023/10/25 Mackerel Drink Up #12
1
自己紹介 • 西川 拓志 ◦ id: taxintt / @taxin_tt •
Mackerel開発チーム SRE 2
今日の話 • カスタムダッシュボードについて • ダッシュボード利用時の悩みどころ • 開発チームにおけるダッシュボードの活用例 3
4 1. カスタムダッシュボード とは?
カスタムダッシュボードとは? • ユーザーがwidgetを自由に配置して カスタマイズができるダッシュボード ◦ アイコンをドラッグ&ドロップしてwidgetを配置 5
6
7
8
9
10
11 カスタムダッシュボード 「上手く」使ってますか?
12 2. ダッシュボード利用時の 悩みどころと開発チームの 活用例
13
散見される悩み • ダッシュボードに情報を詰め込みすぎて 認知負荷が高くなる • 情報量は増えたが結局何をみたらいいのか わからない • widgetは置いてあるが、どう見たらいいのか わからない
14
散見される悩み • ダッシュボードに情報を詰め込みすぎて 認知負荷が高くなる • 情報量は増えたが結局何をみたらいいのか わからない • widgetは置いてあるが、どう見たらいいのか わからない
15
認知負荷とは • ユーザーが情報を処理し、理解する際に かかる精神的なエネルギー量 • 処理すべき情報がユーザーの処理能力を 超えると認知負荷が高いと見なされる 16
「『短期記憶の負荷を減らしつつ、表示されたコン テンツの理解度を高めることを念頭において、 人の理解を助けるためのインターフェイスの仕様に 関する判断を行う』ことが認知負荷を軽減するデザ インだと考えられます。」 17 https://blog.adobe.com/jp/publish/2020/11/16/cc-web-ux-6-ways-to-reduce-cognitive-load-for-a-better-ui
• 短期記憶の負荷を減らす • 表示されたコンテンツの理解度を高めることを 念頭に置く • 人の理解を助けるためのインターフェイスの仕様 に関する判断を行う 18 認知負荷を軽減するには
散見される悩み • ダッシュボードに情報を詰め込みすぎて 認知負荷が高くなる • 情報量は増えたが結局何をみたらいいのか わからない • widgetはあるが、どう見たらいいのかわから ない
19
1. 情報量を減らす • ダッシュボードを確認しアクションを起こす ◦ e.g.) API latencyがある時点から悪化 → 原因調査
• アクションに繋がらない情報は削る 20
e.g.) SLO用のダッシュボード • SLO(サービスレベル目標) ◦ サービスの信頼性の目標・評価基準を定めたもの e.g. HTTPリクエストのSuccess rate :
99.95% • SLO運用 (SLOの更新) での利用を想定 ◦ SLOの現在の状況が把握できる 21
22
1. 情報量を減らす • ダッシュボードを確認しアクションを起こす ◦ e.g.) API latencyがある時点から悪化 → 原因調査
• アクションに繋がらない情報は削る ◦ 情報整理のためには「ダッシュボードの利用目的」も 重要になる 23
散見される悩み • ダッシュボードに情報を詰め込みすぎて 認知負荷が高くなる • 情報量は増えたが結局何をみたらいいのか わからない • widgetは置いてあるが、どう見たらいいのか わからない
24
2. 利用目的を整理する • ダッシュボードを見た上でのゴールは何か ◦ サービスの正常/非正常を判断すること? ◦ 非正常な事象を調査・解消すること? • ダッシュボードを見る場の目的も明確にする
25
26 ダッシュボードを見る場
PWG (Performance Working Group) 27 https://mackerel.io/ja/blog/entry/advent-calendar2015/day19
PWG (Performance Working Group) 28 https://qiita.com/heleeen/items/62f8b001310d49f42653
PWG (Performance Working Group) • 背景 ◦ システム運用の情報が一部に閉じがちで、開発チーム のエンジニアが状況把握できてないという問題意識 •
内容 ◦ 開発チームのエンジニアとSREが パフォーマンス状況やインフラの構成変更を共有 29
PWG (Performance Working Group) • 背景 ◦ システム運用の情報が一部に閉じがちで、開発チーム のエンジニアが状況把握できてないという問題意識 •
内容 ◦ 開発チームのエンジニアとSREが パフォーマンス状況やインフラの構成変更を共有 30
PWG (Performance Working Group) • PWGとしてのゴール ◦ 開発チーム全体でシステム運用の状況を把握できる (e.g. インフラ構成変更、パフォーマンス状況)
31
PWG (Performance Working Group) • 状況を把握できる ◦ パフォーマンス問題が見られたとしても、 PWGの場としては「問題が把握できればOK」 ◦
対応自体はissueを作成して原因調査を別途行う 32
PWG (Performance Working Group) • 状況を把握できる ◦ パフォーマンス問題が見られたとしても、 PWGの場としては「問題が把握できればOK」 →
パフォーマンス状況を把握するための情報を ダッシュボードに含める 33
34 https://mackerel.io/ja/blog/entry/meetup14-3
ダッシュボード(見る場)の目的が決まる → 目的を達成するのに必要な情報が整理される → ダッシュボードに含めるべき情報が決まる 35
(再掲) 1. 情報量を減らす • ダッシュボードを確認しアクションを起こす ◦ e.g.) API latencyがある時点から悪化 →
原因調査 • アクションに繋がらない情報は削る ◦ 情報整理のためには「ダッシュボードの利用目的」も 重要になる 36
散見される悩み • ダッシュボードに情報を詰め込みすぎて 認知負荷が高くなる • 情報量は増えたが結局何をみたらいいのか わからない • widgetは置いてあるが、どう見たらいいのか わからない
37
3. Markdownウィジェットの活用 • ダッシュボードの「見方」を補足する ◦ メトリックの値が示す状態 ◦ メトリックの変動が示す兆候 ◦ メトリックを基に監視しているコンポーネントの
振る舞い 38
39 https://mackerel.io/ja/blog/entry/meetup14-3
e.g.) PWG用のダッシュボード • Markdownウィジェットや補助線機能の活用 ◦ e.g.) latency = 500msを基準値とすると、 それ以下の水準でlatencyが変動していても対応不要
と判断できる 40
41 https://mackerel.io/ja/blog/entry/meetup14-3
まとめ • ダッシュボードに含める情報は最小限に • ダッシュボードや使う場のゴールを明確に して情報を整理する • 整理した情報を理解できるようにする ◦ e.g.
Markdownウィジェット、補助線機能 etc… 42
43 カスタムダッシュボードを 使う上での悩み・ノウハウ 聞かせてください