見張るものを4つに分ける

監視とは、壊れたときに、利用者より先に気づくための仕組みです。何を見張るかを4つに分けて考えます。

外形監視は「利用者に見えているか」、エラー監視は「中で何が起きているか」を教えてくれます。どれか1つでは足りません。サーバが動いていても、特定の画面だけ500エラーを返していることはあるからです。

naminori では、エラーを GlitchTip（エラーを集めて知らせるツール）に集めています。OSを更新したときは、作業の最後に、主要なページ（トップ・講座・求人・記事・ログイン）が正常に返ることを確かめてから公開に戻しました。

いちばん気づきにくいのは「動かなかった」こと

エラーが起きれば、エラー監視が気づきます。気づけないのは、そもそも処理が動かなかったときです。動かなければ、エラーも出ません。

naminori の実例を、設計の目で見直す

講座34の第1回で、naminori のサイトマップ（検索エンジンにページの一覧を伝えるファイル）を作る定期処理が、約6週間止まっていた件を見ました。ここでは「なぜ気づけない作りだったのか」を見ます。

• 定期処理を動かす環境で、必要な道具と設定が読み込まれず、起動すらしていなかった。起動しない処理は、エラーを出さない
• 出力を捨てる設定にしていたため、失敗しても何も言わなかった
• 同じ理由で、ほかの定期処理もまとめて止まっていた。新しく公開したレクチャーページ49本が、検索エンジンに伝わっていなかった

つまり、「失敗したら知らせる」も「動かなかったら気づく」も、最初から作られていなかったのです。

直したこと：失敗を知らせる、成果物を見張る

直したのは、壊れた原因だけではありません。気づけなかった仕組みのほうです。

1. 定期処理は共通の入口から動かし、結果を記録し、失敗したら通知する
2. 通知は、アプリが起動できない種類の失敗でも届くよう、アプリを経由せずに送る
3. 毎朝、できあがっているはずのもの（サイトマップと、定期処理の記録）が新しいかを確かめ、2日以上古ければ通知する

3つ目が大事です。個々の処理の失敗通知そのものが壊れていても、「成果物が古い」という症状の側から気づけます。実際、その後に別の定期処理が失敗したときは、通知がエラー監視に届きました。

最初に決めること

定期処理を1本足すときは、処理と一緒に次を決めます。

• 失敗したら、どこに知らせるか
• 動かなかったことに、何で気づくか（成果物の新しさ、最後に成功した時刻）
• 何日止まっていたら困るか（それが通知のしきい値になる）

• 外形・死活・エラー・定期処理の4つの監視
• 「動かなかった」ことは、エラーでは気づけない
• 定期処理が6週間止まっていた実例
• 成果物の新しさを見張る