モニタリングとアラート設計

何を計測するか: 4つのゴールデンシグナル

計測すべき指標に迷ったら、Google SREの考え方である4つのゴールデンシグナルから 始めるのが定石です。

アラートは「症状」に張る

アラート設計で最も重要な原則は、ユーザーに影響する症状(エラー率の上昇、応答遅延など)に対してアラートを張ることです。考えられる原因1つ1つに 個別のアラートを設定すると、原因の数だけアラートが増えてしまい、運用が破綻します。

# 原因ベースのアラート(避けたい設計) - 原因が増えるたびにルールも増える
alert: DBConnectionPoolNear80Percent
alert: DiskUsageAbove85Percent
alert: ThirdPartyApiSlowResponse
alert: CacheHitRateBelow50Percent

# 症状ベースのアラート(推奨) - ユーザーへの影響を直接見る
alert: HighErrorRate
  expr: rate(http_requests_total{status=~"5.."}[5m])
        / rate(http_requests_total[5m]) > 0.05
  for: 5m
  summary: "直近5分のエラー率が5%を超えています"

アラート疲れを防ぐ設計

アラートが多すぎると担当者は次第に通知を無視するようになり、本当に重要な異常も 見逃してしまいます。これをアラート疲れと呼びます。

• 継続時間の考慮: 一瞬の跳ね上がりで発火せず、一定時間(forの指定)継続した場合のみ通知する
• 重複排除とグルーピング: 同じ根本原因から生じた複数のアラートを1つの通知にまとめる
• 重要度の段階分け: 即座の対応が必要なものと、翌営業日でよいものを分けて通知経路を変える
• 定期的な棚卸し: 発火しても対応不要だったアラートは閾値や設計を見直す

静的閾値と異常検知

「エラー率が5%を超えたら通知」のような静的閾値は シンプルで理解しやすい一方、トラフィックの季節変動が大きいサービスでは 誤検知や見逃しが起きやすくなります。より高度な仕組みでは、過去の傾向から 動的にベースラインを学習する異常検知を組み合わせますが、 導入・運用コストが上がるため、まずは症状ベースの静的閾値を丁寧にチューニングすることから始めるのが現実的です。

ポイント

• まずはレイテンシ・トラフィック・エラー・飽和度の4つのゴールデンシグナルを計測する
• アラートは原因ではなく、ユーザーに影響する症状に対して設定する
• 継続時間・重複排除・重要度分けでアラート疲れを防ぐ
• 静的閾値をまず丁寧に調整し、必要になってから異常検知の導入を検討する