ダッシュボードをコピーした瞬間に分岐する

テンプレート変数は、ダッシュボードをコピーしなくて済むようにしてくれます。コピーは必ずずれていき、ずれたあとは、どちらが正しいのか誰にもわかりません。

サービスが12個あるとき、ダッシュボードを12個作るのは、最初は自然です。1つ作ってコピーし、クエリのサービス名だけ変えればいいからです。

問題はそのあとです。エラー率のパネルで、5分のrateの代わりに1分のrateを使うと決めたら12か所を直さなければならず、実際には3、4か所しか直されません。そして13個目のサービスができたとき、誰もダッシュボードを作りません。そのサービスは、障害が起きるまで誰にも見えません。

変数は、この問題を構造的になくします。ダッシュボードは1つで、見る対象だけが画面上部のドロップダウンで切り替わります。

変数にはいくつかの種類がありますが、実務で分かれるのは2つです。

種類	値の出どころ	問題
`custom`	人が一覧を書いておく	対象が1つ増えたその日に古くなります
`query`	データから読み込む	ありません。こちらを使います

Prometheusデータソースでは、label_valuesで読み込みます。

label_values(http_requests_total, handler)

いまのデータに実際に存在するhandlerの値が、ドロップダウンになります。ハンドラーが1つ増えれば、ドロップダウンにも自然に増えます。

そして変数は、宣言しただけでは何もしません。パネルのクエリがその変数で絞り込まれている必要があります。

sum(rate(http_requests_total{handler="$handler"}[5m]))

表記は$handler、${handler}、[[handler]]の3つとも使えます。複数の値を選べる変数(multi-value)なら、=ではなく=~"$handler"と書きます。Grafanaが値をa|b|cの形でつなげるからです。

「変数を入れると遅くなる」という考えは、たいてい逆です。変数で絞り込んだクエリは、読む時系列が減るので、むしろ速くなります。遅くなるのは値が数千個あるラベルを変数にしたときですが、それは変数の問題ではなく、そのラベルをドロップダウンで選べないというサインです。

「変数名は何でもいい」という考えも誤りです。ラベル名と同じにします。$svcがjobラベルを指していると、6か月後にそのダッシュボードを直す人は、必ず混乱します。

アラートルールではダッシュボード変数を使えません。アラートは、ダッシュボードの外で、画面なしに評価されます。$handlerを解決してくれるドロップダウンがないため、その文字がそのままPrometheusへ飛び、クエリは構文エラーで失敗します。

そのため、パネルのクエリをアラートへ移すときは、変数を必ず解決しなければなりません。特定のハンドラーを監視するなら値を直接書き、全体を見るなら変数の条件を消します。これが、「ダッシュボードからアラートを作る」作業がコピー・貼り付けでは終わらない理由です。