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