アラートはグラフではなくランブックを指すべきだ

一言でいうと

パネルからアラートを作れることと、そのアラートが役に立つことは、別の話です。役に立つかどうかを決めるのはしきい値ではなく、次の2つです: forとrunbook_url。

なぜ必要なのか

5xxの割合は、リクエストが1件失敗しただけで跳ね上がります。トラフィックの少ない明け方なら、1件の失敗が数パーセントになることもあります。しきい値を超えた瞬間に人を呼び出すと、1日に何度も鳴り、人はアラートを無視するようになります。

アラートが死ぬ方法は、いつもこれです。消えるのではなく、無視されます。そして、無視されるアラートチャンネルには、本物の障害も一緒に埋もれます。

forは、この問題を正面から解決します。「10分間超え続けたら」と書けば、一瞬跳ねた値は通り過ぎます。人を呼び出すアラートにforがなければ、そのアラートはいつか必ず無視されます。

どう動くのか

Grafanaのアラートルールは、いくつかのパーツがつながった形をしています。

パーツ	役割
クエリ(A)	データソースから値を取得します
しきい値(B)	その値が基準を超えているかを判定します
condition	どのパーツの結果で判定するか
for	どれだけ長く超え続けたら呼び出すか
annotations	人が読むもの: 要約とランブックのアドレス

クエリだけでしきい値がなければ、それはアラートではなくメトリクスです。いつ鳴らすかが決まっていないからです。

そして、これらすべてをファイルで書けます。

apiVersion: 1
groups:
  - orgId: 1
    name: shop-api
    folder: Lab
    interval: 1m
    rules:
      - uid: shopapi5xx
        title: ShopApiHighErrorRate
        condition: B
        for: 10m
        annotations:
          summary: 5xx 비율이 10분 넘게 0.5% 를 넘었습니다
          runbook_url: file:///root/graf/runbook.md

UIで作ったアラートルールは、ダッシュボードとまったく同じ運命をたどります。このGrafanaの中にしか残りません。

アラートにダッシュボードへのリンクを付けると

ページを受けた人がリンクを押すと、グラフが開きます。グラフは何がおかしいのかしか語らず、何をすべきかは語りません。午前3時に必要なのは、絵ではなく手順です。

ランブックは短くてもかまいません。3つの節があれば、たいてい十分です。

節	入れるもの
何が壊れたか	このアラートが何を意味するのかを1、2行で。ユーザーに何が起きているのか
最初に見るもの	実際に打てるコマンドやクエリ。「状態を確認する」では役に立ちません
元に戻す方法	原因を探す前に、先に行う対処。たいていは直近のデプロイを元に戻すこと

ランブックをアラートより先に書くほうがよいです。そうすれば、「これが鳴ったとき、人はいま何をするのか」に答えられないアラートが、そもそも作られません。

よくある勘違い

「アラートが多いほど安全だ」という考えは誤りです。アラートが1つ増えるたびに、残り全部の信頼度が少しずつ削られます。予算は件数ではなく注意力です。

「重大度だけ分ければいい」という考えもよくありません。severity: warningを付けて、誰も見ないチャンネルへ送るのは、アラートを作ったのではなく、ログをもう1つ作っただけです。

実務で本当に大切なこと

アラートを作るときに問うことは1つです。「これが鳴ったら、人はいま何をするのか」

答えが「とりあえず様子を見る」なら、それはアラートではなくダッシュボードのパネルです。答えがあるなら、その答えをランブックに書き、アラートがその文書を指すようにします。その2行が、ページを受けた人の最初の5分を変えます。