静かなままの通知画面を見て「最近アラートが来ていないな」と少し引っかかっている一人運用の保守担当者
障害対応・運用監視約9分

「アラートが来ない」を疑う｜監視自体が止まっていないかの確認方法

「そういえば最近、アラート鳴ってないな」

その瞬間、少しほっとした自分と、なんとなく引っかかった自分の両方がいませんでしたか。

監視は、鳴っているうちは「動いている証拠」でもあります。逆に、静かな状態は「平和」なのか「監視が死んでいる」のか、通知が来ないという同じ見え方をします。沈黙は、良い知らせと悪い知らせの区別がつかない——ここが監視のいちばん怖いところです。

これは注意力の問題ではありません。仕組み上、気づけないようになっているだけです。この記事では、監視自体が止まっていないかを外側から確かめる考え方と、一人運用でも無理なく入れられる小さな仕組みを、一緒に整理していきます。

結論：やることは3つです。①監視サーバーやバッチが「生きている」合図を定期的に出す、②その合図が届かなくなったら、外部のサービスから自分に通知させる、③通知経路そのものを、定期的にわざと鳴らして試す。まずは③の「テスト通知を1回送ってみる」からで十分です。

何が起きているか：監視は静かに死ぬ

障害と違って、監視の停止はユーザーからのクレームが来ません。誰も困らないまま、静かに止まります。よくあるのは、こんな形です。

どれも、担当者が悪いわけではありません。監視は「異常を教えてくれるもの」なので、監視自身の異常だけは、誰も教えてくれないという構造上の穴があります。

考え方：沈黙を「異常」として扱う

本番サーバーを監視サーバーが見張り、その監視サーバーの生存合図を外部サービスがさらに見張っている三段構えの図
監視を見張るのは「外の見張り」。合図が途切れたら外側から通知が来る

解き方はシンプルです。「異常が起きたら知らせる」だけでなく、「正常なら定期的に合図を送る」を足す。そして、その合図が途切れたら異常とみなします。

この「合図が来ないことを異常と判断する」やり方は、デッドマンズスイッチ（運転士が手を離すと列車が止まる仕組み）に例えられます。Prometheusには、常に発火し続けるダミーのアラート（Watchdog）を用意して、それが止まったら外側で気づくという使い方が公式に紹介されています。

大事なのは、受け取る側を「監視の外」に置くことです。同じサーバーの中で自分の生存を確認しても、そのサーバーごと落ちれば意味がありません。外部のサービス、別のクラウド、最低でも別のネットワークに置きます。

一人運用なら、無料枠のあるヘルスチェック用SaaS（決めた間隔でHTTPリクエストが来なかったらメールやチャットに通知してくれるサービス）を使うのがいちばん手軽です。監視サーバーからcronで定期的にURLを叩くだけで、外側の見張り役が手に入ります。

同じやり方は、cronやバッチの「静かな失敗」にもそのまま使えます。詳しくはcronバッチの失敗を見逃さないもあわせてどうぞ。

具体例：3段階で確かめる

いきなり全部を組まなくて大丈夫です。手間の少ない順に、3段階で考えてみてください。

① 通知経路を、手で1回試す（今日できる）

いちばん軽くて、いちばん見つかるのがこれです。監視ツールのテスト通知機能を使うか、閾値を一時的に下げてわざと1回鳴らし、実際に自分の手元に届くかを確かめます。

確かめたいのは「検知できるか」ではなく、「届くか」です。Slackのwebhook URLは、アプリの再インストールや権限変更で失効することがあります。メールも、送信元の設定変更やフィルタで、いつの間にか迷惑メール行きになっていることがあります。

② 生存の合図を1本だけ入れる（30分くらい）

監視サーバー（または監視の役割をしているホスト）から、外部のヘルスチェックサービスへ定期的に合図を送ります。cronで1行足すだけです。

# 例：5分おきに外部の見張りサービスへ「生きています」と伝える
*/5 * * * * curl -fsS -m 10 --retry 3 https://<外部サービスのURL> > /dev/null

外部サービス側で「10分来なかったら通知」と設定しておけば、監視サーバーが落ちた・ネットワークが切れた・cronが止まった、のいずれでも自分に連絡が来ます。

URLやコマンドはサービスごとに違うので、必ず使うサービスの公式ドキュメントに合わせてください。また、このURLは知っている人なら誰でも叩ける鍵のようなものなので、公開リポジトリやチャットに貼らないよう気をつけます。

③ 「監視対象の一覧」を定期的に見比べる（月1回）

監視が動いていても、対象から漏れていれば同じことです。サーバー一覧・サービス一覧と、監視の登録一覧を並べて見比べます。

月1回が難しければ、サーバーを増やしたとき・入れ替えたときのチェックリストに「監視への登録」を1行足すだけでも効果があります。棚卸しの型はサーバー構成情報を1枚にまとめるが使えます。

影響：入れておくと、何が変わるか

沈黙を疑える状態になると、日々の安心の質が変わります。

逆に、ここが空いたままだと、監視は「入れてあるのに、いざという時だけ黙っている」状態になりかねません。せっかく作った仕組みを、ちゃんと効かせてあげるための最後の一手だと思ってください。

明日やること：テスト通知を1回送る

明日できる、いちばん小さな一歩はこれです。

  1. 監視ツールのテスト通知を1回送る（機能がなければ、閾値を一時的に下げてわざと鳴らす）。
  2. 自分の手元（チャット・メール・スマホ）に、実際に届いたかを確認する。届かなければ、そこが今いちばん危ない場所です。
  3. 通知先に、もう連絡がつかない人のアドレスが残っていないかを見る。
  4. 監視サーバーがどこで動いているかを確認し、監視対象と同じサーバー・同じネットワークにいないかを見る。同居していたらメモしておく（すぐ動かせなくて大丈夫です）。
  5. 余裕があれば、外部のヘルスチェックサービスに1つアカウントを作り、cronを1行足す。

1と2だけなら、たぶん10分で終わります。それだけで「通知が本当に届く」ことが確かめられます。

「監視が止まっていないか」チェックリスト

自分の環境に当ててみてください。全部に○が付かなくて大丈夫です。

よければ、こちらも

監視は「鳴らす設計」と「鳴ることを確かめる設計」の両輪です。あわせて読むと、全体の形が見えてきます。

外部サービスから届いたテスト通知をスマートフォンで確認して、監視が生きていると分かり安心している保守運用の担当者

アラートが来ない静かな日々は、本当に平和かもしれません。それでも、たまに「この静けさは本物かな」と確かめられる仕組みがあるだけで、夜の眠りは少し深くなります。

監視を入れた時点で、あなたはもう十分に備えています。今日はその備えが本当に届くかを、テスト通知1回で確かめてみるところからで十分です。

ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。

関連用語