健康デーモンのアラート嵐：90件のSpamから静かな守護者へ

監視システムをデプロイして最も恥ずかしいこと——監視システム自体が最大のノイズ源になること。

Self-Health Daemonの誕生

OpenClawコンテナが増え、ヘルスチェック機構が必要に。Self-Health Daemon——軽量な健康デーモンを設計し、4つの重要な場所にデプロイ。30秒ごとに各サービスの状態をチェック、異常時はTelegramでアラート通知。

デプロイは順調でした。そして災害が来ました。

90+件のアラート爆撃

デプロイ完了から10分もしないうちに、Telegramが爆発。同じアラートが機関銃のように連射。最終集計：90件以上のspam alert。

原因は単純——アラートの重複排除とクーリング機構がない。同じ障害で30秒ごとに検査が走り、毎回失敗のたびにアラート送信。5分間の小さな障害で10件の同一通知。4つの検査ポイントを掛けると×4。

監視システム設計で最もクラシックなアンチパターンに見事にはまりました。

修正：30分間Cooldown

• 初回の異常検知 → 即座にアラート
• 30分以内の同種異常 → サイレント（ログのみ記録）
• 30分後も問題継続 → 再度リマインダー
• 問題復旧 → 復旧通知を送信、cooldownリセット

修正後、世界がやっと静かになりました。

Docker Rebuild後の権限の罠

アラート嵐の沈静後、一部コンテナのヘルスチェックがエラーを返し続けていることを発見。Docker rebuild後にuidが変わり、設定ファイルとログディレクトリのパーミッションが無効に。

イメージrebuildはuid一貫性を保証しません——Dockerfileで明示的に指定しない限り。

監視設計の教訓

1. アラートの重複排除は必須：オプションではなく基本要件

2. クーリング機構は初日から：爆撃された後に追加では遅い

3. アラートのレベル分け：すべての異常が通知に値するわけではない

4. テストには障害シナリオを含む

5. 監視システム自体も監視が必要

まとめ

90件のspam alertから静かで信頼性の高い守護者へ。良い監視は沈黙の番人——本当に必要な時だけ口を開く。「アラート疲労」を生むようでは、監視がないのと同じくらい危険です。