パネルの種別は問いの形だ

一言でいうと

タイプを選ぶ基準は好みではありません。質問が時間についてなのか、いまの値1つについてなのか、ばらつきについてなのかで分かれます。

なぜ必要なのか

タイプを間違えると、グラフは描かれるのに答えが出ません。しかも、その事実は目立ちません。画面は問題なく、数字も合っていて、ただ必要な瞬間に必要なものを見せられないだけです。間違ったクエリは空の画面で気づけますが、間違ったタイプは静かです。

質問の形	タイプ	例
時間とともにどう変わったか	timeseries	エラー率、p95レイテンシ
いまこの瞬間の値1つ	stat	現在のリクエスト率、残りのエラーバジェット
決まった上限に対してどれだけ埋まっているか	gauge	ディスク使用率、コネクションプール
値がどう散らばっているか	heatmap	応答時間の分布
複数の対象の順位	table・bar	ハンドラー別のエラー数

それぞれが間違える瞬間

秒あたりのリクエスト数にゲージ。ゲージは「0と最大値のあいだのどのあたりか」を見せる道具です。秒あたりのリクエスト数には最大値がありません。針がどこにあっても、その位置は何も語らず、しかも時間軸がないので「いつから増えたのか」にも答えられません。ゲージは上限が定義された値にだけ使います。

分布に折れ線グラフ1本。平均応答時間の線1本は、「ユーザーの半分が2秒待った」を完璧に隠します。平均は大きな値が少しあるだけで引っ張られるのに、その値があったという事実は見せてくれません。ばらつきを見るには、分位数を複数重ねるか、ヒートマップを使います。

状態ダッシュボードにstatだけ。「いまエラー率3%」という数字1つでは、上がっている途中なのか、下がっている途中なのかわかりません。インシデントでは、その違いがすべてです。数字1つを見せるときは、隣に時間軸のあるパネルも一緒に置きます。

分位数は平均ではない

ヒストグラムから分位数を求めるとき、leラベルはバケットの境界です。そのため、必ずleを残して、残りを合算します。

histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

sum by (le)を抜かすと、インスタンスごとのバケットがばらばらに動き、値がもつれます。逆に、すでに求めたp95をあとで平均するのも間違いです。分位数は平均できません。10台のインスタンスのp95の平均は、全体のp95ではありません。合算すべきなのは、結果ではなくバケットです。

よくある勘違い

「タイプはあとで変えればいい」という考えは通用しません。実際には変えません。一度描かれたパネルはそのまま残り、間違ったタイプはそのパネルを静かに役立たずにします。

「円グラフは見栄えがいい」という考えもよくありません。円グラフには時間がなく、扇形の大きさを目で比べるのも難しいからです。同じデータなら、ほとんどの場合、表や棒グラフのほうが優れています。

実務で本当に大切なこと

パネルのタイトルに単位と期間を書きます。「エラー」ではなく、「5xx割合(5分間のrate)」と書きます。ページを受けた人はそのパネルを初めて見る人であり、0.004という数字が割合なのか件数なのか、秒あたりなのか分あたりなのかを、タイトル以外で知る方法はありません。

そして、軸の単位をGrafanaに教えます(percentunit、secondsのようなものです)。0.004より0.4%、0.223より223msのほうが、午前3時にはずっと速く読めます。