有赞移动天网平台搭建

575次阅读  |  发布于3年以前

一、背景

在快速迭代的业务需求下，难免会出现一些线上 bug ，特别是在 SaaS 业务领域，线上 bug 对于商家来说大概率会影响经营，严重的话很可能引发故障。所以，我们对线上质量要求很高。针对线上 bug ，除了商家主动上报问题，后端还有自己的天网监控体系，进行主动发现问题，那移动端如何进行主动防控呢？所以我们也需要自己的主动防控平台。

为什么不可以直接使用后端的天网系统？

从功能来看，后端的天网更像一个线上接口日志存储，结合监控配置能力进行预警处理。经过分析，后端天网无法满足移动端的使用场景。

提高客户端线上质量，减少线上问题，主动发现与预防线上问题，及时报警与处理，降低线上问题的影响面。做到防患于未然。

二、整体设计

根据以上背景，可以得知，移动端天网平台相对于后端天网平台更复杂，涉及的技术点也比较多，主要有客户端、 PC 后台管理（下面内容简称 mpaas ）、后端服务、数据存储等。

整体流程是可以区分两部分，一部分为日志上报流程，数据来源是业务方客户端，另一部分为日志操作流程，操作方是 mpaas 后台。这两者的区别，主要是一个是数据的来源方，另一个是数据的使用方。

客户端上处理流程相对来说没有那么复杂，主要就是数据的采集与上报。其中核心逻辑都在业务服务中进行，比如日志内容整合，触发通知逻辑等。

mpaas 平台，是整个处理和报警的核心。提供问题查看、分配人员、状态变更、问题备注、通知策略等功能。

为什么我们自己做了数据存储以及移动天网平台，为什么还会依赖 skyLog 呢？

主要原因是，我们天网上报数据是区分等级，存在 info 、warning 、error 三个等级，对应上报问题等级不同，通知策略与处理流程也会有区别，但都是需要记录到 skyLog 日志平台上，类似打 log 日志。目前 info 级别的数据是不会存储到移动天网服务中，因为打日志内容不在报警范围内，所以查询打的日志内容就需要到 skyLog 平台上查询。具体两者区别参考前面第一部分背景介绍。

公司内部使用企业微信，针对企业微信可以自定义消息通知以及群机器人功能，可以使用企微提供的公开接口进行调用，很方便的实现通知报警能力，可针对不同业务场景，定制不同消息通知。针对本平台，当触发报警，比如 error 级别问题上报（后面会有具体通知策略分析），则会通过消息给负责人推送系统消息，以及群机器人触发报警。

例：零售移动天网报警群机器人

具体使用参考企业微信官网 api：https://work.weixin.qq.com/api/doc/90000/90135/90235

三、日志采集和上报

目前该平台对接的业务方，主要是针对的是公司各业务团队的移动端业务，日志的上报基础能力集中 Zanlogger 日志二方库。同时基于目前混合开发的现状，开发了 ZanlogWeex 和 ZanlogFlutterPlugin 来实现 Flutter 和 Weex 页面的日志需求。

1、日志信息采集

首先看下日志内容的组成：

其中，基础信息由 Zanlogger 自主收集，业务方使用的时候，只需关注相关业务信息。

//天网日志上报
Log.sky("info", "sale", "startPay", "goods is xxxxx")
Log.sky("warn", "sale", "changePriceFailed", "goods is xxxxx")
Log.sky("error", "sale", "db can not open", "error:xxxx")

设备型号，系统 os 版本，应用版本，用户 id ，店铺 id 等基础信息，在同个设备的大部分时间段内，都是相同的。考虑到流量和效率问题，没必要每条日志都上传。

Zanlogger 的实现方式是，应用启动时，获取设备唯一标识，上传一次基础信息。业务日志上报时，只需上传设备唯一标识。后端服务收到消息时，通过唯一标识获取基础信息，组合成完整的日志。

2、按级别策略上报

移动天网平台支持 error，warning，info 三种级别的日志上报，针对不同级别的上报信息，触发接口上报的时机也不同。

为了担心数据量太小，buffer 一直未达到上报的条件，或者网络原因，但是一直上传失败，同时会设置指定时间（例如 30s ）的轮询机制，一旦发现有未上传的日志，立即上报。

四、日志存储和报警设计

1、日志存储

实际场景中，日志的上报频率，和日志的内容大小是不确定的，基于性能考虑，后端的数据存储流程如下：

原因是，相较于 RDS ，HBase 更适合适合大数量的存储，于是日志完整内容存放在 HBase，两者通过每条日志存储时，生成的 uuid 关联。日志的频繁上报，使用 kafka ，保证峰值处理能力。

存储位置的问题解决后，接下来思考的是日志该以什么维度进行分组？

移动日志的解决方案是聚合 biz + sign + type + level + os ，取其 hashcode 。

这里为什么会将系统 os 作为分组因子呢？这里的原因是，基于现有场景分析，存在 pad 和 phone 同一个 sign 的报警，大概率是不同的代码流程导致的，应该视为不同问题去排查和分析。

2、报警策略设计

当 error 日志上报后，后端会通过企业微信服务，向指定的群发送消息，并且 @指定的人，影响范围大的问题甚至需要 @所有人。信息论中有个定律：“信息量越大，信息熵越小”，所以为了保证群消息的关注度，在保证关键信息触达的前提下，对群内成员减少不必要的打扰。

因此不是所有信息都需要发送到群消息，比较建议群通知的场景如下：

  1. 新问题出现。
  2. 已解决问题新版本再次出现。
  3. 阈值范围报警。

以上是我们提供的默认配置，也支持让业务方自定义。下一章节中会讲到相关自定义配置功能。

报警策略流程中需要用到以下概念：

完整的报警策略流程如下：

五、移动天网平台可视化介绍

该平台的核心功能就是对于上报问题的报警通知能力与处理能力，以及相关报警配置策略。这里对于客户端的上报相关没有什么可讲的，相关的数据上报策略前面也有讲。这里主要针对 mpaas 平台进行功能与策略介绍。

1、问题查看

问题列表页面：

问题列表主要展示上报的所有问题，上报时相同的问题会进行聚合，列表中每一条数据，代表相同一类问题。同时支持多种筛选条件进行快速查找。

问题详情页面：

针对每一类问题，点击详情进行查看上报的具体信息。详情中，会包含该类问题的所有上报信息，每次上报问题都可以查看具体上报内容信息，然后进行问题分析。

2、问题处理

当问题上报上来时，会默认进行分配给上一次处理该问题的人员，如果是新问题则会分配给对应业务 owner 进行处理。当问题在解决时，需要对问题人员及状态等进行变更。

针对问题处理的操作，主要有状态、人员、备注信息。如果状态为待发版或者已上线，则需要填写修复版本，用来保证该问题在低版本的误报情况，如果问题存在问题链接，则需要填写关联问题文档，方便后续查看与统计使用。

3、报警策略相关配置

前面有讲到，报警能力主要依赖企业微信进行通知到相关的人和群。实现自定义报警策略，那就需要相关策略配置功能页面。

3.1 配置后台页面

报警策略列表页面：

报警策略配置页面：

配置页面可以根据业务方需求，自行添加应用配置策略，可根据 error 和 warning 级别分别设置配置策略信息。在问题上报后，会根据不用业务方应用（ biz ）进行识别，采用对应的配置信息进行报警。

3.2 通知模板

通知模板主要分为三类，个人及群消息通知，日报和周报。

个人及群消息通知，主要是针对新问题及操作变更时进行通知。日报和周报更多的是关注统计相关的数据，针对上报问题日报情况，可以看出当日问题的处理情况，周报数量统计，可以看出本周的概要情况。

四、总结

对于移动端来说，线上问题的发生是比较严重的问题，特别是在零售这种线下场景，很可能一个问题会给商家带来资损的问题，所以对于移动端的质量问题要有高标准。除了开发阶段的 code review 和自测，测试阶段的自动化测试和人工测试，我们如何主动监控线上问题的发生就成了关键，移动天网平台的搭建就是解决线上主动监控的空缺。

目前移动天网平台在线上已经跑了近半年时间，其中有效帮助移动端主动发现线上问题数量占比已经达到 20% 。对于主动发现的问题，我们快速响应进行解决，目前主动发现的问题商家没有再进行上报。这对于商家和服务同学，以及开发都是一种效率和质量的提升。

Copyright© 2013-2020

All Rights Reserved 京ICP备2023019179号-8