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
580
カスタムダッシュボードの活用方法とMackerel開発チームでの実践例
taxin
October 25, 2023
Tweet
Share
More Decks by taxin
See All by taxin
OpenTelemetry実践 はじめの一歩
taxin
0
1.1k
SREを「続けていく」あなたへ
taxin
1
290
Cloud runユーザーから見たk8s
taxin
0
820
ローカルk8s環境のススメ / k8s-tools-for-local
taxin
0
1.1k
EKS 101
taxin
0
800
Other Decks in Technology
See All in Technology
中年男性がメインフレームから クラウドへキャリアシフトしてみた
uechishingo
1
410
DX企業CTOとして考える技術への向き合い方
shoheitai
0
110
Tellus の衛星データを見てみよう #mf_fukuoka
kongmingstrap
0
350
[2024/04/23]tbls活用事例 〜 ビューポイントから データベースを整理してみた話 〜
tosite
0
110
KubeConにproposalを送りたい人へのアドバイス
sat
PRO
3
280
Google Cloud Next '24 Recap(Cloud Run/k8s)
mokocm
0
370
自らを知り外と繋がる、日経のエンジニア採用とDevRel活動/devreljp92
nishiuma
1
130
生成AIの変革の時代に、直近1年で直面した課題とその解決策
ktc_wada
1
760
同じ様なUIをiOS/Android間で合わせるヒントNo.2
fumiyasac0921
1
110
類似ロジック実装をiOS/Android間で合わせる道標No.1
fumiyasac0921
0
130
【NW X Security JAWS#3】L3-4:AWS環境のIPv6移行に向けて知っておきたいこと
shotashiratori
1
710
Amplify 🩷 Bedrock 〜生成AI入門〜
minorun365
PRO
9
1.1k
Featured
See All Featured
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
34
6.1k
What's in a price? How to price your products and services
michaelherold
238
11k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
79
44k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
22
1.6k
Agile that works and the tools we love
rasmusluckow
325
20k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
155
14k
What's new in Ruby 2.0
geeforr
337
31k
Learning to Love Humans: Emotional Interface Design
aarron
267
39k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
352
28k
RailsConf 2023
tenderlove
9
570
Statistics for Hackers
jakevdp
790
220k
The Language of Interfaces
destraynor
151
23k
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 カスタムダッシュボードを 使う上での悩み・ノウハウ 聞かせてください