自社が運用するカンタン補助金では、2026-07に5xxエラーを検知する監視を新設した。ところがこの監視自身が、稼働させた当日から「測定できていない」を「異常なし」と取り違える罠を踏んでいた(出所: 自社の運用記録、確認日2026-09-06)。この記事は、その経緯と直し方をまとめる。
この記事で分かること
- 「0件」という報告が、本当にゼロなのか測定が失敗しているだけなのかをどう見分けるか
- 失敗を握りつぶして既定値に落とす書き方が、監視コードの中でなぜ危険に働くか
- 判定不能を0件と混ぜないための、通知側の直し方
この記事で分からないこと(正直に書く)
- 同種の構造がほかの監視スクリプトに残っていないかは、横断で洗い直していない
- 判定不能アラートを導入したあと、実際に何回発報したかの長期データはまだ無い
新設した監視が、稼働当日から異常を見逃していた
2026-07-10、カンタン補助金で5xx監視を新設した。課金ユーザーだけに500が返る不具合を19日間見逃していた反省からの対応だった。ところが稼働当日、データベース側の測定が一度も実行できていないのに、毎回「OK: 5xxなし」と報告し続けていた(出所: 自社の運用記録、確認日2026-09-06)。
「出力が無い」が「0件」に変わっていた
原因は2段構えだった。リモートホストへスクリプトを標準入力経由で流し込む経路の途中で、コンテナ内のコマンドを対話入力モード付きで呼び出していた。対話入力モードは標準入力を要求するため、そのコマンドが後続を読み尽くし、リモート側の処理は静かに終了していた。件数を表す行が出力されないまま、受け取る側は「出力が無ければ0件」として扱っていたため、「測定できなかった」が「0件」に変換されていた(出所: 自社の運用記録、確認日2026-09-06)。
なぜ気づけなかったか
監視のログに残るのは終了コード0と「OK: 5xxなし」だけで、「測定そのものに成功したか」を別の信号として持っていなかった。Googleの公式なSREドキュメントでも、監視システムは「何が壊れているか」と「なぜか」の両方に答えるべきだとされている(出所: https://sre.google/sre-book/monitoring-distributed-systems/ 、確認日2026-09-06)。今回の監視は、その手前の情報すら持っていなかった(出所: 自社の運用記録、確認日2026-09-06)。
判定不能を0件と分けて報告するように直した
2026-07に3点を直した。標準入力を使い切る対話入力モードの呼び出しをやめコマンドは引数で渡す形に変え、測定成功を示す明示的な合図を出力させ揃わなければ「0件」でなく「判定不能」という別種の通知に倒し、通知側はレポートの更新時刻を見て直前に書き直されていなければ内容を使わず止めるようにした(出所: 自社の運用記録、確認日2026-09-06)。
検査に何を書けば次は見つかるか
監視の健全性は、監視自身が返す「0件」だけでは分からない。測定経路をわざと止め「判定不能」が正しく出るかを確かめる較正を、監視追加のたびに行うようにした。この視点は監視の粒度とコストを扱った記事とも重なる。粒度を上げるほど、測定自体が失敗する経路も増える。
同じ「壊れているのに正常に見える」型の事故は、INFOレベルの失敗ログの記事や通信経路断でも正常終了に見えた記事でも扱っている。
自社の監視設計・障害対応について相談したい場合は、お問い合わせから編集部まで連絡してほしい。
よくある質問
Q1. 「0件」という監視の報告は、そのまま信用してよいか
信用できない場合がある。出力が無いことを0件として扱う書き方だと、測定が失敗しているだけでも「0件」と報告され続ける。今回はデータベース側の測定が一度も実行できていないのに、毎回「OK: 5xxなし」と報告していた。
Q2. 何が原因で測定が実行されなくなっていたのか
コンテナ内コマンドを対話入力モード付きで呼び出していたため、標準入力を読み尽くされて後続の処理が実行されないまま終了していた。
Q3. どう直したのか
対話入力モードの呼び出しをやめコマンドは引数で渡し、測定成功の合図が揃わなければ「判定不能」という別の通知に倒し、通知側はレポートの更新時刻を見て古い内容を使わないようにした。
Q4. この直し方はほかの監視にも当てはまるか
失敗を握りつぶして既定値に落とす書き方は監視コード全般のリスクであり、測定経路を止めて「判定不能」が出るか確かめる較正を監視追加のたびに行う価値がある。