众所周知，大数据的浪潮已经来临，爬虫已经成为获取数据最重要的方式之一，而爬虫也会随着我们业务的增长变得越来越多，人工监控的成本越来越高，所以我们也会想各种方式来监控每个爬虫，一开始我们是直接从数据库入手，也就是监控数据库数据的增长量来做为爬虫是否出异常的依据，我们以一周为期限，如果一周内，数据落库的量为个位数，我们则确定该爬虫异常，但是后来发现这种方法的局限性，及时性差，错误位置不明确，导致修复爬虫时间长。

    后来我想从爬虫框架入手，我以python的scrapy爬虫框架为例，首先我们的目的是为了及时监控爬虫异常以及明确的异常位置，让维护人员能及时的修复异常爬虫；再者尽量少的修改原本我们的每个爬虫代码(最好不修改),一开始我想过修改scrapy框架的源码也就是修改scrapy框架的异常处理代码，但是发现这并不是很好的方法，也想过封装xpath等函数，来反映未捕捉到数据时，但是这种方案也不合理。最后我受到java中异常类定义的启发，在不修改原本其他item的情况下，多定义ExceptionItem这个类来放异常数据具体字段要对照每个项目的具体情况，基本字段有爬虫名，错误信息，若需要BUG重现那么还需要对应异常的html中的body体，再者就是在每个爬虫except里面进行yeild exceptionItem，exceptionItem对应字段的获取根据具体情况处理，因为所有的异常处理都一样，所有可以定义一个工具函数将相关字段传入即可，进行了以上处理后，我们会发现，不管这个数据是否异常爬虫都会抛出一个item，可能是异常item也可能是正常的item，而原本是若发生异常则不yield item，这样就会导致我们不知道是原本网站没有更新数据，还是爬虫爬取过程中出了异常。完成了以上工作之后，我们就要去完成最重要的一步，也就是定义了一个异常pipeline，也可以说是过滤发生异常的item，scrapy官网我们知道，item可以进入多个pipeline，直到用户抛出raise DropItem(“Duplicate item found: %s” % item)时，该item不进入下一个管道，过滤pipeline可以对每一个item进行类型判断若为ExceptionItem则存入mongodb或者通过消息队列发送到处理中心在最终落到关系型数据库，若为其他非ExceptionItem，我们还可以对其重要字段是否爬虫到作为判断依据，例如新闻的title、conten没有爬取到则也生成一个ExceptionItem格式的异常item存入mongodb或者抛到异常消息队列，如果字段都正常爬虫则return item 进入下一个管道，进行原本应该处理的管道中。

#items.py

在末尾加入

#exceptionPipeline.py

#test_error.py

若有更好的监控方法，希望可以共同探讨

若该方法有不足之处，望大佬们提出

未经本人同意，请勿转载