监控应用，应该监控什么？

写在前面

如何构建一个完善的监控体系，是一个老生常谈的话题，从基础设施监控入手，到数据库、中间件，再到业务应用，逐层监控。你能在搜索引擎上找到各个公司的监控架构，无论是传统公司还是互联网公司，大同小异。



针对基础设施的监控，大家的监控方式都很统一，而且很成熟，无非是Agent、SNMP、JMX、中间件状态页之类。然而针对业务应用的监控，却如梦似幻，让人找不到头绪，很多公司分享内部的监控架构，也对这部分言辞不详，甚至有很多公司实际上没有针对业务应用的监控。



保障业务稳定运行是运维人员的最高职责，如果没有有效的方式对业务应用进行监控，出现问题后没有系统化的方法去定位诊断，那就真是太悲剧了。本文结合个人经验，试图为大家呈现一个针对业务应用监控的全景。



定义一下业务和应用

“业务”和“应用”是很模糊的词，另外一个很模糊的词是“服务”，说到这些东西时，大家似乎都知道是什么，却很难保证所有人的理解一致。在本文开始前，首先明确一下概念（至少在本文范围内这些概念是一致的）

• 业务：面向用户的一个整体的系统，以电商为例，整个京东商城是一个业务，或者分细点，生鲜是一个业务，数码产品销售是一个业务...... 这个划分的标准主要是基于公司的商业行为的，一般不会划分太细，没有人会把用户登录这一个小功能作为一个业务。大家提到业务时，关心的一般是用户数、订单数、成交额、商品数之类的指标，不会直接关心其底层的技术架构。

• 应用：技术角度上构成一个或多个业务的模块，严格上应该称为服务（service），但很多人习惯叫应用了，本文也称之为应用。例如用户鉴权应用、库存管理应用、商品照片应用等等。一个应用可以由多个实例组成，通过负载均衡对外提供统一的服务。



应用监控黄金指标

监控应用必须要提到“黄金指标”，其具备很好的指导意义，具体如下：

• 吞吐率：应用的请求速率，一般为每秒请求次数

• 错误率：应用的请求种有多少出现了错误，行为不符合预期

• 响应时间：应用的请求在多长时间处理完成了，时间过长会严重影响用户体验

• 饱和率：当前应用的繁忙程度，主要强调最能影响服务状态的受限制的资源，例如磁盘I/O、内存等资源



有了黄金指标还需要能够对这些指标进行进一步的诊断分析，比如错误率上升是谁导致的，根因是什么，响应时间上升的根因又是什么，提前准备好对应的分析工具和方案，才能够在问题发生时不至于手忙脚乱。



如何获取黄金指标并建立分析体系

1 传统派：日志采集

通过在应用和相关中间件中定义详细的日志输出规则，将请求地址、响应时间、响应状态、关键参数、错误堆栈等输出至日志中，再通过日志采集工具将日志统一采集至日志分析平台。在日志分析平台可以通过检索等方式获取应用的关键指标并配置告警，出现异常问题时则进一步检索原始日志。常见的开源方案是ELK。



这一派的武林高手还通过在日志中添加并传递单次请求的ID实现分布式调用的追踪，武功再高一点的还可以将业务ID和请求ID关联起来，例如用户下单失败，根据订单ID追踪其对应的请求，还原其完整的执行过程，成为定位业务问题的倚天屠龙剑。



该流派的优势是可以将应用日常监控和问题定位分析很好的结合起来，日志内容可以灵活定义，派内核心人员大多数是研发人员。劣势则主要为如下两方面：

• 依赖完善的日志输出规范，需要在应用研发阶段就规划好并进行日志埋点，很多研发能力较弱或采购了大量第三方应用的用户很难采用这种方案。

• 日志数据量较大，搭建并维护统一的日志平台会带来较高的成本，比较笨重。



2 改良派：优化日志采集

部分传统派人员对笨重的传统方案深恶痛绝，下定决心降低日志数据量，他们通过几种方式对传统方案进行改良：

• 日志预处理：不是所有的日志对于问题定位分析都是有价值的，因为很多日志都是应用正常运行过程中产生的日志，如果只是为了获取黄金指标就把所有的日志采集到日志平台上会带来较高的数据传输、存储和处理成本。通过在日志的产生端对日志进行预处理，提前计算好该应用实例的黄金指标而不是等所有的日志都到日志平台后再计算能够大幅度降低上述成本。为了进行问题的定位分析则可以将异常日志或少量采样后的原始日志发送到日志平台，日志量大大降低。

• 应用内建指标：基于前面的思路，如果只是为了获取黄金指标，详尽的原始日志并不是非常重要，那何必还要产生这么多日志呢，可以直接在应用内统计并计算得出该应用的黄金指标，对外暴露一个端口，提供给时序指标监控工具就好了。这种方式也受到神秘的“云原生”宗教推崇。

• 降低日志分析及处理成本：传统派日志分析及处理成本较高除了日志数据量过大外，另一个关键的因素则是为了提供灵活的日志检索而对很多字段建立了索引，而索引是很占用计算资源的。既然通过日志预处理和应用内建指标而不再非常倚重通过日志平台检索日志，那为什么还要建这么多索引呢，这样的思路指导下也诞生了很多新型的日志分析平台，例如loki。



这一派通过各种刻苦努力解决了传统派数据量大、比较笨重的问题，然而其仍然要求用户具备较高的研发能力。



3 黑科技派：APM&NPM

传统派和改良派的核心人员往往是研发人员，这让很多运维人员内心不是滋味，难道自己就只能等这些家伙把东西都准备好吗？如果他们搞不好咋办？为此他们通过很多黑科技也实现了应用黄金指标的监控，这些黑科技是如此的黑，以至于前面提到的应用输出日志、内建指标统统都看不见了。这些黑科技主要是APM和NPM：

• APM：通过javaagent等技术实现不依赖输出日志的应用监控，可以简单理解为其通过程序语言或框架本身的一些能力替用户完成了“日志”的输出和处理，不过它产生的“日志”一般不会输出至文件中，而是直接传送到了其专用的分析平台，具体原理参见https://www.jianshu.com/p/a803571cd570。

• NPM：应用的访问和被访问都是需要通过网络的，通过对网络传输过程中的数据包进行解析可以在不改造应用的前提下获取应用每个请求的处理情况。



APM和NPM的优势都在于不需要用户提前在应用中输出日志或内建指标，对于一些已有的应用也不需要进行改造，深受运维人员的喜爱，虽然应用代码不是他们自己写的，但借助这些黑科技，他们同样能够获得深入洞察应用运行状态及过程的机会，对应用的理解更加深刻，处理起异常问题来也更加得心应手。

黑科技也是有劣势的，APM和NPM并不支持天下所有的应用，有很多语言、技术架构或网络协议并不能很好的支持，同时提供APM和NPM工具的一般都是商业公司，使用这些黑科技需要花费一笔不小的金钱。



4 小富即安派

前三派剑指黄金指标，各自使出了绝活，然而江湖上大多数人并没有这么高的追求，受限于客观环境，他们只能采用一些简单的工具，也维护着应用的稳定运行，他们主要关心应用的存活，深知活着就好的道理。

• 进程存活监控：通过判断应用进程的状态来推测应用状态，如果进程出现问题了，应用也肯定出现问题了

• 端口存活监控：与进程类似，通过判断进程监听的端口状态来推测应用状态

• 接口存活监控：应用对外提供服务是通过很多接口来实现的，可以从中选择一些接口来监控其响应是否正常来判断应用状态，相比进程和端口的方式准确率更高。一些仍存有一点理想的用户会在应用中专门提供一个判断应用状态的接口，准确率进一步提高，殊不知他们已经进入改良派的势力范围。

• 关键指标监控：虽然小富即安，却也有危机意识，通过读取数据库、统计错误日志条数等方式也能够获取一些应用的关键指标，这些指标虽然没有黄金指标那么牛逼闪闪，却也能代表一部分应用的运行状态。



业务监控

前面介绍的主要是应用监控的一些流派，那么业务监控指的又是什么呢？主要包含如下几个方面：

• 关键业务指标：不同于应用黄金指标，这些指标是与业务紧密相关的，比如针对一个电商业务，关键的业务指标可能包含订单数、订单成功率、成交额等，而针对一个社交业务，关键的业务指标则可能是在线用户数、新动态数等。关键业务指标需要和应用指标建立起关联关系，通过关键业务指标监控发现异常时能够进一步的定位到对应的应用异常，实现问题的进一步处理。例如订单数突降，其对应的订单应用的吞吐率、错误率和响应时间是否发生了异常。

• 关键业务追踪：常见于交易类业务，通过一些业务ID追踪其在各个应用上的执行过程，便于定位分析一些异常业务交易。例如支付业务出现了失败，可以根据用户反馈的支付订单ID进行进一步的分析。

• 用户体验监控：应用监控的关注点主要在于业务系统的服务端，然而服务端正常并不代表最终用户看到的是正常的。通过在用户终端（例如浏览器和移动APP）监控用户的操作延迟、错误等能够更加全面的了解业务的实际运行情况。

写在后面：以上为一个初略的整理，实际上由很多方案是介于几种方案之间的，例如APM产品zipkin同样需要用户在应用中埋点。