这个组件非常适合订单履约场景。订单履约场景需要上报很多监控数据，包括商品类型、实付价（范围区间）、履约场景类型、渠道类型、提单页类型、客户端类型、折扣类型、用户所在城市等等。尽管在业务刚上线时没有必要监控所有字段，但随着业务的发展，产品和运营人员随时需要查看这些维度的监控数据。如果事先整理好这些字段，在运营人员需要时就可以实时地动态配置，相比临时加班写代码，大大提高了工作效率！
新手程序员初入职场，往往被安排一些 简单的小活 ，我也不例外，都工作六年了，也会被安排了一些小活，并且是紧急需求...... 接下来讲讲如何把一件"小活" 内卷成一个通用组件！
产品上周五让我增加一个监控打点的功能，即上报用户的客户端类型......（产品想看各个客户端的订单履约量）
我对此类小需求有些抵触，因为完成这样的任务无法体现个人价值。在年终述职时，我总不能向老板报告说：今年我工作很努力，添加了 N 个监控打点。更难受的是，上线过程要经过严格的流程控制和审批。在上线之前，必须制定上线方案并经过审批，在上线过程中还需要进行引流压力测试，撰写压测报告，并经过领导审批。整个过程十分繁琐，十分紧张......
不想干也得干！我立刻着手开发和测试，并以最快速度完成了这个需求。由于受到线上发布窗口的限制（周五不允许上线发版），我直到本周一才能进行上线，共花费了两个工作日。仅仅是添加一个简单的监控打点功能竟然需要花费如此长的时间，效率相当低下！
有没有什么办法可以更快地添加监控打点呢？一天的时间，我设计并落地了一个通用的 、可动态配置的监控打点工具。
何谓动态化配置监控打点
在我司上报监控打点 需要指定两个参数 chart 和 line。例如按照统计各客户端的订单履约量，需要上报
- chart 为 perform_ctype。
- name 为 ctype_{客户端类型} 大括号中为对应的客户端类型。
Monitor.report("perform_ctype", "ctype_"+ ctype);
监控平台会收集以上打点数据，创建图表后，就能展示 各个客户端的实时履约情况。
只加一个监控打点，只需要 5 分钟就能完成以上工作，但是却需要两天的时间走测试、线上发布的完整流程，效率极其低下。
如果预先把可能需要上报监控的字段整理出来，通过配置中心动态配置哪些字段需要上报，那么将极大提高效率。因为在配置中心添加配置非常快，能立即在线上生效！
配置中心：例如携程 Apollo携程框架部门研发的开源配置管理中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端
可以这样设计技术组件
- 使用方调用 monitor方法上报监控，其中 data 指定了可能要上报的字段值，configKey 为配置中心的Key，包含了监控配置。
Java
public static void monitor(Map<String,String> data, String configKey){
}data 中的数据如下
json
{
"ctype":1,
"channelType":45,
"priceRange":"5.0-10.0",
"skuType":"8"
......
......
}- 监控配置模型为 JSONArray 如下，包含字段名，上报的 chartName和 line 前缀。
json
[
{
"field":"ctype",
"chartName":"perform_ctype",
"linePrefix":"ctype_"
}
]如果想提供 channelType 的监控，只需要在配置中心添加一个json ，上报 channelType 即可，只需要 2 分钟就能完成这项工作！
- monitor 方法按照 JSONArray 中的配置，从 data 中取值并上报相关的字段监控。
这个组件非常适合订单履约场景。因为订单履约场景需要上报很多不同的监控数据，包括商品类型、实付价（范围区间）、履约场景类型、渠道类型、提单页类型、客户端类型、折扣类型、用户所在城市等等。尽管在业务刚上线时没有必要监控所有这些字段，但随着业务的发展，产品和运营人员可能随时需要查看这些维度的监控数据。如果事先整理好这些字段，在运营人员需要时就可以灵活配置，从而大大提高工作效率！ 这是我的个人经验！如果不这么做，就需要不停地紧急加班！
除了以上最常见的监控场景，我遇到的场景还包括这样一种场景
提供聚合能力的监控
客户端类型的划分维度会细化到 ios 和安卓。举个例子，饿了么的客户端类型可能包括 支付宝 IOS、支付宝安卓、饿了么安卓、饿了么 ios、抖音、微信小程序等。其他的产品，例如滴滴的客户端类型可能包括微信小程序、滴滴安卓、滴滴 ios、高德第三渠道等等。
产品要求客户端类型聚合上报。要按照 饿了么 App、支付宝 App、抖音、微信小程序这样的方式聚合。
于是我修改了配置模型，新增了 mapper 字段，其中配置了 ctype 如何进行映射！下面的 json 中，把安卓和 ios 类型统一，只区分 App 类型。
- 将 ctype 为 1, 2 映射为 1；
- 将 ctype 为 3, 4 映射为 2；
- 将 ctype 为 5, 6 映射为 3；
通过动态配置有个好处，如果哪一天新增一个客户端类型需要上报，只需要在配置中心配一下就行了，不需要修改代码！
为什么监控平台不支持聚合统计？我司基础架构组的监控平台是支持聚合的，但是我所在的核心部门使用的监控平台是老系统，功能简单原始！为什么不换新的，我也不知道......
json
[
{
"field":"ctype",
"chartName":"perform_ctype",
"linePrefix":"ctype_",
"mapper":[
{
"origin":[
1,
2
],
"target":1
},
{
"origin":[
3,
4
],
"target":2
},
{
"origin":[
5,
6
],
"target":3
}
]
}
]除以上场景外，好包括多个维度的聚合监控
多维度聚合监控
假如产品想看 小程序售卖订单的实付价区间监控，也需要看饿了么 App 售卖订单的价格区间监控，总之要查看每个 App 的实付价区间，如何提供动态配置呢?
这个场景我们实现方案是：拼接 ctype 和 priceRange 两个字段实现两个维度的聚合。（老的监控平台不提供多维度聚合能力，都是泪......）
String lineName = String.format("ctype_%s_price_%s", ctype, priceRnage); Monitor.report("perform_ctype_price", lineName);
如何优化配置模型呢？ 在之前的设计中， field、mapper和 chartName 是一对一关系。改为 一个 chartName对应多个 field就能支持多维度监控。
下面的 json 中，fields 包含多个 field。priceRange 和 ctype 会拼接为一个 line。
json
[
{
"chartName":"perform_ctype",
"linePrefix":"ctype_",
"fields":[
{
"field":"priceRange"
},
{
"field":"ctype",
"mapper":[
{
"origin":[
1,
2
],
"target":1
},
{
"origin":[
3,
4
],
"target":2
},
{
"origin":[
5,
6
],
"target":3
}
]
}
]
}
]总结
- 通过配置中心管理监控数据的配置，可以实时动态地添加监控打点，无需开发代码和上线发布，效率大大提高。
- 如果监控平台缺乏聚合能力，监控配置数据可以支持多维度上报，也可以支持重新聚合数据。
这个小工具实现原理非常简单，但是可以有效提高效率。当产品临时提出加监控时，我们就不用加班了！
留出更多的时间给自己，学习、发呆、摸鱼......