数据采集中,如何建立一套行之有效的监控体系?

十点数据 1年前 ⋅ 1609 阅读

在大批量、分布式数据采集中,由于涉及到的服务、系统、插件等较多,任何一处出现问题,都可能导致数据采集中出现异常。为了能够保证采集稳定、高效的运行,一套能够实时监控采集各个部分状态,在出现异常的时候,能够快速、有效的定位问题的监控体系,是必不可少的。

那么,在采集中,哪些地方需要监控?又需要监控哪些指标?今天,我们就从服务器、采集器、任务队列、信源、数据质量、大数据平台等各方面,简单介绍一下都需要监控哪些内容。

第一:服务器监控

在大批量、分布式的采集中,由于采集范围广,为了保证采集数据的时效性,可能需要几十或上百台服务器。如何实时的掌握各个服务器的状态,就需要我们对硬盘、内存、CPU等基础信息进行监控。并根据监控情况,合理的分配采集策略。同时,在发现异常时,通过发送邮件等方式,提醒相关的人员进行处理。

邮件.png

1:硬盘监控

在采集中,我们经常发现,由于某些开发人员忘记设置删除日志,或者开发环境中用于测试的文件写入操作关闭,最终导致硬盘可用空间为零,导致当前服务器上部署的所有采集器均处于假死状态。 所以,我们需要近实时(如:5分钟监控一次)的监控服务器硬盘使用情况。我们需要设定报警阀值,比如硬盘使用率>90%,超过这个阀值则通过邮件,发送报警信息给相应的运维或开发人员。为了便于相关人员进行处理,报警信息应该包括:盘符、使用率、服务器IP、用户名、密码、采集器部署路径等主要信息。

2:CPU监控

由于数据采集属于I/O密集型任务,而且数据采集使用的服务器性能一般较低,且任务较多、运行时间长。所以,如果CPU长时间(阀值:30分钟)居高不下,就可能导致采集器假死,影响采集器的效率,降低采集速度。此时,就需要把当前情况发送给相应人员。同时,报警信息包括:服务器IP、用户名、密码等,以便运维人员迅速处理问题。 ** 3:内存监控**

采集中涉及到大量的数据解析工作,会占用大量的额内容,如果内容使用率长时间(阀值:30分钟)居高不下,则发送报警信息给相关的人员,报警信息包括:服务器IP、用户名、密码等信息。

第二:采集监控

采集监控也属于运行时监控,主要用于监控采集器、Redis、统一数据接口、任务处理等情况,这些也是采集出现异常时,查找、定位问题最重要的依据。

爬虫监控.png

1:采集器监控

数据采集中,首先要保证的就是采集器的正常运行,我们在实际运用中主要监测以下几方面的内容:

1:每次采集器启动,记录服务器IP、启动时间、及采集器ID等;
2:每次获取任务集合后,记录任务获取开始时间、结束时间、待采集任务的标识集合、采集器ID等;
3:任务执行过程中,记录单个任务的开始时间,下载开始时间、请求返回码、下载结束时间,解析耗时、解析的数据量、以及当前任务ID等;
4:所有任务均结束时,记录当前批次任务处理开始时间、结束时间、共解析数据量等;

上述四方面的监控,每天会产生很多日志信息,为了保证日志持久化不影响采集效率,我们把数据是暂存到Redis集群中。然后,每日对日志信息进行分析,同时清除一周前的历史日志。

对上述日志目前我们主要分析两方面:

1:根据日志信息,分析哪些采集器运行异常;
2:根据上述的第三点,筛选出请求码异常的任务,线下进行二次校验,并把结果同步到信源系统,进行最后人工审核;
3:对于上述第三点中,未解析到数据的任务,可能是网站改版导致正则失效,标识出该任务正则异常,并同步到信源系统,供人工处理。

对于上述三方面分析的结果,最后需要在信源系统中相应功能下进行展现,以方便相关的人员进行处理。

2:任务队列监控

我们所有的采集任务都是保存在Redis集群中,为了减少采集器的开发、运维难度,任务队列相关的逻辑处理,我们使用springBoot微服务接口来处理。所以,任务队列的监控主要是监控任务分发接口、及Redis服务是否正常、稳定。

1:Redis监控

redis监控.png

一般情况下Redis最重要的监控是内存、CPU、及各节点是否在线等,客户端连接数等辅助指标根据实际情况处理;

2:基于SpringBoot的Redis任务分发接口

我们的任务分发接口目前只有一个,所以如何实时监测其运行状态,就显得尤为重要。我们主要使用两种方式来检测:

1:采集器日志分析。每一分钟监测一次《采集器监控》中的第二条生成的日志;
2:接口日志分析。接口在接收到请求时,会保存一次心跳信息到Redis中。如果第一条无法确定接口状态,则分析心跳日志。
3:守护进程。接口启动时,我们开启了一个守护进程。不过守护进程正常,并不能保证其他接口能正常访问。所以,只能作为辅助判断条件;

第三:信源监控

网站监控.jpg

大批量采集时,涉及到的网站成千上万个,栏目更是少则几十万、多则上百万个,如何保证这些网站/栏目都有效,也是一件极其麻烦的事情。我们在采集中通常通过一下几种方式进行监测。

1:采集中监测

① 网站/栏目状态监控

采集器监控中,我们记录并持久化了每个任务的请求返回码指标,我们可以按一定的时间间隔分析一遍所有的记录,同时把这些状态码同步到信源系统,提示运维人员进行处理。

② 网站/栏目正则监控

采集器监控中,我们记录并持久化了每个任务解析的数据量指标,我们可以按一定的时间间隔分析一遍所有的记录,把请求返回码正常,但解析出的数据量为0的任务标识为正则异常,同步到信源系统,供运维人员进行人工处理;

2:线下监测

在采集中,失效网站或栏目对采集效率的影响是很大,会极大的降低采集能力。所以,采集中对任务的监控,只能作为信源的辅助监控方式。 信源的线下监控,主要监控网站/栏目的请求状态码,以及根据配置的正则,匹配出的数据量。 可以写一个独立的脚本来处理这些,也可以部署一个采集器,专用于信源的监控,分析信源的状态,并同步到信源系统。

第四:数据质量监控

对于做舆情分析服务的公司,在数据采集中,最关心的维度是:标题、作者、发布时间、及正文等,由于作者判断难度太大,我们主要检测标题、时间和正文三个要素。下面是我们检测的大致方法。

数据质量.jpg

1.采集中监测

① 发布时间监控

一般情况,我们把信息详细页正文中,第一个时间作为发布时间。然后判断解析以后的时间是否在正常范围。如果大于当前日期,则记录该任务ID,并把当前时间作为发布时间;

② 标题监控

在采集中,我一般把列表页中A标签内容作为标题,同时在内容解析时,进行二次校验。因为有的列表页中A标签的内容是简称,一部分内容被隐藏,那么就需要在内容解析时进行二次处理,获取到正确的标题。

③ 内容监控

由于内容难以判断对错,目前我们暂时只判断是否为空。如果为空,则暂时把标题作为正文,并把当前信息的来源任务ID记录到日志,供运维人员进行二次处理。

针对上述三个维度中存在的问题,反馈给相应的脚本或软件开发人员,优化完善采集器/脚本。

2.持久化过程中监测

在大批量采集中,涉及到的采集器、定制化采集脚本等很多,我们如何实时的监测,这些脚本的持久化数据质量如何呢?

我们的做法是统一数据持久化接口。在接口中对标题、发布时间和内容等属性,进行二次校验,把异常前置,以防异常数据进入到生产环境,影响产品的用户体验。同时,根据异常数据的来源(因为,我们采集的每条信息,都有记录脚本的开发人员ID),把异常情况反馈给相应采集器/脚本的开发人员。

采集全流程中需要监控的点很多,且涉及到的知识点很多,上面各维度分析的结果是很分散的,如何把这些点、分析结果串起来,一旦出现异常,能够快速定位到出现问题的点,这就需要一个强大的前端系统了。

今天就先这样,改天在说说这个系统大致可以如何构建。

全部评论: 0

    我有话说: