監視アラートを役立つ通知にする：Fleetdの発生・復旧・配信設計

サーバーやルーターを一つの画面にまとめても、毎日開かないと異常が分からないなら、監視はまだ半分です。CPU、ディスク、オフラインの通知を追加するのは自然ですが、条件を書くことと役に立つ通知を作ることは別です。

短い変動ごとにメールが届き、同じ故障が数秒ごとに繰り返されれば、重要な通知まで見なくなります。一方、メールがないことも正常の証明にはなりません。

今回は Fleetd v0.3.0 のアラートを扱います。Linux と OpenWrt への導入に続き、報告がアラートになり、通知され、終了するまでを見ていきます。

アラートが意味するもの

現在の対象は報告途絶、CPU、メモリー、ディスク容量、inode、失敗サービス、異常コンテナ、WireGuard のハンドシェイク経過時間です。接続元アドレスの変化は単発イベントとして扱います。

容量不足は書き込みを止める可能性がありますが、高い CPU は予定されたビルドかもしれません。古いハンドシェイクも、通信していない相手なら直ちに障害とは限りません。閾値超過だけで業務停止を断定できません。

まず伝えるべきは機器、対象、成立した条件です。原因と対応は用途に合わせて判断します。Fleetd は具体的な検査を提供し、原因を自動断定したり CPU 上昇だけでサービスを再起動したりはしません。

一時的なピークと継続負荷を分ける

CPU とメモリーの既定閾値は 90%、継続窓は五分です。

alerts:
  offline: 40s
  cpu_percent: 90
  mem_percent: 90
  sustain: 5m
  disk_percent: 90
  inode_percent: 90
  wg_handshake: 5m

v0.3.0 の既定値であって、全機器に最適な設定ではありません。サーバー共通設定で、機器ごとの独立した閾値はありません。

説明用に、CPU が一瞬 98% になって終わる処理と、高負荷が続く機器を考えます。これは実測事例ではありません。継続窓は前者を除外し、後者について待ち行列、異常プロセス、予定された作業を調べるきっかけを作ります。

実装は窓内の CPU、メモリーの最小値を使います。最小値が閾値より高ければ、受け取った全サンプルが超過しています。 平均値でも、断続的な超過回数でもありません。90% ちょうどは「90% より高い」に含まれません。

最古のサンプルが十分古いことも確認し、三十秒の範囲の許容差を設けています。正確に五分間待つという意味ではなく、最低サンプル数や全区間の欠測の有無も検証しません。受信できたサンプルによる判断であり、連続観測の保証ではありません。

メモリーは総量から MemAvailable を引いた割合です。Linux の全キャッシュを利用不能とみなすわけではなく、通知だけでアプリのメモリーリークとも判断できません。

オフラインは報告が届かない状態

通常、基本報告は十秒ごと、評価は五秒ごとです。既定では約四十秒報告がないと、その後の評価でオフラインの対象になります。判定にはサーバーの受信時刻を使い、クライアントの時計を直接使いません。

原因にはエージェント停止、停電、ルーター障害、DNS、サーバーへの経路などがあります。通知だけでは区別できません。何回かの欠測を許容する設定であり、評価処理、DB、メールの時間も加わるため、切断四十秒後ぴったりの到着保証ではありません。

承認済みでも一度も報告していない機器は、離脱した機器として扱いません。サーバー起動直後は offline + 15s、既定で約五十五秒、新しいオフライン通知を抑えて再接続を待ちます。

したがって新規登録では最初の報告を確認する必要があります。また Fleetd サーバー自体が停止すれば、評価もメール送信もできません。監視システム自身には独立した外部監視が必要です。

通信断を既存障害の復旧にしない

ディスク警告が出ている機器が切断したとします。新しいディスク情報はありません。「今回超過を見なかった」だけで閉じれば、誤解を招く復旧通知になります。

Fleetd はオフライン機器の既存アラートを維持し、古いデータで別の状態を新規作成・解除しません。猶予期間を過ぎればオフラインを追加します。

報告再開後に改めて評価するので、オフラインが解除されてもディスク警告は残ることがあります。通信が戻ることと容量が空くことは別です。

遅い収集項目には別の時間尺度がある

ディスク、サービス、コンテナ、WireGuard は通常六回の報告ごと、およそ一分ごとに取得します。五秒ごとの評価でも、一分周期の情報を五秒単位の実時間情報にはできません。

項目	現在の条件
ディスク	マウント先の使用率が閾値を超過
inode	inode 使用率が閾値を超過
サービス	systemd の失敗ユニットを報告
コンテナ	restarting、unhealthy、または非ゼロ終了
WireGuard	過去にハンドシェイク済みの相手が時間制限を超過

容量と inode は CPU の五分窓を使わず、保存された直近の遅い指標を評価します。空きバイト数があっても inode 枯渇でファイルを作れないため、別の検査が必要です。

終了コード 0 のコンテナは除外します。単発ジョブの正常終了は障害とは限りません。非ゼロ終了、不健康、restarting は対象ですが、一分間の再起動回数を数える機能ではありません。また running だけで業務 API の正常性は分かりません。

WireGuard は過去のハンドシェイクがある相手だけを調べ、一度もない相手は飛ばします。クライアント報告時刻との差を使い、サーバーの時計との混在を避けます。古い時刻は手掛かりで、完全な疎通試験ではありません。断続的な相手には通信と keepalive の設定を理解して使います。wg_handshake: 0 で全体を無効にできますが、相手ごとの除外設定はありません。

復旧とは、まず条件が成立しなくなること

各評価で必要なアラート集合を作り、DB の未解除レコードと比較します。新規は開き、なくなったものは閉じ、続いているものは維持します。機器と対象で区別するため、マウントやコンテナごとに別の記録になります。

オンライン機器の CPU、メモリーでは、閾値以下のサンプルが一つあれば「全部が超過」が崩れます。低い復旧閾値や「正常がさらに二分続くまで待つ」といった条件はありません。開始の継続条件と復旧の条件は対称ではありません。

新しい遅い指標のない基本報告では、前の遅い指標を保持します。一方、新しい収集結果がツール不在や失敗で空リストになると、その対象の警告が消える可能性があります。以前失敗していたサービスが、照会の失敗によって一覧から消える例です。

項目ごとに「検査成功で正常」と「検査不能」を完全には区別していません。解除記録だけで業務復旧を独立に証明することはできません。前回のとおり、失敗サービス収集は systemd であり、OpenWrt の procd 健全性を完全に調べる機能ではありません。

重複防止と到達保証は別

同じアラートが開いたままなら、五秒ごとに新しいレコードや開始メールを作りません。条件が消えれば解除の変化を作り、一回の評価で生じた開始と解除を一通へまとめます。

集約単位はその評価で、数分間の追加集約や未解決障害の定期催促はありません。アドレス変化などの単発イベントは別経路で通知し、周期評価とすべてが一緒になるわけではありません。

状態を DB に保存してから非同期で送信します。メール失敗時はエラーログを残しますが、永続配信キューや自動再試行はありません。画面の記録は受信の証拠ではなく、障害が続く間、次の評価が失敗した開始メールを自動再送するわけでもありません。

重複防止は雑音を減らしますが、確実な配信、催促、担当者確認、エスカレーションの代わりにはなりません。

メール以外にも記録を残す

SMTP が設定されれば指定先へ送信します。ホストや宛先がなければログに出し、状態は管理画面で確認できます。language: zh はサーバーのアラートとメールを中国語にする設定で、ブラウザ側の画面言語とは別です。

指標は七日、解除済みアラートは九十日を保存し、定期削除します。昔の警告だけ残って詳細グラフがない場合があるため、長期調査には保存方針を別途考えます。

既存の接続元アドレスが変わると単発イベントを作ります。以前の IP に戻るまで続く障害ではなく、単なる出口変更かもしれません。

通知経路全体を確かめる

閾値の調整前に、発生、保存、通知、解除を理解できるか確認します。以下は推奨する検証で、本番で実施した障害の記録ではありません。

場面	確認すること
短い CPU ピーク	高値一回だけで継続警告にならない
継続超過のテストデータ	範囲条件を満たせば一度開き、重複しない
故障中に報告停止	元の警告を維持し、条件成立後にオフライン追加
同じ故障のまま報告再開	オフラインだけ解除し、元の警告を維持
SMTP 利用不可	記録と送信エラーがあり、自動再送を期待しない
収集不能	欠測が解除へどう影響するか確認する

閾値と時間窓は隔離環境の制御データで確認できます。本番のルート領域を満杯にしたり、遠隔接続を支えるルーターを不用意に切断したりする必要はありません。

既存テストにはディスク、コンテナの正常・異常終了、WireGuard 条件などがあり、報告からディスク警告を作る E2E 経路もあります。すべての状態遷移やメール配送を検証した証拠ではありません。

現段階では、小規模な自前環境で説明できるアラートが目標です。発生理由、繰り返さない理由、解除条件、通知が止まる箇所を明確にし、今後は収集能力と鮮度、信頼できる配信、機器別ルールを改善できます。次回は署名付き更新の検証、バージョン判定、失敗からの復旧を扱います。