应用可用性监控建设阶段小结

概述：

在监控体系建设中，我们将监控分了5层：基础设施（含网络设备）、服务器（含VM、容器等）、系统软件、应用可用性、业务监控（如客户体验），每一层都部署了专业的监控软件对每个点进行了监控覆盖，再通过CMDB，以及CMDB的扩展配置（比如应用配置、网络配置、云平台配置等），将每一层涉及的原子节点进行了关联，组成了三维的全链路立体式监控体系。

在这个立体式监控体系中，应用可用性监控主要指应用系统服务运行状况的反映，比如应用停业、部份停业、性能问题、运行缓慢等表现，由于目前面临各种异构的应用系统架构的影响，应用可用性的监控变得愈发复杂。为此，这里从应用可用性的监控目标与适合做应用可用性监控的点介绍一下建设心得：

1、应用可用性监控目标：

对于应用可用性监控，我的理解是分两大类：

1）被动性监控：

      被动性监控是监控系统针对应用运行情况的数据做分析或策略驱动得出应用系统运行状况，包括：应用系统服务状态、应用日志、交易流水状态，以及其它应用层运行情况的监控。这类监控的处理最重的是及时发现，做好事件关联，辅助快速定位问题，恢复业务。

2）主动性监控：

     被动性监控往往只能对应用运行情况的表现判断运行情况，但是对于一些潜在的运行风险并不能很好的反映，这时需要有主动性监控，主动性监控又分为两种：

    （1）应用主动抛出系统运行异常的情况：要实现这个监控目标，需要有DEVOPS的理念，即应用开发团队要为生产系统的运行情况负责，开发团队要主动将运行情况抛出给监控；

     （2）上述的提到的监控都是针对己发生异常的监控，其实监控的目标应该是预测故障。预测故障需要建立一定的运行基线，对当前运行数据与基线数据进行比较后判断是否故障。

2、哪些点适合做应用监控：

    在完善应用监控的建设过程中，我觉得监控项目团队应该用黑盒转变白盒的思路分步建设，去吸收熟悉这个监控点的人去思考分析监控模型，比如，数据库有专门的DBA，数据库对于监控项目组的人是黑盒，但对于DBA是个白盒，如何让数据库监控成为白盒，就需要引入DBA的参与，可以说监控的建设需要IT团队全员参与完善。对于应用可用性监控的点有很多，类似进程状态、端口监听、日志刷新等服务级别的监控这里就不罗列，以下几个点主要是在服务之上的监控点。

1）总线类的节点或应用接口

     总线类的节点或应用API接口是投入产出比最高的应用监控点，以总线类节点为例，由于总线类的节点在企业内部制定了规范的接口标准，通过在这些节点的程序增加抛出异常的埋点，粗的话可以将看到总线节点的运行状况（成功率、耗时、交易量波动、响应率），细的话可以看到流经总线各应用的运行状况，再细的话可以按错误码或指定的错误异常进行响应，发现细到交易级的异常。 

在一些传统企业中由于历史原因，整体的应用部署架构可能没有那么统一，比如可能在核心账务系统前可能有一个前置总线节点，互联网交易渠道有一个互联网交易的前置总线、第三方应用前有一个第三方交易前置总线等等，这些节点都适合做业务监控的埋点。

2）数据库；

      有经验的运维知道，大部份性能问题最早是在数据库层反映出来，如果能将数据库感知的性能问题反映给监控，那也是一个事半功倍的监控点，比如：

• 数据库活动连接数；

• 锁数量

• 平均锁等待时间

• 超长执行语句

• 大事务语句

• 命中率

• …… 

3）中间件：

     在WEB中间件中除了对JVM、线程、会话、节点状态进行监控，对通用中间件的监控埋点也可以有很好的收效。比如：

• JVM堆内存的使用情况； 

• 垃圾回收活动情况；

• 活动连接数情况；

• 数据库连接池情况；

• 应用的会话情况；

• WEB层的页面响应情况；

另外，对中间件的一些标准化组件进行深入埋点，比如数据库连接池，还可以捕获到应用数据库语句到数据库层的粒度到SQL事务级的问题。

4）应用日志；

      对于应用日志，运维人可能会是又爱又恨，爱是因为应用日志有应用运行情况的各种信息，只要你花时间去分析，总会有收获，恨是因为企业里应用日志往往没有标准化，这直接导致应用日志的分析消费成本增高，甚至不可用的地步。但DEVOPS理念讲了多年，开发要为代码稳定负责讲了多年，企业为什么就没有实现应用日志标准化呢？我觉得除了开发配合力度问题外，运维自身也有一定的问题，运维应该为开发提供标准化的应用日志接口，减少开发配合运维工作的成本。在这里不提应用日志标准化的重要性，只提一个对于应用日志消费的一些解决方案：

    相信很多企业级应用都会用到LOG4J等日志模块，为了规范日志格式，可以重构LOG4J函数，这样开发团队无需对现有应用做太大改动，就能输出更标准化的应用日志。

5）应用代码主动报送事件；

     关于应用代码主动报送事件的工作很重要，我们使用数据库、中间件、应用日志等节点的监控埋点，能尽快发现己出现影响业务的问题，对于某个应用出现局部异常的情况则需要应用主动告知监控。实际建设过程中，应用代码主动报送事件方面是最为复杂的，复杂的地方在于：

• 开发团队的配合力度，运维控制力下降；

• 主动报送事件的标准，哪些该抛，哪些不抛的界限；

• 各应用架构、语言、中间件等异构的现状，很难做到大面积覆盖；

      针对这几个难点，我觉得主要从以下几点建设：

• 标准化，什么该抛，什么不该抛一定要有标准

• 分步建设，不放过任何一个故障，对于故障要深究是否可以增加应用级的标准化监控点，再推动应用的优化改进；

• 监控团队要牵头通过数据分析的报表去发现应用监控标准化落实情况，反推开发团队优化，提高控制力；

6）预测监控；

    上面5点提到的都是事后监控，我觉得业务监控的目标应该是预测监控，这一块也是我现在正在考虑去做的事情，思路不是很成熟，但比较简单，大体是：

     对监控采集的运行数据建立一条运行基线，通过对当前监控采集的数据与运行基线做对比，加上当前运行数据与基线比较的策略模型，预测业务运行情况。

     这一块预测监控一方面需要建立模型，同时也会消耗更多的监控系统性能，所以计划先借助监控分布式数据库、应用解耦改造后，再开始实施这方面的建设。未来不排除将这方面的运算放到大数据平台做运维数据分析。