浅谈系统监控指标与平台-京东云开发者社区

### 1 背景与意义
现如今系统内部应用程序的环境高度分散，并且不断变化和扩展。事务在多个应用间移动，调用可能会扩展到几个线程中。代码和网络组成的生态系统中，任何部分出现问题时，软件、硬件都可能是罪魁祸首。

###### 为什么要有监控

1. 以前端性能为例，我们无法掌握用户对系统的实际体验情况，只能处于被动接受用户投诉的模式。
1. 以日志为例，随着前后端分离、分布式部署、跨应用等复杂的架构设计，已经分散到数十个位置中，光是去每个文件中检索有效信息，已经是十分繁重的工作。
1. 系统内部某个性能问题，有可能在整体反映并不明显，或是被其他信息干扰，进而问题被掩盖。

覆盖全面的监控系统，能够让我们在任何时刻都能知道系统的整体性能和运行情况，做到主动发现并解决问题；并且通过监测数据进行联动分析，找出问题的瓶颈点或未来增长点，是提供系统成长重要的数据决策支撑。

在不同的行业、公司、业务、岗位，对监控的理解不同，但我们需要注意，监控是要站在公司的业务角度去考虑，而不是针对某个监控技术的使用。

###### 监控的目标是什么

1. 对系统不间断实时监控
1. 实时反馈系统当前状态（反馈信息能识别出正常、异常或故障）
1. 保证服务可靠性和安全性
1. 保证业务持续稳定运行

###### 监控核心是什么

监控只是方法，其核心是作为问题的发现与定位依据，解决故障是应该去做的，从根本上治理问题才是终点。

- **问题的发现**，需要监控提供实时反馈和故障告警，通过主动或被动方式，接收到故障信息。
- **问题的定位**，需要监控提供全面的监控对象，也就是监控指标，因为首先反馈出来的现象只是痕迹，要追踪痕迹才能定位问题的本质，全面的监控指标能最大限度的为我们提供参考数据。

### 2 技术生态

京东物流内部的监控系统，目前已经涵盖服务器、应用、数据库、中间件等各个关键指标，相关监控平台也在持续演进当中。

以逆向供应链系统为例，采用了包括火眼、UMP、pfinder、logbook、x.devops、myops、origin等等在内的监控系统，作为日常监控、故障追溯的手段。不同平台定位角度不同，提供的监控指标也有差异。

#### 2.1 火眼监控平台

火眼提供的是应用服务器指标的实时数据、历史数据追溯、告警功能，是应用健康情况的核心监控平台。

在逆向供应链中，比较关心的是火眼提供的CPU、内存、网络等指标数据，作为应用服务器健康情况的评估标准，另外通过火眼的告警功能，及时追踪线上问题。

![](//img1.jcloudcs.com/developer.jdcloud.com/33c1d3ef-c91f-4e6f-81fd-c56d8496dfc620220126143851.png)

##### 2.1.1 火眼平台功能

###### 功能

1）提供资源监控：操作系统指标、网络指标、文件系统指标、jvm指标。

- 系统指标，比如CPU使用率、CPU负载、内存使用率、SWAP使用率；
- 网络指标，比如网络流入量、网络流出量、TCP连接数、TCP重传数；
- 磁盘指标，比如磁盘使用量、磁盘IO繁忙

2）数据库监控

- 数据库容器的cpu利用率、内存指标、5分钟负载、网络指标、文件系统指标
- 数据库指标，比如运行连接数、COMDML.SELECT、QPS、TPS、连接数、主从延迟、IO中断等

3）告警：系统告警、业务告警，可通过邮件、咚咚、短信方式通知用户。

4）报表管理：应用实时利用率，包括cpu、load和磁盘IO，支持按部门维度汇总、图表展示。

火眼的部署架构大致如下，组件构成主要包含：agent+logstash采集、上报数据，mq削峰、传输数据，jimdb+mysql+es存储、查询数据。

![](//img1.jcloudcs.com/developer.jdcloud.com/bf12874b-d58a-4edb-9ded-62540e5316de20220126144013.png)

火眼定位于服务器/容器的监控平台，外部类似平台有Zabbix、Nagios、Open-falcon等，都能做到以上指标的采集、展示与告警功能。

##### 2.1.2 外部平台

###### Zabbix

Zabbix 是一个企业级分布式开源监控解决方案。能够监控众多网络参数和服务器的健康度、完整性。Zabbix 使用灵活的告警机制，允许用户为几乎任何事件配置基于邮件的告警。基于 Web 的前端页面确保您可以在任何地方访问您监控的网络状态和服务器健康状况。

Zabbix的数据采集，需要在server端进行配置，由server通知agentd进行采集。Zabbix提供丰富的监控指标（以键值形式控制）及模板，快速配置监控面板。

![](//img1.jcloudcs.com/developer.jdcloud.com/d56db767-52f1-4b37-a0d9-a39d3ccd3be320220126144038.png)

Zabbix组件包括server、数据库、web界面、proxy、agentd，通过agent方式采集监控数据，server与proxy用于收集数据，存储到数据库，以web界面展示监控信息。
架构模式有2中可选方式：

1. server-agent模式，是最简单的架构，常用于监控主机比较少的情况。
1. server-proxy-agent模式，用于主机较多场景，使用proxy进行分布式监控，有效的减轻server端压力。

![](//img1.jcloudcs.com/developer.jdcloud.com/7aaf6d1f-82ad-43bd-941e-977a4525b6ec20220126144106.png)

###### Nagios

Nagios是一款开源的免费IT基础设施监视工具，能有效监控Windows、Linux和Unix的状态，交换机路由器等网络设备，打印机等。在系统或服务状态异常时发出邮件或短信报警第一时间通知网站运维人员，在状态恢复后发出正常的邮件或短信通知。
Nagios核心功能是监控报警，告警能力很不错，但是图形展示效果很差。同时nagios更加灵活，很多功能都要通过插件化来实现。

![](//img1.jcloudcs.com/developer.jdcloud.com/041dab85-801d-4b35-b673-1d353d438dc920220126144131.png)

###### Open-falcon

open-falcon是小米运维部门开源出来的互联网企业级监控系统，以替代zabbix为初衷、解决zabbix复杂部署、数据存储性能瓶颈为目标，而实现的分布式监控系统。Open-Falcon 整体可以分为两部分，即绘图组件、告警组件。

绘图组件：负责数据的采集、收集、存储、归档、采样、查询、展示（Dashboard/Screen）等功能，可以单独工作，作为time-series data的一种存储展示方案。

告警组件：负责告警策略配置（portal）、告警判定（judge）、告警处理（alarm/sender）、用户组管理（uic）等，可以单独工作。

open-falcon的数据采集是由agent执行采集脚本来实现的，只需要按照其格式要求进行上报即可。

![](//img1.jcloudcs.com/developer.jdcloud.com/7663ac3f-3f5f-44dc-a48f-7ee6cd33c5f720220126144201.png)

open-falcon架构图

![](//img1.jcloudcs.com/developer.jdcloud.com/c50d5200-8183-4664-97ff-06d3c318712d20220126144219.png)

##### 2.1.3 平台对比

![](//img1.jcloudcs.com/developer.jdcloud.com/5f05dfa2-e539-4dbd-9c01-5b49b81f1a4c20220126144237.png)

#### 2.2 UMP智能监控平台

UMP的定位是应用性能监控，采集的是应用内部指标，比如方法性能、jvm指标、系统存活情况，是需要以代码侵入方式才能采集到的数据。比如，通过对应用的关键方法进行埋点，在应用运行过程中自行上报方式，收集关键方法的性能（tp99、Max、avg）、调用次数、可用率等数据。

在逆向供应链中，以性能指标作为应用压力情况的参考数据。UMP提供的系统存活告警，是比较关键的告警信息之一，jvm指标则反映应用的运行情况，在排查性能问题、应用宕机等情况时，作为比较重要的参考数据。

![](//img1.jcloudcs.com/developer.jdcloud.com/7f16eac1-4c54-49d5-aced-7eda0e07073420220126144302.png)

##### 2.2.1 UMP平台功能

UMP作为京东集团的统一监控与告警的服务平台，通过整合应用监控、调用链跟踪、中间件监控、服务器监控以及日志检索与分析能力，提供以应用为核心的多维化、通用化、微服务化，智能化的一站式监控与故障管理系统。

核心优势

秒级监控： 全新的秒级监控，可查看秒级粒度的方法监控数据，机器维度数据
多方位监控：可监控应用性能，包含方法，url，端口，系统存活，服务器性能，数据库连接数监控等
告警的服务：从告警配置，告警记录统计，告警处理，最后到告警分析，形成整个闭环，帮助用户快速进行故障定位

![](//img1.jcloudcs.com/developer.jdcloud.com/06a1e9c6-906a-49a8-8ad8-0e9ee11cc5f220220126144412.png)

2.2.2 外部平台
###### CAT

CAT 是基于 Java 开发的开源实时应用监控平台，提供了全面的实时监控告警的服务。原型和理念来源于eBay的CAL系统。

其作为服务端项目基础组件，提供了 Java, C/C++, Node.js, Python, Go 等多语言客户端，可在基础架构中间件框架（MVC框架，RPC框架，数据库框架，缓存框架等，消息队列，配置系统等）深度集成，为业务系统提供丰富的性能指标、健康状况、实时告警等。

CAT 很大的优势是它是一个实时系统，CAT 大部分系统是分钟级统计，但是从数据生成到服务端处理结束是秒级别，秒级定义是48分钟40秒，基本上看到48分钟38秒数据，整体报表的统计粒度是分钟级；第二个优势，监控数据是全量统计，客户端预计算；链路数据是采样计算。

CAT核心优势：

实时处理：信息的价值会随时间锐减，尤其是事故处理过程中
全量数据：全量采集指标数据，便于深度分析故障案例
故障容忍：故障不影响业务正常运转、对业务透明
可扩展：支持分布式、跨 IDC 部署，横向扩展的监控系统

![](//img1.jcloudcs.com/developer.jdcloud.com/8c03b18f-d988-4c35-aed3-e23ef0c1d01920220126144456.png)

##### 2.2.3 平台对比

对比CAT与UMP

![](//img1.jcloudcs.com/developer.jdcloud.com/8468b5d3-ac47-4025-8bc1-a52272b4239020220126144621.png)

#### 2.3 Pfinder全链路监控平台

由于现在的系统架构逐渐复杂，一个请求往往涉及到多个应用，有可能是由不同的团队开发、可能使用不同的编程语言来实现、有可能布在了几千台服务器，横跨多个不同的数据中心。因此需要一种帮助理解系统行为、分析性能问题的工具，以便在发生故障时，能够快速定位和解决问题。而全链路监控就是为了实现此目的产生的。
Pfinder的定位就是全链路监控，也就是提供完整调用链的拓扑情况、调用链日志、各节点性能等数据的平台。

逆向供应链系统，包含集约、拆包、wms、二手等多个应用，与物流、零售多种系统间存在各种依赖关系，数据如何在这些系统中流转的，就依赖于pfinder中拓扑关系、调用链跟踪等功能来分析。尤其是调用链跟踪，在分析接口性能瓶颈方面非常高效，

![](//img1.jcloudcs.com/developer.jdcloud.com/695e1224-a7dc-438f-aeeb-0b330c8cad5120220126144647.png)

##### 2.3.1 Pfinder监控平台功能

###### Pfinder

京东内部全链路监控平台，Pfinder = problem finder + performance finder。其核心在于：调用链+性能分析，每一次请求会产生全局唯一的ID(trace id)，将不同应用、不同维度的孤立数据进行有效整合，形成更有价值的信息；

![](//img1.jcloudcs.com/developer.jdcloud.com/cc497dee-bf0d-440a-974b-189e4261001520220126144717.png)

系统架构图

![](//img1.jcloudcs.com/developer.jdcloud.com/4b9acdd4-5c38-415b-af2c-cdb5fb9f38a720220126144908.png)

##### 2.3.2 外部平台

###### Pinpoint

Pinpoint专注于链路和性能监控，韩国研发团队开源，埋点无侵入，UI功能较强，但毕竟是小团队，不知道会不会一直维护着，目前版本仍在更新中。

![](//img1.jcloudcs.com/developer.jdcloud.com/d92bb85c-fa53-4c3e-83db-dd6efb62cac920220126144934.png)

###### Skywalking

Skywalking专注于链路和性能监控，国产开源，埋点无侵入，UI功能较强。能够加入Apache孵化器，设计思想及代码得到一定认可，后期应该也会有更多的发展空间及研发人员投入。目前使用厂商最多，版本更新较快。

![](//img1.jcloudcs.com/developer.jdcloud.com/4b28f3bb-bfd8-41dc-97fd-66a2296c09c620220126144955.png)

###### 2.3.3 平台对比

对比Pinpoint、Skywalking和Pfinder

![](//img1.jcloudcs.com/developer.jdcloud.com/76a88e73-1e26-4d3c-b572-653d29324cd720220126145017.png)

#### 2.4 Logbook日志平台

分析日志数据，是排查问题最基本的手段，而应用的集群化、容器化部署等原因，直接登录服务器来查看日志，是比较麻烦的操作，通过采集、集中汇总方式，再加上高效的检索功能，在解决日常问题时，会十分友好。

Logbook是一套日志采集、存储、展示的平台，关注的是应用服务器上的文本日志。

##### 2.4.1 Logbook平台功能

###### Logbook

物流内部日志采集、展示平台，通过配置主机路径、接收器等，采集目标服务器上的文件，在logbook平台进行展示，提供检索、实时输出功能，查询以文本检索为主，不提供高阶查询。

架构采用agent+filebeat+JMQ+ES等实现。按行采集日志，通过filebeat简单配置，支持完整采集异常堆栈信息。

![](//img1.jcloudcs.com/developer.jdcloud.com/65156600-a398-422a-b6e0-35926f8808c120220126145244.png)

Logbook的日志采集

现场日志与实时日志：logbook会根据日志路径，发送给agent，agent拿到路径后通过8790端口去监控某个日志，并返回日志中的信息。

历史日志：在logbook订阅历史日志后，应用服务器agent会根据配置的文件路径，通过filebeat将日志数据发送到jmq的topic中，server端将日志写入ES中，提供用户查询。

##### 2.4.2 外部平台

###### ELK/Grafana

ELK包含logstash、elasticsearch和kibana，是一套集采集、传输、存储与展示的解决方案。

logstash作为agent负责采集数据并传输，elasticsearch负责存储及基本检索，而kibana负责可视化的展示，并且每个组件均可与其他主流中间件配合使用，elastic官方提供收费的告警组件。

采集日志过程，会按行收集，对于jvm的堆栈异常信息，需要通过grok或beat插件才能完整收集；采集后的数据，最好提供JSON格式，存储到ES后会方便查询。

![](//img1.jcloudcs.com/developer.jdcloud.com/7672ec92-85e7-458a-a48f-3214c979cd2820220126145326.png)

##### 2.4.3 平台对比

对比ELK与logbook，两者架构思路差不多，只是组合方式不同。

![](//img1.jcloudcs.com/developer.jdcloud.com/38e47782-9438-45dd-a52f-0ff1ef3b2c4020220126145349.png)

#### 2.5 其他

###### x.devops

京东云产品管理平台，提供云产品实例的管理与监控，包括RDS、redis、ES、TiDB、Clickhouse。

例如针对redis实例，提供CPU、内存、网络、请求与响应的监控数据。

![](//img1.jcloudcs.com/developer.jdcloud.com/b909caee-c8a6-486a-9a83-23613f9b8df120220126145720.png)

###### myOps

自助形式的运维平台，提供简单服务器命令来检查应用状态，操作服务器文件，执行数据库命令、检查慢SQL等。

其中提供的glances面板，能实时监控应用服务器的各种硬件指标。jstat、jmap、jstack等命令来分析jvm问题，无需登录服务器，即可执行各种命令。

![](//img1.jcloudcs.com/developer.jdcloud.com/97e9ed9b-8349-4b34-86e2-f1a726a6df0120220126150145.png)

###### Origin

目前京东正在对内部各个监控平台进行汇总，Origin统一的入口平台，提供中间件、存储服务、应用的监控面板。集成平台包括UMP、pfinder、DMC、Logbook，以JSF、JMQ、JIMDB、JIMKV等。

![](//img1.jcloudcs.com/developer.jdcloud.com/461e30c1-8e28-42ee-9441-0886e18b850d20220126150212.png)

### 3 监控指标
#### 3.1 服务器监控指标
由于京东物流内部服务器基本容器化，很多硬件指标都是共享的，因此反映健康情况的监控指标较少。

容器类监控指标，总结如下。

![](//img1.jcloudcs.com/developer.jdcloud.com/d11d1141-faed-4348-a3d4-2cf32934155d20220126150233.png)

以下是从硬件角度，总结的可监控指标。

![](//img1.jcloudcs.com/developer.jdcloud.com/ed0381df-6c52-440a-8531-f70360f8e07920220126150249.png)

硬件监控，这部分比较偏向硬件运维，从研发角度，目前在物流没有或者无权限查看监控；外部平台上有zabbix、MegaCli、IPMI工具、Nagios等，可以获取这部分数据。

服务器/容器监控指标与平台对比（火眼采集的数据是在容器内部）：

![](//img1.jcloudcs.com/developer.jdcloud.com/c11865ed-fbdb-4323-8449-1c367bb4f15a20220126150304.png)

#### 3.2 中间件监控指标

![](//img1.jcloudcs.com/developer.jdcloud.com/c7cc0b01-4080-4d04-b4a8-bf91204ac0c620220126150323.png)

监控指标平台对比：

![](//img1.jcloudcs.com/developer.jdcloud.com/c752cf5a-0291-412a-bec9-ce3339d67e9520220126150339.png)

#### 3.3 应用监控指标

![](//img1.jcloudcs.com/developer.jdcloud.com/4d730b30-c4fd-45f8-b489-d0af2e16266020220126150400.png)

应用监控指标与平台对比：

![](//img1.jcloudcs.com/developer.jdcloud.com/c1a0a2d9-d44b-44bb-889c-8363acc3fd5120220126150414.png)

#### 3.4 业务监控指标

如订单增长量、用户注册量、活跃用户、活动引入量、引入利润、打包出库量、退货商品数量及品类等。

以搬仓为例，监控搬仓方案的完成情况，统计切换数据的规模等。

![](//img1.jcloudcs.com/developer.jdcloud.com/3ffbcf86-a986-45f7-8506-b836bae6b78120220126150438.png)

4 总结

目前物流内部的主要监控平台，提供的是较为标准化的监控指标，从拓展性上来看，各个平台的团队肯定是有能力支持的，但用户存在多样性，无法逐个满足。

监控的价值在于对系统性能、瓶颈、业务状态的掌握，以及故障追溯的能力，监控指标有许多，但不一定每种都需要，每个应用都有各自特点，在应用发展的各个阶段，关注的指标也会有所不同。

故障排查也一样，不同问题反映出的数据指标有差异，指标越多，可供筛选、定位的信息越多，但当一套系统功能趋于平稳或运维人员对系统足够熟悉，依赖经验总结出的关键指标也就更加精确，相应的也能减少不必要数据的采集。一套好的平台应该是能够随着应用的发展而演进。

------------

###### 自猿其说Tech-京东物流技术发展部
###### 作者：耿宏宇