Scrapy Cluster爬虫调试是开发上线过程中比较麻烦的事情。主要原因是爬虫脚本是本地开发的,即使把开发环境尽量和生产环境配置类似,通过了测试并上生产以后仍然会碰到一些问题。最常见的情况就是生产环境没有数据,但是开发和测试环境有数据。这种情况下,我们就需要耐心地一步一步查看每一个环节的日志文件和数据。以下我们就假设线上爬虫没有数据这个故障来分析判断故障原因。
通常排查系统问题有两种方案,一种是自上而下的查看系统每一个环节的日志;另一种是自下而上的查看。在我们当前的情况下,由于最终的爬虫没有数据,个人建议自上而下的方向效率比较高。基于Scrapy Cluster的系统结构(详情见《Scrapy Cluster新手教程》),我们可以分别查看Kafka,Redis和Scrapy爬虫的日志和数据。
排查Scrapy Cluster系统中Kafka问题
由于Kafka和Redis之间是通过kafka_monitor.py
组建实现消息消费和传递的(详情请见《详解Scrapy Cluster中Kafka与Redis的消息生产和消费》),因此查看该组建的日志即可。
排查Scrapy Cluster系统中Redis问题
Redis的问题比较好查。主要是看对应的Key是否存在。如果存在的话,查看Key中对应的值是否正确。因此,只需要了解Redis中一些重要的Key即可。本示例中,由于爬虫没有数据。因此首先可以查看{spiderName}:queue和{spiderName}:{domain}:queue键值对是否存在(注意,Scrapy Cluster本身这个设计得非常低效,在实际使用中我们优化了性能,增加了{spiderName}:queue键值对)。具体可以参考《详解Scrapy Cluster中Kafka与Redis的消息生产和消费》。
排查Scrapy Cluster系统中Scrapy爬虫问题
如果推送给Kafka的爬虫指令正确的转换到Redis中,并且被Scrpay获取。那么问题的根源可以定位到Scrapy爬虫本身。我们可以在parse函数中的重要环节写一些log指令,查看输出的Log即可。以下是在编写分布式爬虫脚本中常犯的一些错误:
- parse函数必须使用yield而不是return
- 千万不要使用全局变量(由于分布式爬虫系统,使用全局变量无法在其它爬虫主机上生效)
- 爬虫脚本中不要使用特殊依赖包(由于分布式爬虫系统的爬虫主机特别多,只会安装常用的Python第三方库)
- 编写中间件时process_request等函数注意return的返回值
扫码联系船长