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

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

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

　　公众号原文链接：

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

　　本文介绍在数据采集过程中不可或缺的一枚利器——数据采集监控大屏，如果想了解数据采集过程中的一些技术，欢迎查阅我的另外几篇文章，文末附有两篇数据采集文章的链接。先看下边三张图：

　　

　　

　　

　　三张图，不同的时间段，对应的日采集数据量分别在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·