TT Lab
はじめる
学ぶ 学習パス コース

可観測性

Alertmanagerでアラートを流す

TT Labで続きを見る

目標

Prometheusが作ったアラートがAlertmanagerを経由してどう振り分けられ、まとめられ、抑制されるのかを、自分で流し込みながら確認します。

なぜ重要なのか

アラート設計の失敗は2つの方向があります。鳴りすぎて誰も見なくなるか、鳴らなくて障害を見逃すかです。どちらも同じ結果になります。アラートが信頼を失います。

そのため、ルーティング・グルーピング・抑制が必要です。1つの原因が20個のアラートを作ると、人はその20個をすべては読みません。抑制ルール1つで、それを1つに減らせます。

ステップ

  1. Alertmanagerを起動する
  2. severityでルートを分岐する → /etc/alertmanager.yml
  3. レシーバーを2つ定義する
  4. criticalがwarningを抑制するルール
  5. amtool check-configで検査して反映
  6. amtool alert addでアラートを直接流し込む
  7. サイレンスを設定してみる
  8. アラートにランブックのリンクを付ける

参考

Alertmanagerを起動する

Alertmanagerを起動する

lab-start-alertmanagerで起動します。lab-statusで9093が[O]になっている必要があります。Prometheusの設定には、すでにalertmanagersの対象が入っています。

ルーティングツリーを書く

severityでルートを分岐する → /etc/alertmanager.yml

/etc/alertmanager.ymlを編集します。routeの下のroutesで、severity=criticalとseverity=warningを分けて、それぞれ別のreceiverへ送ります。criticalはgroup_waitを短く、warningは長くします。急ぐものを先に知らせるためです。

レシーバーを2つ定義する

レシーバーを2つ定義する

receiversのリストに、最低2つを置きます。実際の送信先は必要ありません。名前だけのレシーバーも有効な設定です。ここで学ぶのは「どこへ送るか」ではなく、「何を分けて送るか」です。

抑制ルール

criticalがwarningを抑制するルール

inhibit_rulesを追加します。同じ対象でcriticalが鳴っている間は、warningを抑制します。source_matchers / target_matchers / equalの3つが必要で、equalが「同じ対象」の定義です。これを抜くと、無関係なアラートまで埋もれてしまいます。

設定を検査する

amtool check-configで検査して反映

amtool check-config /etc/alertmanager.ymlで検査します。通ったらAlertmanagerを再起動して(pkill alertmanager; lab-start-alertmanager)反映します。

アラートを直接流し込んでみる

amtool alert addでアラートを直接流し込む

amtoolでアラートを1つ作ってみます。amtool alert add TestAlert severity=critical service=shop-apiを実行してください。そしてamtool alertで届いたかを確認します。

サイレンスを設定する

サイレンスを設定してみる

amtool silence add alertname=TestAlert -d 1h -c '점검 중'で、しばらく埋もれさせます(韓国語で「点検中」を意味する語です)。amtool silence queryで確認してください。点検の時間帯にアラートを切る代わりにサイレンスを使えば、終わったあとに自動で復活します。切って忘れる事故がありません。

アラートにランブックのリンクを付ける

アラートにランブックのリンクを付ける

/etc/prometheus/rules/slo.ymlのアラートに、annotations.runbook_urlを追加します。明け方3時に起こされた人に必要なのは、「何が間違っている」ではなく「何をせよ」です。promtoolで検査してから、reloadしてください。