Agile Alliance 服务监控-系统的私人医生-京东云开发者社区

#### 引言 
系统如同人的身体一样，不可能一生都健健康康，当系统出现问题时，工程师们能否快速排查、准确定位并修复问题，则直接影响了一线员工的工作效率。但是问题通常是五花八门、服务器则是成千上万、系统交互更是错综复杂，想快速定位问题并非易事，面对这样的困难，我们强大的工程师团队为我们请来了系统的良医--服务监控。

#### 服务问题分类
服务监控一般通过系统agent埋点和记录并采集日志等形式对系统进行监控，记录并保存了服务历史的运行情况，当问题发生时，我们可以通过服务监控对系统进行问题的追踪与排查工作。系统问题可以分为两类：服务性能问题、业务问题，让我们一起来看看如何对这些问题进行定位吧。

##### 一、服务性能问题
一般症状为：系统响应缓慢、系统操作不流畅、出现卡顿甚至长时间等待后系统提示异常等情况。面对这一病症，我们通常的处理方式是：
- 1）首先根据jtrace（分布式跟踪系统）查看相关请求的调用链路，定位问题发生的具体服务。
- 2）如果服务为其他团队的服务，则优先联系服务负责人；
- 3）如果是应用服务器问题，则通过fireeye（火眼系统）查看服务器本身是否存在异常情况，如cpu飙高、机器内存飙高、负载飙高、磁盘读写飙高、磁盘空间不足、网络流入流出异常、网络延迟等情况；在根据具体情况结合ump（智能监控平台）中的jvm使用情况帮助排查、辅以myops的相关命令工具即可准确定位问题；
- 4）如果为数据库服务器问题，则通过dbs（数据库服务平台）查看近期执行的慢sql，定位问题。

问题不同对应的排查方式也不尽相同，具体排查过程就不在本篇进行赘述。
##### 二、业务问题
一般症状为：业务流转错误或者业务在前台直接报错。面对这一病症，我们通常通过logbook（日志系统）对业务进行跟踪，也可以通过jtrace查看业务在系统间的流转过程帮助排查定位问题。

#### 报警设置 
#####  一、 全方位的报警设置
  学会系统问题排查固然非常重要，但是我们更应该在系统问题发生初期就 **发现问题、预知问题**。这得力于目前监控服务的报警设置，全方位合理的报警设置帮助我们在问题爆发之前定位问题，减少问题对现场操作的影响。全方位的报警，大致如以下几个方面：
- 1）应用服务器监控：cpu监控报警、内存使用率监控报警、负载监控报警、TCP连接数监控报警、磁盘使用率监控报警、磁盘繁忙报警
- 2）数据库服务器监控：在应用服务器的基础上需要增加主从复制延迟监控报警、数据库QPS监控报警、 数据库TPS监控报警、慢sql监控报警
- 3）服务监控：服务存活报警、http响应码监控报警、gc频率监控报警、jvm内存使用率监控报警
- 4）方法监控： 方法性能监控报警、方法可用率监控报警、方法调用次数监控报警、自定义业务报警
- 5）日志监控：关键字监控报警（如：JSFCodecException、MySQLTimeoutException等）

试想一下，当服务器发生频繁GC，随着gc频率升高、内存飙高以及cpu飙高等警报拉响时，我们便可很快发现问题发生的服务器，迅速从np上摘掉发生问题的服务器、dump内存信息、重启服务器，所有操作一气呵成，在现场反应到服务异常之前便完成的问题的定位以及信息采集工作，待服务恢复后继续分析问题产生的原因，岂不美哉，真正做到了在问题爆发前发现并定位问题，减少对一线人员的影响。

##### 二、合理的报警阈值
当我们设置完所有报警后，问题也随之而来，由于报警阈值的不合理设置，导致我们每天接到的报警不计其数，有的同事已经习惯了每天的疯狂报警，对报警视而不见、更有同事则直接屏蔽了咚咚和手机的报警信息，导致真正有问题的报警被大量的没有意义的报警所淹没，失去了服务监控的真正意义。所以设置合理的报警阈值是十分重要的。

**举个🌰，我们经常会收到大量的以下的报警：**
- 1）采集点：xxxxxxxxxxxxxxxx TP99=210ms[偏差10%]，超过1次TP99>=200ms
- 2）内存使用率为：80.02%, 超过阈值：80
- 3）jvm内存使用率为：80.02%, 超过阈值：80

不知道以上的报警会不会引起大家的共鸣呢，对于报警1，我们是不是应该通过ump分析方法合理的tp99范围，调整合理的报警阈值呢？如果超过10ms是我们不能忍受的，为什么不去优化代码呢？对于一次的方法执行超时就报警是否合理呢，无论是发生gc还是其他情况可能都会带来10ms的时间延迟；对于报警2，我们是不是应该具体分析一下服务器本身的内存大小以及jvm所分配的最大内存大小呢，如果服务器只有4g内存，而jvm直接分配了3.5G内存，这种报警必然会一直报出；对于报警3，我们是不是应该首先分析一下我们使用的垃圾回收器，并掌握垃圾回收的触发条件等相关知识后，再去判断这种报警是否有存在的价值呢。

我们不要小看每一个报警的阈值设置，其背后都会有各种理论知识作为支撑，只有服务监控设置的合理了、全面了，我们无需时时刻刻盯着系统看，只需要听见报警声快速解决问题即可。

##### 以下是我经常使用的服务监控系统和功能概述（如有遗漏和不准确的地方，请大家帮忙补充）：
**ump（智能监控平台）：**
- 1）方法性能监控 ：监控方法执行时长，可以设置报警阈值以及报警频率
- 2）可用率监控： 监控方法执行异常情况，可以设置报警阈值以及报警频率
- 3）调用次数监控： 监控方法在一定时间内的执行次数
- 4）jvm监控：监控服务的jvm情况，如gc次数，jvm内存使用情况，可以设置报警阈值以及报警频率
- 5）自定义业务监控：业务埋点，在出现业务异常时进行报警
- 6）服务存活监控：监控服务接口是否存活可用，不可用时进行报警
- 7）ng日志分析 ：监控ng日志，统计ng的调用情况

**fireeye （火眼监控平台）**
- 1）应用服务器监控：cpu监控、内存使用率监控、负载监控、TCP连接数监控、磁盘监控，可以设置报警阈值以及报警频率
- 2）数据库服务器监控：连接数监控、主从复制延迟监控、QPS监控、TPS监控，可以设置报警阈值以及报警频率
- 3）资源使用率、ng状态码报表统计等
- 4）当服务器指标异常时，自动记录当时的top以及jstack等信息，帮助问题排查

**jtrace（分布式跟踪系统)：**
- 1）请求调用链跟踪：帮助排查请求在跨系统中的性能以及业务问题
- 2）判断系统服务是否健康：根据请求时长点的分布，判断服务是否健康，长用来做为系统优化的根据3）由于机房网络问题，也常常用来根据错误请求所在机器的分布，来定位是否为机房网络导致的问题

**logbook （日志监控平台）**
- 1）业务日志跟踪，通过业务埋点日志，分析业务流转情况
- 2）自定义关键字监控：可以设置报警关键字以及报警频率
- 3）ng日志分析

**jex（线上诊断排障平台）**
- 1）监控java服务中出现的异常，并保留当时的堆栈，以及变量值，可以设置自动报警

**myops（京东物流智能运维系统）**
- 1）丰富的命令，帮助我们查看服务器以及jvm的运行情况
- 2）性能分析，帮助我们初步分析系统出现问题的原因

**dbs（数据库服务平台）**
- 1）查看数据库运行情况，如主从延迟、qps等相关信息
- 2）慢sql订阅，帮助排查由于慢sql引起的系统问题

**np（网络平台）**
- 1）域名vip网络质量检测
- 2）历史流量监控
- 3）http响应吗检测

在此，也十分感谢为我们提供这些服务监控平台的开发工程师们，正是由于你们的付出，让我们安然享受这服务监控带给我们的便利。

------------
###### Being Agile 京东物流技术发展部效能提升部
###### 作者： 供应链技术部  张乐祺