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

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

一、背景

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

www.zeeklog.com  - 趣店线上监控报警系统设计与实现

二、大纲

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

三、业务监控系统架构

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

3.1 设计背景

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

3.2 主流架构

3.2.1 案例

阿里:

www.zeeklog.com  - 趣店线上监控报警系统设计与实现

蘑菇街:

www.zeeklog.com  - 趣店线上监控报警系统设计与实现
3.2.2 特点
  • 架构的核心关键字是:海量、实时
  • 侧重于大数据的处理,报警分析偏弱,没有解决当时的痛点问题
  • 公司已有大数据部门在做类似的事情
  • 监控人手紧张且缺乏相关经验,存在一定风险

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

3.3 趣店当前监控架构

www.zeeklog.com  - 趣店线上监控报警系统设计与实现
  • 基于现有业务监控开发,利用已有资源
  • 利用队列将系统拆分成不同模块,方便升级
  • 利用现有的优秀开源软件

四、监控模块设计与优化

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

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排行榜
www.zeeklog.com  - 趣店线上监控报警系统设计与实现
4.2.4 趣店的选择-InfluxDB
www.zeeklog.com  - 趣店线上监控报警系统设计与实现
  • 无外部依赖
  • 快速使用
  • 优雅的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)、单点问题的解决方案:

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

www.zeeklog.com  - 趣店线上监控报警系统设计与实现

4.3 展示模块

www.zeeklog.com  - 趣店线上监控报警系统设计与实现
4.3.1 开源项目Grafana
www.zeeklog.com  - 趣店线上监控报警系统设计与实现
  • 界面比较漂亮
  • 完整的API支持
  • 丰富的数据源支持
  • 报表功能很完善
4.3.2 基本概念
  • 数据源 (Grafana只是一个时序数据展现工具,它展现所需的时序数据有数据源提供)
  • 组织 (Grafana支持多组织,单个实例就可以服务多个相互之间不信任的组织)
  • 用户 (一个用户可以属于一个或者多个组织,且同一个用户在不同的组中可以分配不同级别的权限)
  • 行 (在仪表板中行是分割板,用于对面板进行分组)
  • 面板 (面板是最基本的显示单元,且每一个面板会提供一个查询编辑器)
  • 查询编辑器 (查询编辑器暴露了数据源的能力,并且不同的数据源有不同的查询编辑器)
  • 仪表板 (仪表板是将各种组件组合起来最终展现的地方)
4.3.3 丰富的数据源
  • Graphite
  • ElasticSearch
  • CloudWatch
  • InfluxDB
  • OpenTSDB
  • KairosDB
  • Prometheus
4.3.4 使用中遇到的问题
  • Grafana默认存储为sqlite,存在单点风险
  • 采集周期未满时显示问题
www.zeeklog.com  - 趣店线上监控报警系统设计与实现

4.4 报警通知模块

4.4.1 设计特点
  • 多种通知方式(短信,邮件,电话)
  • 灵活的通知策略
  • 基于组的通知人管理
4.4.2 遇到的问题
  • 短信,邮件发送失败 (重要指标需要有多种通知方式)
  • 重复报警频率限制,减少骚扰
  • 人员入职离职修改麻烦 (基于组来管理)

4.5 异常决策模块

4.5.1 异常决策的难点在哪?
  • 系统监控和业务监控相比,业务监控的问题更难定义
  • 运营推广频繁加剧问题定义的难度
  • 互联网金融行业对监控的要求更高
4.5.2 异常决策策略
1)、基于样本数据的对比策略
www.zeeklog.com  - 趣店线上监控报警系统设计与实现
  • 样本为近7天的值, 去除最高最低后的平均值

数据量小时,样本随机性高, 容易误报

  • 延长统计周期 (实物订单数)
  • 调整统计策略 (风控通过率)
  • 降低异常判定敏感度(变化幅度,持续时间)

策略调整,运营活动频繁,样本经常不具有参考价值

  • 定义不变量指标 (白条客单价)
  • 定义活动,告知决策模块指标的预期变化
2)、基于预测趋势的对比策略
www.zeeklog.com  - 趣店线上监控报警系统设计与实现

前提:

正常曲线不会出现骤升或骤降

使用:

灰色预测模型

特点:

所需要的数据量比较少,预测比较准确,精度较高;

如:

新版Zabbix利用非线性回归预测磁盘空间占满的时间

  • 问题:
  • Q1:曲线存在固有的骤升骤降情况
  • A1:使用实际数据与样本数据的比值来作为预测序列
  • Q2:异常曲线缓慢变化
  • A2:尽量多维度监控
www.zeeklog.com  - 趣店线上监控报警系统设计与实现

4.6 智能化监控的一些尝试

让指标之间建立起某种联系
  • 规则引擎
  • 神经网络
4.6.1 规则引擎
1)、作用
  • 规则外部化,即有利于规则知识的复用,也可避免改变规则时带来的代码变更问题
  • 由规则引擎使用某种算法进行推理过程,不需要编写复杂晦涩的逻辑判断代码
  • 开发人员的不需要过多关注逻辑判断,可以专注于逻辑处理
2)、举例
  • IF
  • 登录数增加
  • 订单量增加
  • 新用户授信风控通过率下降
  • 新用户授信风控申请数增加
  • THEN
  • 用户召回活动
4.6.2 神经网络

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

  • 下载MNIST数据
  • 定义模型
  • 训练模型
  • 验证模型
www.zeeklog.com  - 趣店线上监控报警系统设计与实现

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

www.zeeklog.com  - 趣店线上监控报警系统设计与实现

五、总结、经验、教训

  • 线上问题,永远都是最紧急最重要的问题
  • 异常判断问题本质上也是分类问题

监控系统设计过程中,一定要预防决策方式的局限性

盲人摸象:

局部&整体

  • 血压高与高血压的关系
  • 业务监控需要持续运营与优化,并且需要业务部门共同维护
  • 必须要具备完善的异常处理流程
www.zeeklog.com  - 趣店线上监控报警系统设计与实现
目前趣店集团监控系统已经覆盖到所有产品线的注册、登录、下单、授信、风控、放款、还款等流程, 接下来会继续在全面、准确、及时各方面进行优化升级,为趣店集团线上业务的稳定性保驾护航, 更是为广大趣用户放心使用我们的产品,提供绝对可靠的保证!
www.zeeklog.com  - 趣店线上监控报警系统设计与实现