前言
在系统上线之后，或多或少总是会存在问题，有机器性能方面的问题，例如CPU Load过高，内存使用率高，RT高，线程池满，FullGC之类，也有业务逻辑的问题，例如支付系统中金额计算错误，状态校验错误等。为了尽量减少线上的影响（对用户造成困扰，甚至导致资金损失等），对系统的稳定性监控建设还是很有必要的。
从方法论的角度来看，很多事情都可以归纳为信息收集能力，信息的处理能力。稳定性也类似，需要多维的收集信息，然后根据信息发现系统的运行状态。
数据收集
不过方法论如果抽象层次过高，就变得不易落地的，因此还需要结合具体的场景细化，目标是信息维度足够详细，可以有效的辅助问题的分析。结合稳定性场景的话，分为系统与业务两部分数据。系统方面数据比较通用，通常包括机器的CPU情况（CPU使用率，LOAD等情况），内存使用率（JVM内存情况，GC的情况），磁盘使用率，网络的流量情况，以及分布式中一些中间件的情况，例如服务的RT，线程池使用情况，缓存的RT，命中率，消息的堆积情况，任务调动的执行情况等等，以及数据库的执行情况，例如慢sql等等。如果存在不同的机房还需要把机房情况也列出来，例如安全生产环境，正式环境，不同的机房，不同的单元等，这样可以有效定位到影响面。业务数据主要是需要根据具体业务进行分析，梳理出业务关注的指标，不过通用的一般有入口情况（可以分不同的场景，例如PC端，无线端，小程序端等，总量，成功率），依赖情况（依赖服务的成功率， RT等，总量），系统的错误码情况（统一错误码），同样也需要分不同的机房情况。其他具体业务指标就需要结合业务具体分析了，例如支付系统中，每个支付渠道的提交成功率，支付成功率，耗时等。对于业务指标可以根据线上真实出现过的问题或者自己假想出现一类问题，自己需要哪些信息来慢慢完善。 对于单一的应用系统通常可以比较有效的进行监控与巡检，如果是全链路的系统，就需要对链路上的系统分别建设，不过业务上的监控一般可以跨越多系统。
数据处理
数据收集好之后，另外需要了解数据背后的意义，这里就是基础知识以及经验的积累。例如当发现系统提供的服务RT上升时，应该如何排查。当支付宝渠道的支付成功数下降应该如何排查。这些也都可以通过问题处理的经验梳理处理。
服务RT上升
1. 排查依赖的系统RT是否上升，如何下游系统都是自己域内，那就以此排查，如果不是域内，就需要联系对应的owner进行排查
2. 如果依赖的服务RT没有上升，看是否请求量是否明显上涨，导致机器负载过高
3. 是否应用机器是否刚刚启动，由于jvm对代码进行编译导致时间过长；
4. 查看CPU使用率，Load，内存使用率，GC的次数，GC耗时，线程数大小，JVM堆内存使用情况
5. 如果是虚拟机，还需要查看宿主机的情况
支付成功数下跌
1. 入口是否有下跌
2. 各渠道成功数是否下跌
3. 对应的渠道收银台与支付的报错
4. 对应的成功回调，从外层到内层依次排查
其他
监控一方面可以提升问题排查的速度，也可以对于问题进行告警，避免问题的放大。
