【要約】スクレイパーが壊れたことに、自分より先に気づく仕組み [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
スクレイパーを運用するエンジニアは、プロセスが正常終了する一方でデータが欠落する問題に直面する。エラーログや終了ステータスだけでは、以下の事態を検知できない。
- ・HTTPエラーやパースエラーは例外として検知可能である。
- ・サイト構造の変化により、空のリストを正常に返してしまう。
- ・スケジューラ自体が停止し、エラーログすら出力されない。
- ・これらはプロセスが正常終了（exit 0）するため、外部からは成功に見える。
// Approach
検知漏れを防ぐため、実行ジョブとは独立した監視プロセスによる二段構えの構成を採用する。具体的には以下の3要素で構成する。
- ・Scraper Job：実行結果（成否・取得件数）を記録する。
- ・run_log：SQLiteを用いてジョブ名や取得件数を蓄積する。
- ・Watchdog Job：履歴を定期的に確認し、異常を判定する。
- ・判定基準：「最終成功からの経過時間」と「取得件数の下限（min_count）」を用いる。
- ・通知：異常検知時はDiscord Webhookを通じて通知を行う。
// Result
最小構成の監視システムを導入することで、実運用における「静かな失敗」を可視化できる。導入による具体的な成果は以下の通りである。
- ・min_countの導入により、構造変化による空データ取得を検知できる。
- ・監視ジョブの分離により、スケジューラの沈黙も検知可能になる。
- ・外形監視を組み合わせることで、監視システム自体の停止にも備えられる。
- ・実測値に基づき閾値を調整することで、誤検知を抑制できる。
Senior Engineer Insight
> 本手法は、高価な監視ツールを導入できない層への極めて現実的な解である。監視を「人の判断を代替するものではなく、人を呼ぶボタン」と定義する割り切りが実戦的だ。ただし、閾値の決定には数週間の実測に基づく「育てる作業」が必要となる。スケーラビリティには限界があるが、運用コストと検知精度のバランスにおいて高い価値を持つ。