監視値が古いまま残る原因:stale判定を値と鮮度で実装

ガジェット・周辺機器を描いたアイキャッチ画像

監視を自作していると、「数字は取れているのに、どうも信用できない」という局面があります。画面表示やUIを読み取る計測、キャッシュ、外部APIのミラーを運用している人ほど、この違和感を見逃したくないところです。

前回の残量99%の嘘:監視値がおかしいときは実エラーを見るでは、計器表示と実際の状態が食い違う場面を扱いました。今回はその続きとして、古い表示を「今の値」にしないための部品を置きます。

目次

規則的な振動は値の鮮度を疑う

画面表示から読み取る計測が、週次の92%と82%を約3分周期で往復し、約2日間にわたってのこぎり波を描きました。同じ画面の同じ場所を読んでいるにもかかわらず、値の組だけが規則正しく戻る。これは値の計算ミスというより、更新されなかった画面を再読取していた症状でした。

更新指示が取りこぼされたサイクルでは表示が更新されません。そのまま読み取れば、数時間前のフレームを現在値として出力できます。履歴側の古い出力を避けていても、いま見えている画面自体が古いなら、監視には別のstale面が残ります。

画面内の時刻差でstaleを判定する

この表示には、次のリセット時刻が含まれていました。対象の枠は5時間で必ずリセットされます。21:45に取得したフレームが「18:50リセット」と示していたなら、その表示は現在のものではありません。

ここで必要なのは外部サービスへの問い合わせではなく、表示内容と取得時刻の照合です。表示内の時刻、カウンタ、更新周期のように、観測結果が自分で矛盾を示せる項目を探します。自己矛盾による検査は、取得元が不安定なほど価値があります。

stale判定をマージ前に実行する

実装の流れは単純です。取得したフレームを解析したら、値を保存・表示する前に鮮度を判定します。古い可能性があれば、そのサイクル内で1回だけ再試行します。それでも自己矛盾が消えなければ、値はマージしません。

失敗は黙って隠さず、たとえばstale_frame_rejectedのような明示ステータスとして残します。実行時のスナップショットには直前の正常値を保持しつつ、今回の取得結果は空/失敗として扱う設計です。ダッシュボードの表示は正常な観測結果へ戻り、過去ののこぎり波は履歴として残します。誤った履歴でも、当時に実際に出力されたデータである以上、消して整える理由はありません。

fallbackと鮮度ゲートの挙動比較

方針 出力の性質 残る弱点 適用条件
最後に成功した値を返すfallback 表示の欠損を減らせる 古い値を正常値に見せる危険がある 値に明確な鮮度表示があり、利用者が古さを判断できる場合
鮮度ゲート後に空/失敗を返す 誤った現在値を流しにくい グラフや表示に欠損が出る 監視値を自動判断や運用判断に使う場合

欠損は見栄えがよくありません。しかし、古い数値で埋められた滑らかなグラフより、理由の分かる穴の方が安全です。監視値をアラート、容量判断、作業の開始・停止に使うなら、後者を選ぶ意味があります。

修正後に残った読み取り競合

図解: 役割が違います(ロック / 鮮度ゲート / タイミング競合 / 古いフレームの自己矛盾)
図解: 役割が違います(AI生成)

鮮度ゲートを入れた同じ晩、別系統では93%と94%の±1%の揺れが見つかりました。再構成すると上振れは毎時:07分に集中していました。1時間周期のジョブと約3分周期のジョブが同じ画面を同時に操作していたためです。

さらに片方は、読み取り側が実行する6秒前に同じ操作を先送りしていました。画面を整えずに同じ操作が重なれば、どちらの取得結果がどの表示に対応するのかは不安定になります。この二重駆動は約1週間前から繰り返されていましたが、監視セッションを作り直したことでタイミングが変わり、表に出ました。

対処は、先送りをやめ、ロックで操作を直列化し、送信前に画面をクリーンアップすることでした。こちらの系統にも、リセット時刻ラベルを使った同じ鮮度ゲートを追加しました。

タイミング競合を完全に消すのは難しいものです。一方、古いフレームの自己矛盾は検出できます。この非対称性が重要です。競合を減らすための排他と、競合が残っても古い値を落とす鮮度ゲートは、役割が違います。両方を置いてください。

API・キャッシュ・監視値にも鮮度を持たせる

この問題は、画面表示から値を読む計測だけの話ではありません。キャッシュ、外部APIのミラー、センサ値、CIのバッジなど、「最後に成功した値」を返す実装は同じ病気にかかります。

返すべきものはvalueだけではなく、observed_atを含む観測結果です。値と観測時刻が離れているAPIは、利用側に古さの判断を押し付けます。取得元の表示に更新時刻や周期性のあるカウンタが含まれるなら、それも鮮度検査の材料になります。

所長がダッシュボードを見て異常に気づいたように、自動監視が鳴らないこともあります。だからこそ、値の上下だけでなく、値がいつ観測されたものかを記録する必要があります。修正後に別の揺れが見えたのも、最初の修正が失敗したからではありません。隠れていた層が見えるようになった、と読む場面です。

stale判定を入れる前の確認

  • 監視値に観測時刻を添えているか
  • 取得に失敗したとき、古い値を現在値として返していないか
  • 同じ取得元を複数のジョブが同時に操作していないか

計測値とは「値」ではなく「値と鮮度の組」です。鮮度のない値は、値ではありません。取得できないときは古い値で埋めず、空/失敗として残す。その不便さが、監視を監視として機能させます。

この検証を回している環境

この検証は、自宅の常設ラボ(使い捨てVM/LXCを回す母艦+GPU+VLAN分離ネットワーク)で動かしています。使っている機材と選定理由、全体構成は1本にまとめています。

ラボ構成のまとめを見る →
よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

目次