目
录
1.背景场景/实现的功能介绍
2.架构设计
3.核心模块
4.效果评估
5.难点/后续规划
背景场景/实现的功能介绍
集团经营日报的产出基于整个集团的各个BG数据，数据链路经过清洗过滤、逻辑加工、统计汇总等步骤，并在发送之前会针对产出数据进行一致性、完整性、波动性等⼀系列校验，校验通过后，采用更新数据库中最⼤有效数据⽇期维表的形式，经过BI工具帆软扫描感知后进⾏推送。在整个过程中涉及数据流转非常复杂，上游任务数量超过2300个，任何⼀个任务出现异常，如若不能及时处理都会影响⽇报产出的时效性，因此，必须在第⼀时间监控到异常，对异常问题进⾏快速定位并作出相应处理。
⽇报相关数据任务接⼊了星河平台的基线监控，能够通过设置承诺完成时间和预警余量，在任务链路无法在承诺时间完成时触发报警，对数据链路保障带来了⼀定的帮助。基线监控在⼀定程度上满⾜集团⽇报监控场景的需要，但目前流程存在数据校验如果不通过，会kill后续任务来阻断链路，并触发⼈⼯确认流程的的场景，在这种情况下，基线监控会将失败任务作为异常进⾏报警，同时⼈⼯确认页面为内网服务器部署，必须连接VPN才可访问，操作步骤繁琐且效率不⾼，其次，所有主题经营⽇报发送后没有⼀个统⼀的反馈，容易出现日报漏发的情况，尤其当主题数量上升后，人工统计确认所有日报是否正常发送完成也是⼀件耗时耗⼒的⼯作。
针对上述背景，基于企业微信开发了“哨兵”监控系统，将任务链路实时监控、校验⼈⼯确认和⽇报推送统计这⼏个主要的业务场景所需功能融合起来，结合更加定制化的的监控策略，辅以任务调度、异常任务统计等衍⽣功能，优化了整个⽇报产出流程的异常监控和问题排查，提⾼了处理效率，并且提升了日报推送的准点率。
架构设计
“哨兵”监控系统数据底层基于星河平台，通过企业微信实现交互控制，其架构体系主要分为5层，自下而上分别为：存储层、基础层、监控层、交互层和配置层，功能介绍如下。
架构图如下所示：
核心模块
3.1 数据模型
数据收集
监控所需要的数据主要分为两部分。第一部分是任务历史运行数据，这部分数据用于划定任务的标准运行时间，和基本信息的识别，例如任务ID和上线状态；第二部分是当天运行中的数据，例如当前的运行状态，负责人的信息，通过实时调取接口获取数据。
数据处理
由于模型需要根据任务开始和结束时间在相应时间窗口筛选被监控的任务，所以任务的参照时间采集尤为重要。这部分历经两版改进，第一版是使用近七天系统调度并且运行成功的开始和结束平均时间，这种策略面对特殊节假日流量激增导致的任务迟滞，会滚动影响后续时间的判定，不够稳定；针对这个问题，第二版采用箱线图模型，采集近三十天系统调度并且成功运行的开始和结束时间，剔除离群值后取平均值作为“标准时间”，计算方法如下：
如图所示，其中Q1和Q3分别为25%和75%的分位数，下限值为Q1-1.5*(Q3-Q1)，上限值为Q3+1.5*(Q3-Q1)。在上下边界之间的值即为有效值，参与平均值的计算。
数据存储
监控需要的基础数据包括任务的基本信息，例如调度ID、平均开始时间、平均结束时间、在线状态等，以及任务的对应主题和关联关系。
由于使用传统的行式数据库，对于任务链路的查找不方便，并且多次关联性能会大受影响。使用图数据库不但对于查找友好，并且数据处理及存储结构与视觉较为符合，能够体现任务（点）和依赖关系（边）的关系。
技术选型
在图数据库的选择上，选用的是CDB维护的NebulaGraph。Nebula Graph是一款开源的、分布式的、易扩展的原生图数据库，能够承载数千亿个点和数万亿条边的超大规模数据集，并且提供毫秒级查询。并且支持Spark和Flink导入数据，能够使用Spark的graphX作为图计算引擎。结合任务监控场景，能够满足需求。
Nebula Graph 由三种服务构成：Graph 服务、Meta 服务和 Storage 服务，是一种存储与计算分离的架构。每个服务都有可执行的二进制文件和对应进程，用户可以使用这些二进制文件在一个或多个计算机上部署 Nebula Graph 集群。下图展示了 Nebula Graph 集群的经典架构。
Meta 服务 ：基于 Raft 协议的集群，能够实现高可用，保证其稳定性。Meta服务主要用来管理元数据。
Graph 服务：主要负责处理查询请求，包括解析查询语句、校验语句、生成执行计划以及按照执行计划执行。
Storage 服务：负责图相关操作到KV操作的转换，查询和插入，以及数据的存储。
Nebula Graph 使用nGQL语言进行查询，支持灵活高效的图模式。在监控场景中使用nGQL语言进行查询可以避免传统行数据库中的带来的复杂关联问题。
库表设计
存储结构
Tag
任务的基本信息会以Tag的形式进行存储，字段如下：
Edge
任务边的关系没有额外添加属性，通过自带的rank，将最大日期更新任务ID设置为rank即可实现区分，目前支持主题如下：
入库更新
基于配置的各主题日报推送链路末端任务，每天定时通过递归的⽅式⾃动向上获取依赖，这种⽅式能够获取完整且有效的链路任务图谱。任务在星河中的依赖关系如下：
通过监控系统入库后如下：
可以看到，入库以后，任务的基本信息，和依赖关系，都能够完全体现，并且查询方便且高效。
3.2 实时监控
监控模型
以固定时间窗口进行动态扫描，扫描这个窗口内应该完成任务的完成情况，如果任务处于等待状态，则向上进行追溯，以此类推，直到上游任务状态为执行中或执行完毕为止。
在查询时间的三分钟前到查询时间的窗口里，查询该时间段内：
1. 应该开始运行的任务（即当前时间位于被监控任务平均开始时间和平均结束时间之间）。
2. 应该已经结束的任务（即被监控任务结束时间位于当前三分钟窗口时间内）。
图数据库中可以直接查询指向已知点的其他点，对于该依赖查询场景特别适合。
运行逻辑
系统查询运行逻辑如下所示：
获取任务列表
1.1 来自任务跟踪模块
这部分存储上一个扫描周期中需要复查的任务，任务列表来自redis缓存。
1.2 来自窗口扫描监测模块
通过nGQL扫描任务树中正在运行和应该完成的任务，这部分数据来自于Nebula Graph。
获取任务运行情况
通过星河平台接口，获取任务执行历史，取最新的一条记录，提取其结束时间，执行代码等信息。
信息比对
将范围内的任务及其最新一条记录时间、状态进行比对，涉及：
告警
告警信息通过企业微信和电话进行通知。
告警类型
告警推送样例
任务异常
任务卡死
任务异常等待
任务延迟
告警策略
现有告警策略主要围绕任务异常，延迟和等待来进行提醒，细节如下：
正在运行：
任务运行时间超过标准时间的80%，并且任务运行时间超过20分钟，触发告警。
任务在链路中延迟超过20分钟，任务运行时间超过标准时间的35%，并且运行20分钟以上，触发告警。
任务在链路中延迟超过20分钟，并且失败过至少一次，触发告警。
任务失败/用户取消：直接触发告警。
任务等待中：查询上游任务情况。
任务异常等待：针对任务刷数的情况，可能会对任务信号造成影响，体现为：上游所有任务运行成功，但是任务仍在等待，这种情况会直接触发报警。
3.3 异常追踪
任务追踪
命令：delay taskID|taskName
企业微信发送到后端通过查询模块进行查询。该查询使用递归的方式，从指定任务向依赖上游进行查询，直到任务在运行中。将运行时间和近七日平均结束时间相比较，计算得到该任务的延迟时间（a），之后获取并计算得到每一条链路的调度时间间隔（以平均运行时间计算而非设置的调起时间）(b)，用a和b进行对比即可获得单个链路的延迟情况，将所有的链路都进行计算后取最大链路延迟即为计算的延迟结果，再根据平时的任务结束时间可以推测出任务的预计完成时间。
举例如下：
查询的任务为“等待中”时，会自动追溯上游任务，上游任务如果不为“等待中”则不继续往上追溯。
取出非运行完成的链路，在图中为：
a) 查询任务--上游任务2--上游任务2-1--上游任务2-1-1。
b) 查询任务--上游任务2--上游任务2-1--上游任务2-1-2。
c) 查询任务--上游任务2--上游任务2-2。
计算每条链路每个任务之间结束与开始的间隔，求和，以a为例：
“查询任务--(间隔1)--上游任务2--(间隔2)--上游任务2-1--(间隔3)--上游任务2-1-1” 即为求“间隔1”至“间隔3”的和，然后减去当前查询出最上游的任务（2-1-1）延迟时间。
类似的，可以求出每一条的链路间隔时间之和与该链路所追溯最上游任务的延迟时间之差，对比得出最小值，它的绝对值就是最大延迟时间。
任务异常归因
该功能通过将异常任务，延迟任务按照不同主题进行归类统计，能够方便主题负责人排查原因，推动链路上游的提升任务质量。
统计样式如下：
3.4 交互功能（企业微信）
通过接入企业微信，“哨兵”监控系统能够实现星河平台任务查询和调度的便捷性，并且能够将监控结果以消息推送的形式发送至微信端，方便随时确认和处理，基于一套完整的任务信息查询、调度、统计、监控流程，可以在手机端完成以往需要电脑才能完成的工作，大大提升了效率。
支持功能
任务调度
用户信息与企业微信绑定，能够在保证权限安全的情况下对任务进行调度、查询、终止等操作。
在值班过程中，收到报警，可以使用该功能查询运行记录，快速确认报警状况，并且通过命令即可实现任务重试。如果需要在电脑上定位任务，也可以使用命令快速调取任务信息，包括任务负责人、任务链接等信息。
任务通知
根据校验脚本反馈数据校验情况，如果异常则可以直接通过手机端点击处理，⽆需登陆电脑。
以往数据校验异常需要⼈⼯确认页面（内网环境）必须连接VPN才可访问，上线“哨兵”监控系统后，可在微信中直接点击进行确认。
日报推送统计
提供日报当天的发送情况查询，包括邮件发送（数据质量校验）和最大日期维表更新（确认推出日报）。
此功能可以直观查看所有主题的产出情况。免除了逐个确认任务状态或者逐个查询邮件的繁琐过程。
效果评估
“哨兵”监控系统上线以后，日报产出延迟率下降明显，对于异常任务的报警精度有明显提升，大大提高了夜间异常问题的处理效率。系统上线后，近⼀个季度⽇报推送准点率提升了9.6%。
“哨兵”独特优势体现在很多细节上的优化，⽐如对于上游任务部分延迟，但是链路未发生延迟，不影响最终结果产出的情况，不会拨打电话，降低报警频次的同时提升了报警精度，减少值班同学夜间处理无效报警的情况。
难点/后续规划
5.1 难点
报警策略
在任务判断过程中，任务的当前运行状况是可以获取到的，但是提高报警的精准度，解决“没有必要的报警”问题是一个需要平衡和不断调整的问题。在“哨兵“系统开发过程中，结合过往值班同学的反馈进行了反复的思考和改进。例如：当任务失败时，如果有负责人及时处理，不一定需要报警；当任务正常运行时，如果运行时间相对于以往有很大差别则需要报警，这些报警策略从项目开始时的单一规则逐渐扩展为复杂的多重规则，并且仍在不断完善中，以应对新的异常场景。对于报警的形式，也有所思考，例如：不同主题依赖同一个任务，则其报警信息会进行合并，只报一次。这些策略的复杂性作为系统开发的难点，也是系统的亮点。
图数据库的稳定性
路径的查找是单线程，会占用很多内存。在新版本中，为了提高扩展性，边的设计由原来的“每个主题一种边”变成了“同一种边通过不同的rank区分主题”，这使得图数据库在查询路径时容易崩溃，经过调整，由原先的25跳减少至6跳以保证稳定性。
5.2 后续规划
1. 增强智能性，针对特殊节假日，例如春节，进行兼容，提供链路延迟归因分析和改进建议。对资源使用情况进行统计，给出优化建议。
2. 接入机器学习，对于任务修改造成的任务时间正常变化做出判断。
作者简介
刘含，58同城TEG 经营数据部高级开发工程师
高剂斌，58同城TEG大数据部数据资深开发工程师
参考文献
Nebula Graph官网 (https://nebula-graph.com.cn/)
箱线图Boxplots (https://towardsdatascience.com/understanding-boxplots-5e2df7bcbd51)
本文分享自微信公众号 - 58技术（architects_58）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
