数据平台初试（产品篇）——监控大屏初露面

申明：文中涉及到的图片均为原创，未经授权，不得使用。

公众号原文链接：
数据平台初试（产品篇）——监控大屏初露面
​
本文介绍在数据采集过程中不可或缺的一枚神器——数据采集监控大屏，如果想了解数据采集过程中的一些技术，欢迎查阅我的另外几篇文章，文末附有两篇数据采集文章的链接。先看下面三张图：



三张图，不同的时间段，对应的日采集数据量分别在10万，30万，110万，不断刷新自己创下的单日采集数据量记录，可能有人会好奇，为什么最后两天采集到的数据量有暴增的趋势，偷偷告诉你们，这两天是新架构设计方案完成之后，开始测试的两天，第一天轻松达到了53W数据，超过之前极大值近两倍，而第二天更是突破了100W，所以，前面的凹槽，就是新架构开发测试的时间了。图片出自数据采集监控大屏，完整图如下：

通过以上截图可以得知，目前数据平台总共采集了近700W数据，而最多一天采集数据达到了110W以上，日处理任务量达到30W以上，还能查看到不同业务通道采集到的不同数据的数据量。这个大屏建设的初衷就是为了监控数据采集平台各方面的性能，在采集平台性能优化的同时，监控大屏也在不断优化自身的性能，占用越来越少的平台资源，其中最大的优化算是每日采集数据量统计图。而随着数据量的不断增加，不仅平台压力越来越大，监控大屏性能也越来越差，统计到的阻塞数量也越来越多，这个阻塞数目，监控的是内存中线程的阻塞数，如果这个数量越来越多，最直接的后果就是死机。而每天的数据量还在增加，业务也在扩大，硬件资源就那么多，急需寻找新的解决办法，在这种场景下，数据采集平台2.0架构设计横空出世，解决所有阻塞问题，而且将日采集数据量从30万提升到110万，理论值从50万提升到160万。数据采集平台2.0架构设计为将来的数据暴增预留了位置，支持分布式的横向扩展，这样，随着以后数据的增长，升级就变得非常简单了，接下来本篇文章主要介绍这款监控大屏。

监控大屏简介

监控大屏主要运用数据可视化技术，对采集平台进行监控，定时刷新平台运行数据，通过这款监控大屏，曾经发现了平台的一个死锁问题，当时问题非常隐蔽，平台没有报错，数据还在增加，通过大屏，意识到数据增长变得有一点慢了，有几张表没入库数据，后来开始排查，发现了平台死锁问题。如果该问题没被发现，后续造成的损失将变得不可控制。监控大屏功能如下：

1.每日采集数据量：统计平台近期，每天采集到的数据量，以此来判断平台在一段时间内的健康状况和负载情况。可根据该指标制定性能测试计划。

2.各主机执行任务统计：统计当前小时，各台机器执行任务的数量，以此来判断各个机器的性能以及资源配置。

3.全网数据量：统计整个平台实时数据量，以此来判断平台压力，确定是否需要升级新架构。

4.当前时间采集数据量：统计当前小时，每张表增加的数据量，对每一类数据是否正确入库做监控。

5.全网数据分布：统计平台所有表的数据量，以此来判断各表压力，为后续分库分表提供依据。

6.阻塞数统计：统计个主机中，各个程序阻塞的线程数，以此来判断各机器的性能，阻塞越多，内存占用越多，最终将导致机器宕机。理想情况是，此处为空白，即程序运行不阻塞。

7.各类任务执行数：统计不同种类任务，不同状态任务的数量，以此来判断平台执行任务的速度以及正确率。

8.采集速度监控，采用仪表盘监控当前实时的数据采集速度，以及监控过程中出现的采集速度峰值，以此来判断平台实时的效率。

通过以上八部分实时数据，即可监控整个数据采集平台运行状况。目前该大屏运行超过两个月，以下列举几个常见问题案例：

案例1

如下图所示，待执行任务有1440个，正在执行任务16个，主机执行任务统计图为空，且数据超过1分钟未刷新。

解析：任务无法执行，当前小时已经没有任务结束
原因及解决方案：
1.任务复杂，短时间内无法执行完成（几乎不可能有这种情况）
2.程序挂起，无法执行任务。需要重启程序
3.内存不足，程序自动结束。需要重启程序
4.机器宕机。需要重启机器。

案例2

如下图，丢弃任务暴增。

解析：大量任务已达到重试最大次数，或者出现大量已重置用户
原因及解决方案：
1.出现大量已重置用户。检查是否真的出现了大量重置用户，如确实如此，可不处理，平台会定时处理该类数据，只需等待20分钟即可。
2.接口被官方反爬，采集不到数据了。需要升级采集代码，优化采集策略。

案例3

如下图，当前时间采集数据量中，只有一两个表采集到数据且长时间没有新表加入。

解析：其他表在当前时间都没有数据入库
原因及解决方案：
1.当前为定向采集时间，只采集指定类型的数据。正常，无需处理。
2.其他类型的数据解析过程出错。检查数据，查看是否会有超长数据，空数据出现，导致解析失败。如：前期采集到重置用户时，导致解析器报错，现已适配。
3.历史数据中已经存在了采集过的数据，数据没有新增。正常，无需处理。
4.个别表锁表。需要排查数据库，杀死死锁进程。

案例4

如下图，各机器整体阻塞较高

解析：该部分统计每个机器上面每一类程序的阻塞情况
原因及解决方案：
1.同一任务阻塞较高。该任务代码性能不足，需要升级代码性能
2.同一机器不同任务阻塞较高。该机器硬件不足，需要减少任务量或者升级机器性能。

案例5

如下图，机器处理任务不平均，有机器“偷懒”。

解析：该机器执行任务相对其他机器明显偏少
原因及解决方案：
1.机器硬件性能较其他机器低。升级机器，使用相同配置机器。
2.该机器处理任务较复杂。优化取任务策略，不同类型任务随机获取
3.该机器的进程假死。需要重启该机器上运行的进程。

案例6

大屏数据更新正常，处理任务正常，但是数据增量较慢。
解析：数据增长较慢，但是处理任务速度正常，应该怀疑是否是由于丢数据引起
原因及解决方案：
1.有数据未解析，直接跳过。需要排查未处理数据的类型。
2.锁表。需要手动释放锁，修改代码，所有的写操作均用主键ID

以上为这两个多月时间中，见过的一些常见案例，此类问题均由该监控大屏抛出，并以解决。

本次文章就介绍到这里，主要介绍了自主研发的这款监控神器，下次介绍平台的架构演化，看看日采集数据是怎么从10W增加到100W的。

·end·

喜欢的朋友欢迎点赞收藏订阅，能点个关注就更好啦，我将不定时更新一些文章。公众号和其他平台不经常登录，如有需要，可以给我留言或者添加我的公众号同名微信“SPWanderer”，备注“交流”即可。

往期回顾

数据可视化大屏的价值——从超市实时营业额作战平台说起
实时大屏如何支撑海量数据处理——超市实时监控大屏V2.x
数据平台初试（技术篇）——抖音数据采集（初级版）
数据平台初试（技术篇）——抖音数据采集（高级版）