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
TAMとre:Capセキュリティ編 〜拡張脅威検出デモを添えて〜
fujiihda
2
240
CZII - CryoET Object Identification 参加振り返り・解法共有
tattaka
0
370
インフラをつくるとはどういうことなのか、 あるいはPlatform Engineeringについて
nwiizo
5
2.6k
利用終了したドメイン名の最強終活〜観測環境を育てて、分析・供養している件〜 / The Ultimate End-of-Life Preparation for Discontinued Domain Names
nttcom
2
190
レビューを増やしつつ 高評価維持するテクニック
tsuzuki817
1
710
Cloud Spanner 導入で実現した快適な開発と運用について
colopl
1
650
エンジニアのためのドキュメント力基礎講座〜構造化思考から始めよう〜(2025/02/15jbug広島#15発表資料)
yasuoyasuo
17
6.7k
室長と気ままに学ぶマイクロソフトのビジネスアプリケーションとビジネスプロセス
ryoheig0405
0
360
Platform Engineeringは自由のめまい
nwiizo
4
2.1k
Oracle Cloud Infrastructure:2025年2月度サービス・アップデート
oracle4engineer
PRO
1
210
Nekko Cloud、 これまでとこれから ~学生サークルが作る、 小さなクラウド
logica0419
2
970
速くて安いWebサイトを作る
nishiharatsubasa
10
13k
Featured
See All Featured
RailsConf 2023
tenderlove
29
1k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
GraphQLの誤解/rethinking-graphql
sonatard
68
10k
The Power of CSS Pseudo Elements
geoffreycrofte
75
5.5k
Code Reviewing Like a Champion
maltzj
521
39k
Automating Front-end Workflow
addyosmani
1368
200k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
226
22k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.4k
Speed Design
sergeychernyshev
27
790
Unsuck your backbone
ammeep
669
57k
GraphQLとの向き合い方2022年版
quramy
44
13k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
100
18k
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 カスタムダッシュボードを 使う上での悩み・ノウハウ 聞かせてください