美しいダッシュボード、しかしサーバーダウンに誰も気づかない
PrometheusとGrafanaを使って監視システムを構築するのに一週間かけたとしましょう。CPUやRAMのグラフが大画面で動いている様子は、非常にプロフェッショナルに見えます。しかし、深夜2時にデータベースがハングアップし、ウェブサイトが完全にダウンしてしまいました。朝起きて、上司からの大量の着信に気づき、ダッシュボードを見ると、数時間前から真っ赤な線が表示されている……という状況は避けたいものです。
どんなに素晴らしいダッシュボードも、それだけでは受動的モニタリング (Passive Monitoring)に過ぎません。誰かが画面を見ていなければ、すべてのデータは無意味です。本当に必要なのは、能動的アラート (Active Alerting)のメカニズムです。異変が起きた瞬間に、システムが担当者に自ら「ベルを鳴らして」知らせる必要があります。
なぜ障害を見逃してしまうのか？
多くの場合、問題はツールではなく、運用プロセスが最適化されていないことにあります。私の経験上、監視が失敗する主な理由は3つあります。
- データの孤立: メトリクスがPrometheusのデータベース内だけに留まり、外部へ通知するチャネルがない。
- SMTP設定への抵抗感: 構文ミスやGmailのセキュリティ設定を恐れて、Grafanaの設定ファイルを触るのを避けてしまう。
- 不適切なアラートしきい値 (Threshold): アラートが敏感すぎてノイズになるか、逆に遅すぎて手遅れになる。
TelegramやSlackが普及していますが、メールは依然として不可欠な公式チャネルです。障害の痕跡（監査ログ）を残してレポートを作成したり、JiraやServiceNowのようなチケット管理システムと連携したりするのに適しています。
Grafanaメールアラート設定の3ステップ
今回は、統合されたアラートインターフェースを持つGrafana v9/v10を例に説明します。プロセスは、SMTPの設定、コンタクトポイントの設定、そしてアラートルールの作成の3段階です。
ステップ1：設定ファイルでSMTPを有効にする
Grafana自体がメールを送信するのではなく、メールサーバーを経由する必要があります。Gmailを使用する場合は、個人のパスワードではなく、必ずアプリパスワード (App Password)を作成してください。
ターミナルを開き、システム設定ファイルを編集します。
sudo nano /etc/grafana/grafana.ini[smtp] セクションを探します。各行の先頭にあるセミコロン ; を削除して、以下のパラメータを有効にします。
[smtp]
enabled = true
host = smtp.gmail.com:587
user = あなたのメールアドレス@gmail.com
password = 16文字のアプリパスワード
from_address = [email protected]
from_name = Grafana Monitorファイルを保存し、サービスを再起動して変更を適用します。
sudo systemctl restart grafana-serverステップ2：UIでコンタクトポイントを作成する
Grafanaにログインし、Alerting > Contact points にアクセスして以下の手順を行います。
- + Add contact point をクリックし、
Ops-Team-Emailのような分かりやすい名前を付けます。 - Integration で Email を選択します。
- 受信側のメールアドレスをカンマ区切りで入力します。
- Test をクリックします。受信トレイにテストメールが届けば、設定は成功です。
ステップ3：実践的なアラートルールの設定
サーバーのCPU使用率が5分間90%を超えた場合にアラートを出す設定をしてみましょう。Alerting > Alert rules で以下のように設定します。
- Query: Prometheusを選択し、
100 - (avg by (instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)と入力します。 - Evaluation behavior: For を
5mに設定します。これにより、数秒間だけのスパイク（一時的な上昇）を除外できます。 - Details: 名前を “High CPU Usage” とし、ラベル
severity=criticalを付与します。 - Notifications: ステップ2で作成したコンタクトポイントを選択します。
実践アドバイス：アラート疲れ (Alert Fatigue) を防ぐ
以前の私が犯したよくある間違いは、あらゆるものにアラートを設定したことでした。CPU > 70%、RAM > 80%、Disk > 85%……。その結果、ある朝起きると500通ものメールが届いていました。これがアラート疲れ (Alert Fatigue) です。
受信トレイがジャンクメールで溢れると、人はそれらを無視し始めます。本当に深刻な障害が発生したとき、それは無意味な通知の山に埋もれてしまいます。以下の3つの黄金律を守りましょう。
- アクションが必要な時のみ通知する: CPUが高くなってもシステムが自動で処理できるなら、メールを送る必要はありません。人間の手動介入が必要な時だけ通知します。
- 通知のグルーピング (Grouping): 20台のサーバーが同時にダウンしたとき、20通のメールを受け取るのではなく、1通のメールに20台のリストが含まれるように Notification Policy を設定します。
- しきい値の定期的な調整: アプリケーションの負荷は月ごとに変わります。毎週15分時間を取って、アラートのしきい値が適切かどうかを見直しましょう。
プロフェッショナルな運用のためのヒント
個人のメールアドレスに送るのではなく、[email protected] のようなメールエイリアスやメーリングリストを使用することをお勧めします。これにより、担当者の退職や交代の際に、Grafanaの設定をいちいち修正する必要がなくなります。
また、マルチチャネルを組み合わせましょう。迅速な対応が必要な “Warning” レベルには Telegram を使い、記録と照合が必要な “Critical” レベルには Email を使うといった使い分けが効果的です。皆さんの設定が成功し、突然の障害に怯えることなく安眠できることを願っています！
