在大批量、分布式数据采集中，由于涉及到的服务、系统、插件等较多，任何一处出现问题，都可能导致数据采集中出现异常。为了能够保证采集稳定、高效的运行，一套能够实时监控采集各个部分状态，在出现异常的时候，能够快速、有效的定位问题的监控体系，是必不可少的。
那么，在采集中，哪些地方需要监控？又需要监控哪些指标？今天，我们就从服务器、采集器、任务队列、信源、数据质量、大数据平台等各方面，简单介绍一下都需要监控哪些内容。
第一：服务器监控
在大批量、分布式的采集中，由于采集范围广，为了保证采集数据的时效性，可能需要几十或上百台服务器。如何实时的掌握各个服务器的状态，就需要我们对硬盘、内存、CPU等基础信息进行监控。并根据监控情况，合理的分配采集策略。同时，在发现异常时，通过发送邮件等方式，提醒相关的人员进行处理。
1：硬盘监控
在采集中，我们经常发现，由于某些开发人员忘记设置删除日志，或者开发环境中用于测试的文件写入操作关闭，最终导致硬盘可用空间为零，导致当前服务器上部署的所有采集器均处于假死状态。 所以，我们需要近实时(如：5分钟监控一次)的监控服务器硬盘使用情况。我们需要设定报警阀值，比如硬盘使用率>90%，超过这个阀值则通过邮件，发送报警信息给相应的运维或开发人员。为了便于相关人员进行处理，报警信息应该包括：盘符、使用率、服务器IP、用户名、密码、采集器部署路径等主要信息。
2：CPU监控
由于数据采集属于I/O密集型任务，而且数据采集使用的服务器性能一般较低，且任务较多、运行时间长。所以，如果CPU长时间(阀值：30分钟)居高不下，就可能导致采集器假死，影响采集器的效率，降低采集速度。此时，就需要把当前情况发送给相应人员。同时，报警信息包括：服务器IP、用户名、密码等，以便运维人员迅速处理问题。 ** 3：内存监控**
采集中涉及到大量的数据解析工作，会占用大量的额内容，如果内容使用率长时间(阀值：30分钟)居高不下，则发送报警信息给相关的人员，报警信息包括：服务器IP、用户名、密码等信息。
第二：采集监控
采集监控也属于运行时监控，主要用于监控采集器、Redis、统一数据接口、任务处理等情况，这些也是采集出现异常时，查找、定位问题最重要的依据。
1：采集器监控
数据采集中，首先要保证的就是采集器的正常运行，我们在实际运用中主要监测以下几方面的内容：
1：每次采集器启动，记录服务器IP、启动时间、及采集器ID等；
2：每次获取任务集合后，记录任务获取开始时间、结束时间、待采集任务的标识集合、采集器ID等；
3：任务执行过程中，记录单个任务的开始时间，下载开始时间、请求返回码、下载结束时间，解析耗时、解析的数据量、以及当前任务ID等；
4：所有任务均结束时，记录当前批次任务处理开始时间、结束时间、共解析数据量等；
上述四方面的监控，每天会产生很多日志信息，为了保证日志持久化不影响采集效率，我们把数据是暂存到Redis集群中。然后，每日对日志信息进行分析，同时清除一周前的历史日志。
对上述日志目前我们主要分析两方面：
1：根据日志信息，分析哪些采集器运行异常；
2：根据上述的第三点，筛选出请求码异常的任务，线下进行二次校验，并把结果同步到信源系统，进行最后人工审核；
3：对于上述第三点中，未解析到数据的任务，可能是网站改版导致正则失效，标识出该任务正则异常，并同步到信源系统，供人工处理。
对于上述三方面分析的结果，最后需要在信源系统中相应功能下进行展现，以方便相关的人员进行处理。
2：任务队列监控
我们所有的采集任务都是保存在Redis集群中，为了减少采集器的开发、运维难度，任务队列相关的逻辑处理，我们使用springBoot微服务接口来处理。所以，任务队列的监控主要是监控任务分发接口、及Redis服务是否正常、稳定。
1：Redis监控
一般情况下Redis最重要的监控是内存、CPU、及各节点是否在线等，客户端连接数等辅助指标根据实际情况处理；
2：基于SpringBoot的Redis任务分发接口
我们的任务分发接口目前只有一个，所以如何实时监测其运行状态，就显得尤为重要。我们主要使用两种方式来检测：
1：采集器日志分析。每一分钟监测一次《采集器监控》中的第二条生成的日志；
2：接口日志分析。接口在接收到请求时，会保存一次心跳信息到Redis中。如果第一条无法确定接口状态，则分析心跳日志。
3：守护进程。接口启动时，我们开启了一个守护进程。不过守护进程正常，并不能保证其他接口能正常访问。所以，只能作为辅助判断条件；
第三：信源监控
大批量采集时，涉及到的网站成千上万个，栏目更是少则几十万、多则上百万个，如何保证这些网站/栏目都有效，也是一件极其麻烦的事情。我们在采集中通常通过一下几种方式进行监测。
1：采集中监测
① 网站/栏目状态监控
采集器监控中，我们记录并持久化了每个任务的请求返回码指标，我们可以按一定的时间间隔分析一遍所有的记录，同时把这些状态码同步到信源系统，提示运维人员进行处理。
② 网站/栏目正则监控
采集器监控中，我们记录并持久化了每个任务解析的数据量指标，我们可以按一定的时间间隔分析一遍所有的记录，把请求返回码正常，但解析出的数据量为0的任务标识为正则异常，同步到信源系统，供运维人员进行人工处理；
2：线下监测
在采集中，失效网站或栏目对采集效率的影响是很大，会极大的降低采集能力。所以，采集中对任务的监控，只能作为信源的辅助监控方式。 信源的线下监控，主要监控网站/栏目的请求状态码，以及根据配置的正则，匹配出的数据量。 可以写一个独立的脚本来处理这些，也可以部署一个采集器，专用于信源的监控，分析信源的状态，并同步到信源系统。
第四：数据质量监控
对于做舆情分析服务的公司，在数据采集中，最关心的维度是：标题、作者、发布时间、及正文等，由于作者判断难度太大，我们主要检测标题、时间和正文三个要素。下面是我们检测的大致方法。
1.采集中监测
① 发布时间监控
一般情况，我们把信息详细页正文中，第一个时间作为发布时间。然后判断解析以后的时间是否在正常范围。如果大于当前日期，则记录该任务ID，并把当前时间作为发布时间；
② 标题监控
在采集中，我一般把列表页中A标签内容作为标题，同时在内容解析时，进行二次校验。因为有的列表页中A标签的内容是简称，一部分内容被隐藏，那么就需要在内容解析时进行二次处理，获取到正确的标题。
③ 内容监控
由于内容难以判断对错，目前我们暂时只判断是否为空。如果为空，则暂时把标题作为正文，并把当前信息的来源任务ID记录到日志，供运维人员进行二次处理。
针对上述三个维度中存在的问题，反馈给相应的脚本或软件开发人员，优化完善采集器/脚本。
2.持久化过程中监测
在大批量采集中，涉及到的采集器、定制化采集脚本等很多，我们如何实时的监测，这些脚本的持久化数据质量如何呢？
我们的做法是统一数据持久化接口。在接口中对标题、发布时间和内容等属性，进行二次校验，把异常前置，以防异常数据进入到生产环境，影响产品的用户体验。同时，根据异常数据的来源(因为，我们采集的每条信息，都有记录脚本的开发人员ID)，把异常情况反馈给相应采集器/脚本的开发人员。
采集全流程中需要监控的点很多，且涉及到的知识点很多，上面各维度分析的结果是很分散的，如何把这些点、分析结果串起来，一旦出现异常，能够快速定位到出现问题的点，这就需要一个强大的前端系统了。
今天就先这样，改天在说说这个系统大致可以如何构建。
