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.7k
カスタムダッシュボードの活用方法とMackerel開発チームでの実践例
taxin
October 25, 2023
Tweet
Share
More Decks by taxin
See All by taxin
監視SaaSの運用におけるObservability改善の歩み
taxin
4
4.9k
ポストモーテム読書会のすすめ
taxin
1
2.5k
OpenTelemetry実践 はじめの一歩
taxin
0
3.1k
SREを「続けていく」あなたへ
taxin
1
360
Cloud runユーザーから見たk8s
taxin
0
900
ローカルk8s環境のススメ / k8s-tools-for-local
taxin
0
1.2k
EKS 101
taxin
0
950
Other Decks in Technology
See All in Technology
人工衛星のファームウェアをRustで書く理由
koba789
15
8.3k
「Linux」という言葉が指すもの
sat
PRO
4
140
S3アクセス制御の設計ポイント
tommy0124
3
210
20250910_障害注入から効率的復旧へ_カオスエンジニアリング_生成AIで考えるAWS障害対応.pdf
sh_fk2
3
280
Codeful Serverless / 一人運用でもやり抜く力
_kensh
7
450
AWSで始める実践Dagster入門
kitagawaz
1
750
プラットフォーム転換期におけるGitHub Copilot活用〜Coding agentがそれを加速するか〜 / Leveraging GitHub Copilot During Platform Transition Periods
aeonpeople
1
240
今日から始めるAWSセキュリティ対策 3ステップでわかる実践ガイド
yoshidatakeshi1994
0
120
Aurora DSQLはサーバーレスアーキテクチャの常識を変えるのか
iwatatomoya
1
1.2k
20250912_RPALT_データを集める→とっ散らかる問題_Obsidian紹介
ratsbane666
0
100
Snowflake Intelligence × Document AIで“使いにくいデータ”を“使えるデータ”に
kevinrobot34
1
120
LLMを搭載したプロダクトの品質保証の模索と学び
qa
1
1.1k
Featured
See All Featured
Java REST API Framework Comparison - PWX 2021
mraible
33
8.8k
What’s in a name? Adding method to the madness
productmarketing
PRO
23
3.7k
Site-Speed That Sticks
csswizardry
10
820
Documentation Writing (for coders)
carmenintech
74
5k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
Facilitating Awesome Meetings
lara
55
6.5k
YesSQL, Process and Tooling at Scale
rocio
173
14k
Optimizing for Happiness
mojombo
379
70k
Building Adaptive Systems
keathley
43
2.7k
[RailsConf 2023] Rails as a piece of cake
palkan
57
5.8k
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
The Language of Interfaces
destraynor
161
25k
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 カスタムダッシュボードを 使う上での悩み・ノウハウ 聞かせてください