趣店线上监控报警系统设计与实现

    理想很丰满，现实很骨感，线上业务系统，绝对不会万事如意，外在因素太多，总会出现这样那样的问题，所以，智能监控和报警，变得尤为重要；线上问题永远都是最重要的问题，必须尽早发现尽早解决。

一、背景

一张网络图，比较形象的描述线上业务系统的状况，虽然有点儿夸张，但这不假：

二、大纲

• 业务监控系统架构分析
• 监控模块的设计与优化
• 监控智能化的一些尝试

三、业务监控系统架构

没有完美的架构，任何架构都是平衡妥协的结果

3.1 设计背景

• 监控项不完善，需要快速完善监控项(痛点:快速实施)
• 运营活动频繁，报警收到麻木(痛点:报警太多)
• 上线调整时无实时直观的参考(痛点:不及时，不直观)

3.2 主流架构

3.2.1 案例

阿里：

蘑菇街：

3.2.2 特点

• 架构的核心关键字是:海量、实时
• 侧重于大数据的处理，报警分析偏弱，没有解决当时的痛点问题
• 公司已有大数据部门在做类似的事情
• 监控人手紧张且缺乏相关经验，存在一定风险

思考:大数据是否应该属于监控系统的一部分?

3.3 趣店当前监控架构

• 基于现有业务监控开发，利用已有资源
• 利用队列将系统拆分成不同模块，方便升级
• 利用现有的优秀开源软件

四、监控模块设计与优化

各个模块可以随时被更优的方案替换

4.1 采样模块

• 采集源：SQL、API、ElasticSea ch (实时日志收集)、其他更多
• 运行方式：crontab定时运行，Laravel队列执行采集任务

4.1.1 问题

• 某个采集变慢，导致整个采集不可用
• 大数据表性能雪崩
• 采集需要额外监控

4.2 存储计算模块

4.2.1 时序数据库

时序数据库(Time Series Database，简称TSDB)是用于管理时间序列数据的专业化数据库。 区别于传统的 关系型数据库，时序数据库针对时间序列数据的存储、查询和展现进行了专门的优化， 从而获得极高的数据 压缩能力、极优的查询性能，特别适用于物联网应用场景(物联网应用往往需要处理海量的时间序列数据)。

4.2.2 关键特性

• 针对时间特别优化，以时间为维度的高效查询
• 很方便的向下采样(downsampling)
• 海量存储能力
• 自动简单高效处理过期数据

4.2.3 TSDB排行榜

4.2.4 趣店的选择-InfluxDB

• 无外部依赖
• 快速使用
• 优雅的RESTFUL API
• 强大的类似SQL的查询语言
• 水平扩展
• 纯go编写

1）、InfluxQL具体表现：

# demo 1
SELECT <stuff> FROM <measurement_name> WHERE <some_conditions>

# demo 2
SELECT * FROM "foodships"

# demo 3
SELECT * FROM "foodships" WHERE "planet"='Saturn'

# demo 4
SELECT * FROM "foodships" WHERE "planet"='Saturn' AND time > '2015-04-16 12:00:01'

# demo 5
SELECT * FROM "foodships" WHERE time > now() - 1h

2）、使用中遇到的问题：

• 集群功能不再开源(社区已有项目在跟进，国内七牛公司有解决方案)
• 单点问题(InfluxDB Relay)
• influxDB为什么比Mysql高效?

3）、单点问题的解决方案：

通过写多份数据来保持高可用

4.3 展示模块

4.3.1 开源项目Grafana

• 界面比较漂亮
• 完整的API支持
• 丰富的数据源支持
• 报表功能很完善

4.3.2 基本概念

• 数据源 (Grafana只是一个时序数据展现工具，它展现所需的时序数据有数据源提供)
• 组织 (Grafana支持多组织，单个实例就可以服务多个相互之间不信任的组织)
• 用户 (一个用户可以属于一个或者多个组织，且同一个用户在不同的组中可以分配不同级别的权限)
• 行 (在仪表板中行是分割板，用于对面板进行分组)
• 面板 (面板是最基本的显示单元，且每一个面板会提供一个查询编辑器)
• 查询编辑器 (查询编辑器暴露了数据源的能力，并且不同的数据源有不同的查询编辑器)
• 仪表板 (仪表板是将各种组件组合起来最终展现的地方)

4.3.3 丰富的数据源

• Graphite
• ElasticSearch
• CloudWatch
• InfluxDB
• OpenTSDB
• KairosDB
• Prometheus

4.3.4 使用中遇到的问题

• Grafana默认存储为sqlite，存在单点风险
• 采集周期未满时显示问题

4.4 报警通知模块

4.4.1 设计特点

• 多种通知方式(短信，邮件，电话)
• 灵活的通知策略
• 基于组的通知人管理

4.4.2 遇到的问题

• 短信，邮件发送失败 (重要指标需要有多种通知方式)
• 重复报警频率限制，减少骚扰
• 人员入职离职修改麻烦 (基于组来管理)

4.5 异常决策模块

4.5.1 异常决策的难点在哪?

• 系统监控和业务监控相比，业务监控的问题更难定义
• 运营推广频繁加剧问题定义的难度
• 互联网金融行业对监控的要求更高

4.5.2 异常决策策略

1）、基于样本数据的对比策略

• 样本为近7天的值， 去除最高最低后的平均值
• 数据量小时，样本随机性高， 容易误报
  • 延长统计周期 (实物订单数)
  • 调整统计策略 (风控通过率)
  • 降低异常判定敏感度(变化幅度，持续时间)
• 策略调整，运营活动频繁，样本经常不具有参考价值
  • 定义不变量指标 (白条客单价)
  • 定义活动，告知决策模块指标的预期变化

2）、基于预测趋势的对比策略

• 前提：正常曲线不会出现骤升或骤降
• 使用：灰色预测模型
• 特点：所需要的数据量比较少，预测比较准确，精度较高；如：新版Zabbix利用非线性回归预测磁盘空间占满的时间
• 问题：
  • Q1:曲线存在固有的骤升骤降情况
  • A1:使用实际数据与样本数据的比值来作为预测序列
  • Q2:异常曲线缓慢变化
  • A2:尽量多维度监控

4.6 智能化监控的一些尝试

让指标之间建立起某种联系

• 规则引擎
• 神经网络

4.6.1 规则引擎

1）、作用

• 规则外部化，即有利于规则知识的复用，也可避免改变规则时带来的代码变更问题
• 由规则引擎使用某种算法进行推理过程，不需要编写复杂晦涩的逻辑判断代码
• 开发人员的不需要过多关注逻辑判断，可以专注于逻辑处理

2）、举例

• IF
  • 登录数增加
  • 订单量增加
  • 新用户授信风控通过率下降
  • 新用户授信风控申请数增加
• THEN
  • 用户召回活动

4.6.2 神经网络

神经网络解决手写数字识别问题(MNIST问题)

• 下载MNIST数据
• 定义模型
• 训练模型
• 验证模型

在趣店监控系统中的实际应用和表现：

五、总结、经验、教训

• 线上问题，永远都是最紧急最重要的问题
• 异常判断问题本质上也是分类问题
• 监控系统设计过程中，一定要预防决策方式的局限性
  • 盲人摸象：局部&整体
  • 血压高与高血压的关系
• 业务监控需要持续运营与优化，并且需要业务部门共同维护
• 必须要具备完善的异常处理流程

目前趣店集团监控系统已经覆盖到所有产品线的注册、登录、下单、授信、风控、放款、还款等流程， 接下来会继续在全面、准确、及时各方面进行优化升级，为趣店集团线上业务的稳定性保驾护航， 更是为广大趣用户放心使用我们的产品，提供绝对可靠的保证！