本文转载自微信公众号「猿天地」，作者尹吉欢 。转载本文请联系猿天地公众号。
监控，一直是个可以聊很久的话题。除了系统监控，还有一个往往容易被忽略，今天我们就来聊聊这个容易忽略的业务监控。
监控什么?
作为开发人员，不仅仅是把功能开发出来就行了，对于你负责的产品或者模块，你需要对它有足够的了解，时时刻刻需要关注着，要有初恋的那种感觉才行。
以电商最常见的下单功能来说，比如我想知道下单的成功率多少，下单的平均耗时，下单失败中有多少是因为库存不足下单失败的等等这类相关的信息。
有了这些业务指标信息，你就能知道你负责的产品现状是什么样的，以及你需要做哪些改进。
至于要监控哪些指标，得跟着你的业务走。目的很明确，就是需要知道业务的状况，并在某些时候能够触发告警。
实现方式
基于埋点的方式来进行数据的记录，记录到本地磁盘文件中，然后通过统一的日志收集程序收集存储，统计展示以及告警。
之所以基于埋点的方式实现是因为需要知道每个业务接口的执行结果，成功还是失败，失败的原因是什么。我们对于每个异常都定义了业务码，可以根据业务码知道异常原因。
如果用写日志的方式输出数据，记得将业务日志的数据文件单独出来，不要和系统的日志输出在一起，否则不好收集解析。
用logback可以单独配置一个appender，我这边只输出了我埋点的业务数据，Json格式的。
- <appender name="BIZ_FILE_APPENDER" class="ch.qos.logback.core.rolling.RollingFileAppender">
- <encoder>
- <pattern>%m%n${LOG_EXCEPTION_CONVERSION_WORD:-%wEx}</pattern>
- </encoder>
- <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
- <FileNamePattern>${LOG_HOME_PATH_BIZ}/${APP_NAME}.%d{yyyy-MM-dd}.log</FileNamePattern>
- <MaxHistory>7</MaxHistory>
- </rollingPolicy>
- <filter class="ch.qos.logback.classic.filter.LevelFilter">
- <onMatch>ACCEPT</onMatch>
- <onMismatch>DENY</onMismatch>
- </filter>
- </appender>
日志文件内容：
- {"biz":"confirm","bizCode":500,"domain":"storeOrder","bizId":"86081301","execTime":3,"count":"1","storeId":"1","userId":"740942"}
- {"biz":"confirm","bizCode":500,"domain":"storeOrder","bizId":"86081301","errorMessage":"/ by zero","execTime":14,"count":"1","storeId":"1","userId":"740942"}
注解埋点
BizLog注解用于业务监控埋点，里面具体配置字段说明如下：
- domain: 领域，比如 order,pay
- biz: 业务，比如 createOrder,cancelOrder
- bizId: 业务ID，比如 orderId
- addition: 扩展信息
addition可以配置多个additionField获取想要埋点的数据，数据可以从请求参数中获取，也可以从相应参数中获取，比如订单创建成功后，会返回订单ID, 那么bizId就是从响应参数中获取。
代码埋点
某些场景(支付回调，JOB任务等)下不太好通过注解方式埋点我们可以采用代码埋点的方式来实现。
日志收集
我们用的是阿里云的日志服务，直接配置logtail即可完成收集工作，界面操作，非常方便。
指标展示
埋点原始数据
图表统计展示
指标告警
数据都收集上来了，想要关注哪些指标，想要在什么时候告警，就变得很容易了。比如说某分钟内下单频繁失败，这个时候你就可以配置告警失败次数>N 触发告警，当收到告警时，就马上去排查为什么会下单失败了。
关于作者：尹吉欢，简单的技术爱好者，《Spring Cloud微服务-全栈技术与案例解析》, 《Spring Cloud微服务 入门 实战与进阶》作者, 公众号猿天地发起人。
