• 写在前面
• 本文主要内容
• 为什么要做结果级监控
• 应该把监控放在哪个模块
• 关于：指标的完备性
• 关于：异常的分类
• 关于：“趋势”和 “异常”
• 关于：选取最合适的视角
• 关于：如何提纯更准确的均值
• 关于：局部城市异常如何捕捉
• 关于：数据太分散，如何降敏
• 关于：均值不变，分布发生变化
• 新探索：质变刻画

---

写在前面

面对复杂业务系统如何更好的做监控和报警是一个困难的话题。在滴滴，几十个系统都会直接或者间接的影响最终订单的价格，本文是在做业务治理过程中一个小总结。

本文是在滴滴的工作总结，版权属于滴滴，内容已脱敏，转载请注明出处。

本文的主要内容

根据滴滴国际化出行业务的价格监控建设实践，把一些可迁移的经验总结下来：

【面向架构】 对监控的一些认识，为什么要做结果级监控【面向研发】 提升准召率的一些实践总结

做监控的最大困惑

1、为什么我有很多监控，出了问题还是没有提前发现 （召回率）

2设置、为什么监控总误报，时间长了，我也不看了 （准确率）

为什么要做结果级监控

现在系统架构越来越复杂， 主要有两个现象，

1. 模块和接口越来越多，而且还不断累积历史废旧逻辑

2. 请求链路越来越长，甚至变成了网状的拓扑结构。

所以带来的问题主要有：

1. 直接或者间接影响最终价格的因素太多，过程功能级别的监控几乎无法全量覆盖

2. 功能在不断变更，之前的监控很快就要废弃或者调整

# 思考的结论 #

借鉴混沌系统治理方法，面对多因素多变量系统，很难进行全方位白盒分支级别监控，

所以需要以黑盒形式处理，从最终结果衡量正确性

应该把监控放在有哪个模块

应该在有全局数据中心处建设监控。

理论上一个比较合理的业务架构应该是 “主线型”、 “汇聚型”、 “层次型”等， 这些都有一个共同特点，那就是有集中化的数据平面，在某个位置统一的数据汇集。

   -- - - [数据出口] --- / /

关于：指标的分类

首先，一个错误的认识是想用一个指标发现所有的问题，这样只会在每个指标上都蜻蜓点水，关键特征却又会遗漏。

结论：同一个指标的不同类型异常，需要用不同方法发现

异常分类：大幅异常、局部大幅异常、局部小幅异常、个例异常

异常的类型

关于：“趋势”和 “异常”

# 误区：

试图通过【大盘】来发现异常，往往陷入“误报”和“漏报”的漩涡

# 解法：

正向监控：大盘用来把控趋势发现整体异常

反向监控：明确定义出什么是异常，寻找出最大信息量有，在此基础上监控异常

# 举例【如何定义高速费异常】

订单1：总金额 100， 里程费 40， 时间费20，高速费40 → 高速费是否正常？→ 基本正常

订单2：总金额 50， 里程费 6， 时间费4，高速费40 → 大概率异常 （高速费占收入的80%）

订单3：司机高速费40，乘客总金额 30 → 异常 （高速费比乘客总额监控还大）

关于：选取最合适的视角

# 总结

横看成岭侧成峰，不同视角看数据有不同的表现，需要寻找最稳定的角度看数据

指标维度，包括数量、金额、比例

报警维度，包括大盘、品类、城市

# 场景举例：

场景1：倒挂类型，一笔可能损失好几万，

所以如果只用“倒挂订单数”，监控上几乎没有任何波动

场景2：品类之间有明显差异的，看头适合用“比例类型” ，

比如有的品类是一口价，有的是实时计价，

如果用一口价总金额或者订单量，非常容易受单量波动影响

关于：如何提纯更准确的均值

# 问题：

比如想监控整体单价是否有巨大波动，但是个别订单会造成整体趋势不稳定，进而报警也不好加，阈值加高了报不出来，阈值低了容易误报

# 方法：

提取核心特征，剔除边界噪音，让整体趋势熵更低 （如图，比如只取 3-20公里，时间大于1分钟的高质量订单。）

提纯更准确的均值

关于：局部城市异常如何捕捉

# 问题场景

比如有20个城市，只有2个城市异常时，在大盘数据上表现不明显； 如果针对每个城市都加报警又非常容易误报；

# 思路：

> 寻找到一种方法，对异常数据更灵敏，对正常数据更迟钝

加权调优思路

关于：数据太分散，如何降敏

# 场景：

有的数据熵比较大，本身比较分散，数据波动很大，不容易衡量异常，此时需要降敏

# 降敏方法：

临近值聚类，确定一批特征值，每个点向临近值做近似

数据降敏

关于：均值不变，分布已经质变

如图，上下两个图无论是均值、总额、订单数都基本一致

但是，明显看出两个图已经发生了很大的变化，如何捕捉这类异常？

# 方法:

> 使用均值偏报警离衡量法，只统计偏离均值N倍的数据

# 实际应用

识别蜗牛单： 行程 5公里， 行驶时间是12小时

识别火箭单：行程1公里， 实际金额200元 （均值应该是6元）

新探索：质变刻画

# 出发点

是否能寻找到一种数据衡量方式，

1、当数据有 “质的变更” 时能明确反应，

2、当数据只有 “量的波动” 时处于稳定状态

# 思路

把所有参与元素进行 降敏 聚类 签名，期望效果是量的变化不会改变签名值设置，质的变化会影报警响改变聚类或者直接改变签名

# 实际应监控用

1. 如何监控 “接口协议发生质变”

比如模块间json结构，屡次发生 "看头应该是int，传递了string"，"应该是数组，传递了null"

2. 如何监控 “基础费费用构成发生变化”

比如原来基础费由5个费项构成，某天变成了6个费项