「緑なら大丈夫」が本当になるために

一言でいうと

「緑なら大丈夫」という約束は、その緑が何を意味するのか説明できるときにだけ成り立ちます。根拠のないしきい値は、何も語らないまま全員を安心させてしまいます。

なぜ必要なのか

Grafanaでパネルを作ると、しきい値はすでに入っています。公式ドキュメントに書かれている既定値は、ベース(Base)が緑、80から赤、方式は絶対値です。この80はどこから来たのでしょうか。どこからも来ていません。CPU使用率のように0から100のあいだで動く値を使う人が多いので、便宜上決められた値です。

問題は、その便宜上の値が私たちの指標にそのまま残ることです。PromQLで作ったエラー率は0と1のあいだで出ます。そのパネルに80で赤になるしきい値が付いていると、サービスがリクエストを100%失敗させても値は1なので、しきい値を超えられません。そのパネルは永遠に緑のままです。画面は毎日「大丈夫」と言っていたのに、その言葉が何を意味するのか、誰も尋ねたことがなかっただけです。

逆の方向もよくあります。誰かが「赤が頻繁に出すぎる」と言って、しきい値をこっそり上げます。上げる根拠がないので、下げる根拠もありません。しきい値が一度、気分で回せるつまみになってしまうと、それ以降は画面が人を慣らしていきます。

どう動くのか

しきい値は絵ではなく、ダッシュボードモデルにあります。fieldConfig.defaults.thresholdsの下に、方式(mode)と段階の一覧(steps)が入っていて、各段階は色と値を持ちます。先頭の段階の値は空ですが、これがドキュメントの言うベース、つまりマイナス無限大です。Grafanaは段階を値の順に並べ替え、値がその段階以上である最後の段階の色を選びます。境界は含みます。しきい値が0.005なら、0.005はすでにその色で、0.00499は1つ前の色です。

ここから出てくるルールが2つあります。1つ目は、段階が「低いほど良い」を前提に書かれることです。値が大きくなるほど悪い色へ進みます。そのため、残りディスクや成功率のように大きいほど良い指標では、順序を逆にする必要があります。ベースを赤にして、上へ行くほど緑になるようにします。逆にしないと、ディスクが空っぽの状態が緑に見えます。2つ目は、段階のあいだに空白がないことです。どんな値でも、必ずどれか1つの色を持ちます。

方式は2種類です。絶対値は、値そのものをしきい値と比べます。パーセンテージは、値が最小値と最大値のあいだで何パーセントの位置にあるかを比べます。そのため、パーセンテージのしきい値は標準オプションのMin・Maxがなければ意味を持ちません。ドキュメントがMinとMaxを「パーセンテージのしきい値の計算に使う値」と書いている理由です。残りディスクをパーセンテージで色分けするには、ボリューム全体のサイズを最大値として書いておく必要があります。その数字を書かないと、Grafanaは今画面にあるデータから最大値を推測します。すると、同じパネルが時間範囲を変えるたびに違う色になります。

しきい値を決めるとき、説明できる根拠は私たちがユーザーに約束したことだけです。30日の可用性目標が99.5%なら、エラーバジェットは0.5%で、エラー率が0.5%を超えているあいだは、バジェットをまさにバジェットのペースより速く消費していることになります。すると、警告は0.005に、その2倍の0.01に赤を置く、というようにしきい値が計算されます。こうして作ったしきい値は会議で根拠を示して説明でき、目標が変われば一緒に変わります。

色だけで語る画面は、別の問題も生みます。色覚特性のある人には赤と緑が区別できず、白黒で印刷された振り返り資料でも同じで、アラートのキャプチャを白黒で保存するツールもあります。そのため、色は付け足しの信号であるべきで、値と文字が先になければなりません。Grafanaでは、値マッピングのRangeルールで、区間ごとに文字を付けられます。0から0.005までは「正常」、それより上は「バジェット消費中」のようにです。マッピングは上から順に見て最初に当てはまったルールが勝ち、両端をどちらも含むので、境界値が重なると前のルールが取ります。

最後は、画面とページャーのずれです。パネルの赤は0.01なのに、アラートルールは0.02で鳴るとします。すると、エラー率が0.015のあいだ、ダッシュボードは真っ赤なのに誰にもページが飛びません。事故の振り返りで「なぜ誰も気づかなかったのか」と尋ねると、2つの数字が別々のファイルに手で書かれていた、という答えが返ってきます。直す方法は、2つを1か所から引っ張ってくることです。目標ファイルに数字を1回書き、パネルとルールをそこから作り出せば、ずれる余地がなくなります。

この環境が判定できないものも、はっきり書いておきます。実際に塗られた色です。このPodのGrafanaには画像レンダラープラグインがないため、パネルを画像として書き出せません。そのため採点ツールは、しきい値モデルとクエリ結果だけを見ます。どの値がどの色になるかは、Grafanaが使うルールをそのまま計算して確認できますが、その赤が画面で目立つかどうか、隣のパネルの緑と紛らわしくないかは確認できません。それは、Webプレビューで3000番ポートを開いて、人が見なければなりません。

現場での姿

あるチームの決済ダッシュボードは、6か月間、一度も赤くなったことがありませんでした。信頼の根拠として、その事実がよく引用されました。ある日、誰かがパネルのJSONを開いてみて、しきい値が80になっているのを見つけました。そのパネルの値は0と1のあいだでした。6か月のあいだ、その緑は「大丈夫」ではなく「何も言っていない」でした。

別のチームでは、ディスクのゲージが、赤で始まって緑で終わる向きではなく、逆に設定されていました。残り容量が90%のときに赤、5%のときに緑でした。誰もおかしいと言わなかった理由は、そのパネルがいつも緑だったからです。

次のラボですること

Grafanaを起動し、既定のしきい値のままのパネルを1つ作って、そのしきい値が私たちの指標で到達できる値かどうかを自分で計算します。次に、目標ファイルからエラーバジェットを取り出してしきい値を計算して入れ、今の値がどの色になるかをGrafanaのルールで確認します。絶対値のしきい値とパーセンテージのしきい値を使い分けながら、最小値・最大値がなぜ必要なのかを確認し、値マッピングで、色だけでなく文字でも語らせるようにします。境界値6個で、しきい値の順序と境界を含むルールを確認する小さなツールを作り、すでに本番に上がっているアラートルールのしきい値とパネルのしきい値を、1つの値から引っ張ってくるように直します。最後に、しきい値の欠陥が4つ入った本番ダッシュボードを受け取り、すべて直して提出します。