同期ジョブの誤検知を減らす：停滞判定と通知重複排除

「同期ジョブ、Running 50時間、転送0B。停滞疑い」。この通知が2時間おきに届きました。

一見すると、同期が止まったように見えます。しかし確認したところ、NAS本体は健全で、同期サービスもエラー0・警告0、成功5・実行中2でした。問題は同期ジョブではなく、監視の判定にありました。

正本の状態を見ると、ジョブは substatus: Synchronized、progress: 100、残バイト0、残ファイル0でした。転送中リストは空で、エラーも0。変更なしファイルは17,253です。リアルタイム同期ジョブは、同期済みのまま常駐し、コピー対象がなければRunningかつ転送0Bで待機します。初回に考えた「コピー対象が無いから0B」という仮説が、そのまま正解でした。

Runningと転送量0Bだけで停滞判定しない

元の停滞判定は、Runningが48時間を超え、かつ転送量が0Bであることだけを見ていました。これは状態そのものではなく、症状からの推測です。

常駐型やイベント駆動型の処理では、健全でも「実行中だが仕事量はない」という時間が生じます。ここを異常として扱うと、監視は正常な待機を繰り返し叩きます。

修正では、停滞の候補に次のガードを加えました。

• substatus が Synchronized ではないこと
• 残バイトまたは残ファイルが残っていること

つまり、見るべき状態は「Runningである」ことではなく、「残作業があるのに進んでいない」ことです。Error、Failed、Abortedのような明確な異常と、残作業ありで無進捗の状態は、引き続き検知対象に残します。

通知本文の識別子まで重複排除に含める

この件には、もう一つ故障がありました。通知は本来、前回から異常セットが変化したときだけ送る設計です。同じ異常を何度も送らず、変化だけを人間に渡すための重複排除です。

ところが、通知本文には「Running 50h」のような経過時間を入れていました。経過時間は監視が走るたびに増えます。すると文面も毎回変わり、差分比較は同じ異常を毎回「新規」と判定します。

判定の誤りが誤検知を作り、本文の可変値が重複排除を無効化して、2時間おきの再送を作っていました。情報を増やした一行が、通知を静かに壊していたわけです。

修正後は本文から経過時間のような可変値を外し、必要なら「>48h」のように閾値そのものを固定表現で示す形にしました。変動する数字は、詳細を確認する画面やリンク先に置くほうが安全です。

構文確認後に一度実行すると、復帰通知は1回だけ送信され、記録されていた異常一覧も空に更新されました。監視スケジュール、NAS設定、ほかの監視項目は変えず、判定ブロックだけを修正しています。

通知到達と通知内容を別々に検証する

通知そのものが届くかを、意図的な失敗で確かめる作業も必要です。通知経路の検証については、ntfyの自宅通知は、届く前に「401」と「届かないtopic」を先に見ておくで扱っています。

ただし、経路が正常でも判定が誤っていれば、届く通知はノイズになります。また、死活監視のように「落ちたら気づく」層には別の役割があります。Uptime Kumaの死活監視：DownとNotify失敗を実際に起こして見るも合わせて見ると、監視対象の状態、発報経路、通知内容を分けて考えやすくなります。

タイムアウトは不明として再確認する

別系統の監視でも、プリフライトの状態チェックがタイムアウトしたことを「失敗」と断定し、重大判定に昇格させた結果、後続処理全体をブロックしたことがありました。対象自体は正常でした。

ここではタイムアウトを判定保留、つまりinconclusiveとして扱い、重大判定へ直結させないよう変更しました。タイムアウト時間も20秒から45秒へ調整しています。判定できなかったことと、失敗していることは同じではありません。

ミュート前に判定条件を修正する

アラート疲れが始まると、通知をミュートしたくなります。その判断が必要な場面もありますが、誤検知そのものを放置すると、本当に必要な通知まで信用されなくなります。

向いているのは、常駐ジョブやリアルタイム同期のように、正常でも進捗が動かない時間を持つ運用です。向かないのは、状態の意味を確認せず、転送量や経過時間だけで異常を決める運用です。

所長のように、自宅ラボの通知を日常の判断材料として使いたい運用者が先に決めるべきなのは、「このジョブの正常なアイドルとは何か」です。その定義がなければ、48時間という閾値をどれほど調整しても、停滞判定は安定しません。

誤検知を監視バグとして直す確認項目

• アラート本文に、経過時間、カウンタ、累積値など増え続ける数字を入れていないか。
• 症状ではなく、システムが公開する正式な状態、完了状態、残作業を読んでいるか。
• 「実行中かつ仕事量0」を正常なアイドルとして定義できているか。
• タイムアウトを失敗と断定せず、判定保留として扱う余地があるか。
• 偽陽性が出たとき、ミュートではなく監視の不具合として修正対象にしているか。

監視の実装は、鳴らすだけでは半分です。正しいときだけ鳴るようにして、初めて運用の役に立ちます。

誤検知は「監視が動いている証拠」ではありません。監視のバグです。ノイズとして我慢した瞬間、その監視は人間の注意と信頼を消費し始めます。偽陽性を一件見つけたら、通知を消す前に監視へ不具合チケットを一枚切る。それが、狼少年にしないための最小限の保守です。