문제
디스크 사용량을 확인하는 로직이 정확해도, 상태 파일·잠금·임시 JSON 같은 제어 데이터를 감시 대상과 같은 파일시스템에 쓰면 실패를 알리는 경로가 실패 조건에 종속됩니다. 파일시스템이 가득 찬 순간 상태 갱신이 먼저 막혀 실제 경보가 전송되지 않을 수 있습니다.
운영 패턴
1. 감시 대상 파일시스템과 경보 제어 상태가 저장되는 파일시스템을 명시적으로 구분한다.
2. 임시 파일은 기본 임시 디렉터리에 맡기지 말고, 독립적으로 쓰기 가능한 상태 파일 옆에 원자적으로 생성한다.
3. 상태 쓰기 실패가 감시 루프 전체를 조용히 중단하지 않도록 오류 경로를 분리한다.
4. 정상 상태의 단위 테스트만으로 끝내지 말고, 감시 대상이 쓰기 불가 또는 용량 부족인 조건에서 실제 알림 전송을 검증한다.
5. 복구 뒤에는 상태 갱신, 중복 억제, 재알림이 모두 정상인지 다시 확인한다.
왜 중요한가
감시기는 대상의 고장을 관찰해야 하므로, 자신의 보고 능력을 그 고장과 같은 자원에 의존하게 만들면 안 됩니다. 제어 경로를 실패 독립적으로 두면 가장 필요한 순간에 경보가 사라지는 fail-open 동작을 막을 수 있습니다.
완료 기준
감시 대상이 가득 차거나 쓰기 불가인 조건에서도 상태 처리 오류가 명시적으로 관측되고, 경보가 실제 수신 지점까지 도착하며, 복구 후 중복 억제와 다음 알림이 정상 동작하면 경로 분리가 검증된 것입니다.
Problem
A disk-usage check can be logically correct while its reporting path is still fragile. If control data such as state files, locks, or temporary JSON is written to the same filesystem being monitored, the alert path depends on the exact resource that is failing. When the filesystem fills, state persistence may fail before the alert is delivered.
Operating pattern
1. Identify the filesystem being monitored and the filesystem that stores alert control state. Keep them explicitly separate.
2. Do not rely blindly on the default temporary directory. Create temporary state atomically beside a control file on an independently writable path.
3. Separate state-write errors from the monitoring loop so a persistence failure cannot silently abort notification.
4. Test more than the healthy path: make the monitored filesystem unwritable or capacity-constrained and verify delivery at the real receiving endpoint.
5. After recovery, verify state updates, duplicate suppression, and repeat-alert behavior again.
Why it matters
A monitor exists to observe a target failure, so its ability to report must not depend on the same failing resource. A failure-independent control path prevents fail-open behavior in which the alert disappears precisely when it is most needed.
Completion bar
The separation is proven when state-processing errors remain observable, the alert reaches the real receiver while the monitored target is full or unwritable, and duplicate suppression plus subsequent alerts still work after recovery.
问题
磁盘使用率检查逻辑即使正确，报告路径仍可能很脆弱。如果状态文件、锁或临时 JSON 等控制数据写在被监控的同一文件系统上，告警路径就依赖于正在故障的资源。当文件系统写满时，状态持久化可能先失败，导致告警尚未送达就中断。
运维模式
1. 明确区分被监控文件系统与保存告警控制状态的文件系统。
2. 不要盲目依赖默认临时目录；应在独立可写路径的控制文件旁原子创建临时状态。
3. 将状态写入错误与监控循环分离，避免持久化失败静默终止通知。
4. 不只测试健康路径；让被监控文件系统处于不可写或容量不足状态，并在真实接收端验证告警送达。
5. 恢复后再次验证状态更新、重复抑制和再次告警行为。
为什么重要
监控器的职责是观察目标故障，因此它的报告能力不能依赖同一个故障资源。让控制路径与故障相互独立，可以避免告警在最需要的时候反而消失的 fail-open 行为。
完成标准
当被监控目标写满或不可写时，状态处理错误仍可观察，告警能到达真实接收端，并且恢复后的重复抑制与后续告警仍正常工作，才算验证了路径分离。
問題
ディスク使用量の判定ロジックが正しくても、報告経路は脆いままかもしれません。状態ファイル、ロック、一時 JSON などの制御データを監視対象と同じファイルシステムへ書くと、アラート経路が故障中の資源そのものに依存します。容量が尽きた瞬間、通知より先に状態保存が失敗する可能性があります。
運用パターン
1. 監視対象のファイルシステムと、アラート制御状態を保存するファイルシステムを明示的に分ける。
2. 既定の一時ディレクトリへ無条件に任せず、独立して書き込める制御ファイルの隣に一時状態を原子的に作る。
3. 状態書き込みエラーを監視ループから分離し、永続化失敗が通知を静かに中断しないようにする。
4. 正常系だけで終えず、監視対象を書き込み不可または容量不足にして、実際の受信先まで通知が届くことを確認する。
5. 復旧後は状態更新、重複抑止、再通知の動作も再確認する。
なぜ重要か
監視は対象の故障を観測するためにあるため、報告能力を同じ故障資源へ依存させてはいけません。制御経路を障害から独立させれば、最も必要な瞬間にアラートが消える fail-open 動作を防げます。
完了基準
監視対象が満杯または書き込み不可でも状態処理エラーが観測でき、アラートが実際の受信先へ届き、復旧後の重複抑止と次回通知も正常なら、経路分離が検証されています。