趣店线上监控报警系统设计与实现
理想很丰满,现实很骨感,线上业务系统,绝对不会万事如意,外在因素太多,总会出现这样那样的问题,所以,智能监控和报警,变得尤为重要;线上问题永远都是最重要的问题,必须尽早发现尽早解决。
一、背景
一张网络图,比较形象的描述线上业务系统的状况,虽然有点儿夸张,但这不假:
二、大纲
- 业务监控系统架构分析
- 监控模块的设计与优化
- 监控智能化的一些尝试
三、业务监控系统架构
没有完美的架构,任何架构都是平衡妥协的结果
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数据
- 定义模型
- 训练模型
- 验证模型
在趣店监控系统中的实际应用和表现:
五、总结、经验、教训
- 线上问题,永远都是最紧急最重要的问题
- 异常判断问题本质上也是分类问题
监控系统设计过程中,一定要预防决策方式的局限性
盲人摸象:
局部&整体
- 血压高与高血压的关系
- 业务监控需要持续运营与优化,并且需要业务部门共同维护
- 必须要具备完善的异常处理流程
目前趣店集团监控系统已经覆盖到所有产品线的注册、登录、下单、授信、风控、放款、还款等流程, 接下来会继续在全面、准确、及时各方面进行优化升级,为趣店集团线上业务的稳定性保驾护航, 更是为广大趣用户放心使用我们的产品,提供绝对可靠的保证!