两码一号（九）：业务监控

背景
大部分业务监控都是业务同学自己按照需求配置，业务间的监控一般无法感知到。这种玩法存在一些问题：

• 日志格式不标准，大部分都是自己用

• 监控配置繁琐，阈值调整反反复复，新产品上线需要从头来一遍

• 业务间的监控不好做，彼此口径不统一

• 应急处理时不同平台间无法统一口径

主要痛点就是监控零散、配置繁琐、应急效率低。

新生态业务监控
为解决目前的监控痛点，我们推出了基于两码标准建设的业务监控lego。通过两码的标准化管控，实现业务口径的统一、标准管理。

所谓生态是指监控体系的发现、定位、变更、预案等，基于这套标准，大家统一口径后能实现互通。

下面详细介绍新业务监控的玩法。

数据标准化
通过标准日志格式，来统一管控业务唯一标识。不同系统通过业务标识来沟通，达到口径一致的效果。标准日志格式主要包括：

• 非扩展区域，每个字段的含义都是固定的，可枚举的字段，枚举值是固定

比如 产品码=收钱码，事件码=支付，结果=成功，就很容易计算出"收钱码业务的支付笔数"。

• 扩展区域，支持业务自定义数据打印，但是必须可理解/管控。 以服务端日志举例， 以K-V形式打印（key1=value1, key2=value2,…)，其中key 要求提前申请，确保同样语义的业务含义的key定义是一致的。比如 pid=2088xxxxxxx(张三烧烤的店铺ID)，再结合非扩展区域，就可以衍生出"张三烧烤的收钱码的支付笔数"。

目前在蚂蚁，SPM、两码规范，分别从客户端/服务端视角进行了业务身份的定义，在这里不进行展开,相关文档见 https://lark.alipay.com/dc/antlogmng/vm5i1z https://lark.alipay.com/architecture/doc/hfsvf3

通过标准日志格式，我们就有了最基础的能力：

• 统一的业务语义

• 清晰的产品地图

• 自动的生命周期管控
  

数据模型化
基于标准数据，监控系统就可以设计出一套模型，标准数据进入模型后，自动完成监控部署。监控领域模型有兴趣可以看下lego的专题文章。

监控部署自动化
有了标准的日志，日志的切分就是标准化的，数据计算也是标准化的；通过标准数据建模，就可以自动完成监控初始化。简单说就是：

日志上线后，数据采集、数据计算、数据建模就自动完成了。

智能算法引擎
通过机器学习的能力来简化人工调整阈值的过程，lego的算法模块包括离线和实时两部分，通过协作完成动态阈值调整。

应急体系
有了业务唯一标识，不同平台间的互通就具备了。lego的监控告警发生后，就可以用唯一标识去查询其他兄弟平台的数据，提供给应急同学分析，达到快速应急恢复的要求。