突然ですが Scrapy v1.1.0 から Python 3 に対応して嬉しいですね。これまで Scrapy のために 2.7 で通してきたんで。
さて、今回は Scrapy における エラーハンドリング(例外処理) についてまとめようと思います。
スクレイピングという行為は外部の構造化されていないデータを取ってくるものなので例外はつきものです。
例外が投げられたとき 何となく正常終了したように見せる ことは厳禁です。例外から正しく復帰させるか、または例外が投げられたならば正しく落とすことが重要です。
でないと、その後に例外に気づいて調節→リトライできませんからね。
Scrapy データフローに沿ったエラーハンドリング
スクレイピング中に起こる不測の例外をキャッチするために通常の try ... except 文を使う事はできません。
なぜなら、我々が記述した Spider を実際に起動するのは Scrapy エンジンだからです。
我々は parse() メソッドを実装することはあっても、parse() メソッドに response を食わせて呼び出すことはしません。parse() メソッドの呼び出しは Scrapy エンジンの管轄になります。
では parse() メソッドでの処理中に投げられた例外は誰が面倒を見るのでしょうか？
デフォルトでは Scrapy エンジンが控えめにログに書き出してくれます。が、その動作をカスタマイズすることは可能です。
Scrapy でエラーハンドリングするために (私の観測範囲では) 以下の3種類の方法があります。
- Request オブジェクトを生成するときに errback を渡す
- Spider の spider_error シグナルをキャッチする
- Spider Middleware の process_spider_exception で処理する
それぞれ解説していきます。
1. Request オブジェクトを生成するときに errback を渡す
スクレイピング中、parse() メソッドの中で scrapy.Request のインスタンスを返すと、スクレイピング対象 URL を追加できます。
そのとき errback という名前付き引数に関数を渡してあげると、レスポンスの取得に失敗したときにその関数が呼ばれます。
こんな風に、
# spiders/foo.py import scrapy from scrapy import Request class FooSpider(scrapy.Spider): name = "foo" allowed_domains = ["httpbin.org"] start_urls = ( "http://www.httpbin.org/", # ステータスコード: 200 "http://www.httpbin.org/status/500", # ステータスコード: 500 ) def start_requests(self): for url in self.start_urls: yield Request( url, callback=self.parse, errback=self._errback # 200 以外が返ったときに呼ばれる ) def parse(self, response): return { "url": response.url, "status": response.status, } def _errback(self, failure): self.logger.error("### ERRBACK ###") self.logger.error(failure.type) self.logger.error(failure.getErrorMessage())
Request オブジェクトの errback にコールバック関数を渡しています。
コールバック関数の _errback() はリクエストに対して 200 以外のステータスコードが返ってきたときに呼ばれます。
上記のサンプルコードで start_urls に指定している httpbin(1) は色々なステータスコードで色々なレスポンスを返してくれる便利なサービスです。
1つめURLは ステータスコード200 が、2つめのURLは ステータスコード500 が返ります。なので2つめのリクエストは parse() ではなく _errback() で処理されることになります。
errback で指定したコールバック関数には failure オブジェクトを渡してもらえるので、エラーメッセージなどを取得することも可能です。
今回のログはこんな感じになりました
2016-09-24 22:35:08 [foo] ERROR: ### ERRBACK ### 2016-09-24 22:35:08 [foo] ERROR: <class 'scrapy.spidermiddlewares.httperror.HttpError'> 2016-09-24 22:35:08 [foo] ERROR: Ignoring non-200 response
ところが、この方法は私の求めている例外処理ではありません。
なぜなら parse() メソッドの実行中に何かしらの例外が投げられても、_errback() が呼ばれることは無いからです。
_errback() が呼ばれるのは
- リクエストに対して 200 以外のステータスコードが返ったとき
- そもそもDNSルックアップに失敗したとき
- リクエストがタイムアウトしたとき
この場合に限ります。
ステータスコード200 が返って、そのあとに parse() で例外が投げられたとしても _errback() は呼ばれません。
この方法は「全部でnページ分のリクエストを投げてmページの取得に失敗した」みたいなログを残すのに使うようです。
あくまでもダウンロード時のエラーに対処する目的ですね。
2. Spider の spider_error シグナルをキャッチする
というわけで、本当の例外処理です。
パース中に例外が投げられると、spider_error というシグナルが発生します。
spider_error シグナルにコールバック関数を紐づけることでエラーハンドリングが可能です。
# spiders/bar.py import scrapy from scrapy import signals class BarSpider(scrapy.Spider): name = "bar" allowed_domains = ["httpbin.org"] start_urls = ( "http://www.httpbin.org/", ) @classmethod def from_crawler(cls, crawler, *args, **kwargs): spider = super(BarSpider, cls).from_crawler(crawler, *args, **kwargs) # シグナルとコールバック関数を紐づける crawler.signals.connect(spider._handle_error, signal=signals.spider_error) return spider def parse(self, response): bar = 1 / 0 # ZeroDivisionError 例外が発生 yield { "url": response.url, "status": response.status, "bar": bar, } def _handle_error(self, failure, response, spider): self.logger.error("### HANDLE_ERROR ###") self.logger.error(failure.type) self.logger.error(failure.getErrorMessage())
from_crawler() の中で signals.spider_error シグナルと _handle_error() メソッドを紐づけています。
parse() メソッドの中の bar = 1 / 0 の行で ZeroDivisionError 例外が投げられます。
それが _handle_error() でキャッチされ、ログにエラーの詳細が吐き出される流れです。
ログはこんな感じ、
2016-09-24 22:38:15 [bar] ERROR: ### HANDLE_ERROR ### 2016-09-24 22:38:15 [bar] ERROR: <class 'ZeroDivisionError'> 2016-09-24 22:38:15 [bar] ERROR: division by zero
例のごとく failure オブジェクトを渡してもらえるので、カスタムのエラーログを書き出したりエラー詳細をメールで通知することも可能でしょう。
ところが、この方法ではパース中の例外の通知を受けることしかできません。
そう、エラーからの復帰が出来ない のです。
というわけで続きます。
3. Spider Middleware の process_spider_exception で処理する
最後の方法です。例外をキャッチして、復帰するところまでをやります。
そのためには Spider Middleware を自作する必要があります。
Scrapy のアーキテクチャを紹介でよく見る図ですね。Spider と Scrapy エンジンの間にあるのが Spider Middleware です。
カスタム Middleware を定義することで、
- Downloader から Spider に渡される直前のリクエストオブジェクト
- Spider から Pipeline に渡される直前のアイテムオブジェクト
- Spider から投げられた例外オブジェクト
この3つを加工できるようになります。
3つめのやつが本題ですね。
Spider で投げられた例外を Middleware の中で正常なアイテムにすり替えて Pipeline に流すことができるわけです。
これが try ... except で例外から復帰する処理に最も似ていると思いませんか？
カスタム Middleware 自体は普通の class として書きます。
# middlewares.py class HandleErrorMiddleware(object): def process_spider_exception(self, response, exception, spider): spider.logger.error("### PROCESS_SPIDER_EXCEPTION ###") spider.logger.error(exception) return [{ "url": response.url, "status": response.status, "error": str(exception), }]
このように、
そして、settings.py の中で有効化してあげます。
# Enable or disable spider middlewares # See http://scrapy.readthedocs.org/en/latest/topics/spider-middleware.html SPIDER_MIDDLEWARES = { 'example.middlewares.HandleErrorMiddleware': 543, }
そうして、先ほどと同じ Spider を走らせてみると、
2016-09-24 22:54:46 [bar] ERROR: ### PROCESS_SPIDER_EXCEPTION ###
2016-09-24 22:54:46 [bar] ERROR: division by zero
2016-09-24 22:54:46 [scrapy] DEBUG: Scraped from <200 http://www.httpbin.org/>
{'url': 'http://www.httpbin.org/', 'error': 'division by zero', 'status': 200}
このように、bar = 1 / 0 の時点で process_spider_exception() が呼び出されつつ、例外が無かったことにされてアイテムが流れています。
試しに、結果を JSON で保存してみると、
[ { "url": "http://www.httpbin.org/", "error": "division by zero", "status": 200 } ]
このようにエラーの詳細をアイテムとして流すことに成功しています。
ところが...
何度目の「ところが」でしょうか。
Spider Middleware の process_spider_exception には バグがあります 。
Spider Middleware のバグ
先ほどの process_spider_exception() ですが、通常のメソッドの中で投げられた例外は正しくキャッチしてくれますが、ジェネレーター関数の中で投げられた例外をキャッチすることができません 。(v1.1.3 時点)
Issue にも挙げられています。
どうやら Scrapy が内部的に依存している Twisted の挙動が関係しているらしく一筋縄では解消できないようです。
「help-wanted」というタグがつけられているのが絶望感を煽りますね。
Scrapy では複数のアイテムを抜き出して返すためにジェネレーター関数を多用しますからね。これは痛い。痛すぎる。
まとめ
というわけで Scrapy のエラーハンドリングの方法3種類をまとめてみました。
ちなみに、最後のバグについては、現時点でこれといった解決策を見つけられていません。 ひとまず今後の Isuue の流れを watch しておきます。あー、力が欲しい。
私からは以上です。
