持续坚持原创输出，点击蓝字关注我吧
几个月前，写过一篇关于系统可观测性的文章《可观测性就是对“监控”的包装？》，文中也阐述了可观测性与监控之间的区别。
1.监控是可观测性的先决条件。在监控处理收集数据的同时，可观测性收集、存储、查询和可视化这些数据，使专业人员能够轻松地了解每个系统行为背后的原因。
2.监控为你提供有关系统中的问题或故障的信息，而可观测性让你了解导致故障的原因、发生地点以及发生原因。
3.不受监控的系统是不可观测的。
4.可观测性 发现&解决未知的未知问题。监控 发现已知的问题。
当然，关于监控的文章，在各大论坛上一搜一大把，国内外比较大的互联网公司也都有开发自己的监控系统（可以参考文末的相关文章）。 本文主要介绍支付系统的精细化监控，一方面是工作相关，相对比较熟悉；一方面支付系统对资损0容忍，因此需要借助精细的监控系统以实现对线上异常的第一时间响应。但大部分内容，应该来说对其他系统也是通用的 。
OK，下面就由浅入深慢慢道来。
1.系统监控
先说相对比较简单的系统监控，一般系统监控关注如下指标，当然熟悉性能测试同学也比较熟悉：
- CPU负载
- 内存使用率；
- 磁盘使用率；
- 网络带宽占用
2.JVM监控
JMX提供了关于JVM的大部分核心信息，启动时设置参数，支持远程访问JMX，之后即可通过接入JMX来实时读取JVM的CPU,内存等信息。
JVM可监控指标如下：
- GC（垃圾收集）瞬时和累计详情
- FullGC次数
- YoungGC次数
- FullGC耗时
- YoungGC耗时
- 堆内存详情
- 堆内存总和
- 堆内存年轻代Survivor区字节数
- 堆内存年轻代Eden区字节数
- 已提交内存字节数
- 非堆内存
- 非堆内存提交字节数
- 非堆内存初始字节数
- 非堆内存最大字节数
- 直接缓冲区
- DirectBuffer总大小（字节）
- DirectBuffer使用大小（字节）
- JVM线程数
- 线程总数量
- 死锁线程数量
- 新建线程数量
- 阻塞线程数量
- 可运行线程数量
- 终结线程数量
- 限时等待线程数量
- 等待中线程数量
3.服务监控
服务监控主要指对接口的监控，包括HTTP、RPC等协议开发的服务。服务监控关注如下指标：
- QPS，每秒请求数。对于使用容器的系统，例如Apache Tomcat，可以从Access Log中采集到每个服务的QPS。这个指标还可以细分为 每秒成功请求数、失败请求数、总请求数等。
- 请求响应时间。在服务器端监控每个服务的响应时间。
- 执行异常数。指程序运行过程中发生的未捕获处理的异常，一般是对场景考虑不周导致的异常发生，比如空指针、错误参数、数据访问等的异常。异常在应用日志中一般都会把错误堆栈打印出来。
- 执行失败数。指程序运行过程中捕获的异常数，一般是对特定场景下做的异常报错，比如参数校验失败等。
监控项目 | 监控数据 | 数据源 |
系统监控 | CPU使用率 | zabbix agent默认采集 |
系统监控 | 内存使用率 | zabbix agent默认采集 |
系统监控 | 带宽使用率 | zabbix agent默认采集 |
JVM内存监控 | free, used, heepsize | JMX |
服务状态监控 | 404/505等status数量 | Tomcat访问日志 |
服务状态监控 | 每个接口的访问量 | Tomcat访问日志 |
服务状态监控 | 每个接口发送的字节量 | Tomcat访问日志 |
服务状态监控 | 每个接口的最大响应时间 | Tomcat访问日志 |
服务状态监控 | 每个接口的最平均响应时间 | Tomcat访问日志 |
服务监控 | 错误数 | 应用日志 |
4.数据库监控
数据库是大部分应用的核心和瓶颈，对其监控至关重要。监控可以在数据库服务器上做。以MySQL为例，可以通过监控其bin log来获取执行的sql语句以及执行时间、错误代码等信息。
数据库监控重点关注如下指标:
- 每秒请求数
- 慢查询处理数
- SQL语句执行时间
5.全链路监控
调用链监控更多应用于微服务系统中，追踪一个请求从发起到返回的整条链路，观察在各个相关系统中的调用情况。调用链监控往往是跨系统的监控，需要在请求发起时分配一个可以唯一识别本次调用请求的ID，这个ID会被分发到每个调用的应用服务上。之后会在调用日志中打印出此ID。当所有日志都汇总起来后，就可以从日志中分析本次调用的整个链路。
当然，随着微服务架构大行其道，当今市面上存在很多开源的分布式链路追踪工具，分布式追踪系统用于记录请求范围内的信息，一次远程过程调用的执行过程和耗时，是我们排查系统问题和系统性能瓶颈的利器。常见的分布式追踪工具如Jaeger，Uber推出的一款开源分布式追踪系统，兼容OpenTracing API，用于监视和诊断基于微服务的分布式系统。
6.业务监控
可能很多朋友会问，服务监控难道不就是业务监控吗？其实不然，我认为服务监控是脱离业务的，它更多表征的是服务自身的特性，例如响应时间、延迟、响应结果、异常结果，而这些特性是所有服务共有的，并不是某个服务特有的。而业务监控就不同了，每个业务可能有不同的特性指标。以支付业务为例：
如常见的淘宝购物，完成一笔支付， 可以选择不同的支付渠道，例如卡支付、钱包支付（支付宝、微信等）。而针对支付接口的监控包括如下内容：
- 支付渠道请求数：如果一段时间内渠道请求量大幅度下降，可能是该支付渠道出现问题了。
- 支付渠道请求失败数，即调用渠道失败的数量。
- 支付渠道请求延迟。
- 支付渠道支付失败率。每个支付渠道有一定的失败率，如果给定时间内突然有超过这个失败率的情况出现，则可能是这种支付渠道出现问题了。
而支付业务相关的接口，如下单、退款、签约、解约等，监控如下内容：
- 下单交易金额
- 每笔平均金额
- 支付成功率
- 退款成功率
7.精细化监控
所谓精细化监控，就是对业务的精细化监控，即对第6小节介绍内容的更进一步。精细化监控的目的是提升开发人员的应急效率。
实现精细化监控，除了常规的数据统计手段外，更多依赖测试同学的业务经验了。下面我就YY一些业务场景给大家通俗易懂阐述下，当然这些例子更多的是帮助大家理解而已。
例如，上述介绍的 针对支付业务的监控指标，支付渠道请求失败数，特定时间支付失败有时候是正常的，例如网络延迟、支付超时等，此时仅仅这个请求失败数是不能断定就是系统出现了问题的，我们可以基于时间维度进行数据统计，例如统计一小时内容的失败率，并且设置阈值，触发阈值则通知开发响应应急预。
再例如，我们在支付服务中开发一段处理异常的代码，即触发该异常代码会报xx错误码，而且这个错误码是0容忍的，此时就需要配置精细化监控，监控这个错误码，只要发现有这个错误码就通知开发响应应急预案。
精细化监控是测试右移的一种有效手段，可以帮助测试同学更及时发现线上故障，以降低故障带来的负面影响(资金损失、客诉等)。
