内容采集系统(哪些地方需要监控哪些内容？又需要哪些指标？(图))

　　内容采集系统(哪些地方需要监控哪些内容？又需要哪些指标？(图))

　　在*敏*感*词*、分布式数据采集中，由于涉及到很多服务、系统、插件等，任何问题都可能导致数据采集出现异常。为了保证采集的稳定高效运行，一个能够实时监控采集各部分状态，并在出现异常时能够快速有效定位问题的监控系统是基本的。.

　　那么，在采集中，你需要监控哪里呢？需要监控哪些指标？今天从服务器、采集器、任务队列、信息源、数据质量、大数据平台等方面简单介绍一下需要监控的内容。

　　一：服务器监控

　　在*敏*感*词*、分布式的采集中，由于采集的范围很广，为了保证采集数据的及时性，可能需要几十台甚至几百台服务器。如何实时掌握每台服务器的状态，需要我们监控硬盘、内存、CPU等基础信息。并根据监控情况，合理配置采集策略。同时，当发现异常时，通过发送邮件等方式提醒相关人员进行处理。

　　1：硬盘监控

　　在采集中，我们经常会发现由于一些开发者忘记设置删除日志，或者在开发环境中进行测试的文件写入操作关闭，硬盘上的可用空间最终归零，导致当前服务器的部署。所有 采集器 都处于假死状态。

　　因此，我们需要近乎实时地监控服务器硬盘的使用情况（例如：每 5 分钟监控一次）。我们需要设置一个报警阈值，比如硬盘使用率>90%。如果超过此阈值，则会通过电子邮件向相应的运维或开发人员发送告警信息。为方便相关人员处理，告警信息应包括：盘符、使用率、服务器IP、用户名、密码、采集器部署路径等主要信息。

　　2：CPU监控

　　由于 data采集 是 I/O 密集型任务，而 data采集 使用的服务器一般性能较低，任务较多，运行时间较长。因此，如果 CPU 长时间保持高电平（阈值：30 分钟），可能会导致 采集器 假死，影响 采集器 的效率，降低 采集 的速度。此时，需要将当前情况发送给相应的人员。同时告警信息包括：服务器IP、用户名、密码等，方便运维人员快速处理问题。

　　3：内存监控

　　采集涉及大量的数据分析工作，会占用很多内容。如果内容使用率长期居高不下（阈值：30分钟），将向相关人员发送报警信息。报警信息包括：服务器IP、用户名、密码等信息。

　　第二：采集监控

　　采集Monitoring也属于运行时监控，主要用于监控采集器、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：采集器日志分析。每分钟监控“采集器Monitoring”中第二项产生的日志；

　　2：接口日志分析。当接口收到请求时，会将心跳信息保存到 Redis。如果第一条不能判断接口状态，分析心跳日志。

　　3：守护进程。当界面启动时，我们启动一个守护进程。但是，正常的守护进程并不能保证其他接口可以正常访问。因此只能作为辅助判断条件；

　　三：源头监控

　　在大批量的采集中，涉及到上千个网站，列数从几十万到几百万不等。如何保证这些网站/列都是有效的，也是一件很麻烦的事情。我们通常在采集中通过以下方式进行监控。

　　1：在 采集 中监控

　　①网站/列状态监控

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

　　②网站/列的定期监控

　　采集器在监控中，我们记录并持久化每个任务解析的数据量指标。我们可以在一定的时间间隔内分析所有的记录，使请求返回码正常，但解析出的数据量为 0 ，识别为常规异常的任务同步到源系统，供运维人员手动处理；

　　2：离线监控

　　在采集中，网站或列的失败对采集的效率影响很大，会大大降低采集的能力。所以采集中对任务的监控只能作为对源的辅助监控方式。

　　源的离线监控主要监控网站/列的请求状态码，根据配置的规律匹配的数据量。

　　您可以编写一个独立的脚本来处理这些，也可以部署一个 采集器 专门用于监视源，分析源的状态并将其同步到源系统。

　　四：数据质量监控

　　对于提供舆情分析服务的公司，在数据采集中，最关注的维度是：标题、作者、发布时间、正文等。由于作者太难判断，我们主要检测标题、 时间和文本。一个元素。下面是我们检测的一般方法。

　　1. 采集 中的监控

　　①发布时间监控

　　一般情况下，我们将信息详情页正文中的第一次作为发布时间。然后判断解析后的时间是否在正常范围内。如果大于当前日期，记录任务ID，以当前时间作为发布时间；

　　②标题监控

　　在采集中，我一般将列表页中A标签的内容作为标题，同时在解析内容时进行二次验证。因为有些列表页面中A标签的内容是缩写，部分内容是隐藏的，需要在内容解析时进行二次处理才能得到正确的标题。

　　③内容监控

　　因为内容很难判断对错，我们暂时只判断是否为空。如果为空，则暂时将标题作为文本，并将当前信息的源任务ID记录在日志中，供运维人员二次处理。

　　针对以上三个维度的问题，反馈给相应的脚本或软件开发者，对采集器/script进行优化和完善。

　　2. 持久化期间的监控

　　在大批量的采集中，涉及到很多采集器和自定义的采集脚本。我们如何实时监控，这些脚本的持久数据质量如何？

　　我们的做法是统一数据持久化接口。界面中两次检查标题、发布时间、内容等属性，并预先定位异常，防止异常数据进入生产环境，影响产品的用户体验。同时根据异常数据的来源（因为我们采集的每一条信息都有记录脚本的开发者ID），将异常情况反馈给对应的开发者< @采集器/脚本。

　　采集全程需要监控的点很多，涉及的知识点也很多。上述维度的分析结果非常分散。如何将这些点和分析结果串起来？一旦出现异常，可以快速定位到问题点，这需要强大的前端系统。

　　今天就是这样，改天我将讨论如何构建这个系统。