1.1　监控：把握应用的脉搏

以“脉搏”这个词语对监控的作用进行概括，取了老中医看病时切脉的意境。我在《HikariCP数据库连接池实战》一书中介绍过“扁鹊三兄弟”的故事，当时用这个故事来阐释数据库连接池监控的重要性。

春秋战国时期，有位神医被尊为“医祖”，他就是扁鹊。一次，魏文王问扁鹊说：“你们家兄弟三人，都精于医术，到底哪一位最好呢？”扁鹊答：“长兄最好，中兄次之，我最差。”魏文王又问：“那么为什么你最出名呢？”扁鹊答：“长兄治病，是治病于病情发作之前，由于一般人不知道他事先能铲除病因，所以他的名气无法传出去；中兄治病，是治病于病情初起时，一般人以为他只能治轻微的小病，所以他的名气只及本乡里；而我是治病于病情严重之时，一般人都看到我在经脉上穿针放血，在皮肤上敷药，所以以为我的医术高明，名气因此响遍全国。”

监控如同切脉诊断，是技术人员先于用户发现问题的最佳手段。完善的监控系统能够引导技术人员快速定位问题并解决。虽然故事中的扁鹊名气最大，但在生产环境中我们要以扁鹊的兄长为榜样，将系统的问题扼杀于萌芽状态。这就需要做好对系统的完善监控。如同故事中的扁鹊那样，事后监控、不完整监控、不正确监控、不准确监控、静态监控、不频繁的监控、缺少自动化或自服务的监控，都是不完善的监控手法。完善的监控系统，是技术人员运筹帷幄的强有力保障。我们应建立完善的监控体系，以期达到如下效果。

1）趋势分析：长期收集并统计监控样本数据，对监控指标进行趋势分析。例如，通过分析磁盘的使用空间增长率，可以预测何时需要对磁盘进行扩容。

2）对照分析：随时掌握系统的不同版本在运行时资源使用情况的差异，或在不同容量的环境下系统并发和负载的区别。

3）告警：当系统即将出现故障或已经出现故障时，监控可以迅速反应并发出告警。这样，管理员就可以提前预防问题发生或快速处理已产生的问题，从而保证业务服务的正常运行。

4）故障分析与定位：故障发生时，技术人员需要对故障进行调查和处理。通过分析监控系统记录的各种历史数据，可以迅速找到问题的根源并解决问题。

5）数据可视化：通过监控系统获取的数据，可以生成可视化仪表盘，使运维人员能够直观地了解系统运行状态、资源使用情况、服务运行状态等。

工欲善其事，必先利其器。综上所述，一个完善的监控系统是IT系统构建之初就该考虑的关键要素。监控系统可以贯穿于移动端、前端、业务服务端、中间件、应用层、操作系统等，渗透到IT系统的各个环节。

如图1-1所示，通常情况下，监控系统分为端监控、业务层监控、应用层监控、中间件监控、系统层监控这5层。

图1-1　五层轻量监控体系图

1）端监控：针对用户在体验上可以感知的对象进行监控，如网站、App、小程序等。有些公司会设置专门的端用户体验团队负责进行端监控。在移动客户端的系统中，端监控的对象主要有H5、小程序、Android系统、iOS系统等，完善的端监控可以反馈地域、渠道、链接等多维度的用户体验信息；用户终端为传统的Web页面时，端监控仍会围绕用户体验采集数据，比如页面打开速度（测速）、页面稳定性（JS）和外部服务调用成功率（API），这3个方面的数据反映了Web页面的健康度。在阿里内部，对于端上数据的采集和监控，除了有SPM^[1]（超级位置模型）、SCM^[2]（超级内容模型）、黄金令箭^[3]（交互采集模型）等理论支撑外，还有一系列相关工具、相关系统与大数据分析提供实践支撑。

2）业务层监控：对于业务层，可按需深度定制监控系统，实现对业务属性的监控告警功能，生成业务数据监控大盘。比如用户访问QPS、DAU日活、转化率、业务接口（如登录数、注册数、订单量、支付量、搜索量）等都是常见的监控对象。

3）应用层监控：主要是对分布式应用和调用链应用的性能进行管理和监控，如对Spring Boot、JVM信息、服务链路、Dubbo等应用在进行诸如RPC调用、Trace链路追踪动作时产生的数据进行监控。

4）中间件监控：监控的主要对象是框架自身的埋点、延迟、错误率等。这里的中间件包括但不限于消息中间件（RabbitMQ、Kafka、RocketMQ等）、数据库中间件（MySQL、Oracle、PostgreSQL、TIDB、PolarDB等）、数据库连接池中间件（HikariCP、Druid、BoneCP等）、缓存中间件（Redis、Memcached等）和Web服务中间件（Tomcat、Jetty等）。

5）系统层监控：如何对系统层进行监控，是运维工程师最关心的问题。小米通过Open-Falcon提炼出了Linux系统的运维基础采集项^[4]，主要包含CPU、Load、内存、磁盘I/O、网络相关参数、内核参数、ss统计输出、端口、核心服务的进程存活情况、关键业务进程资源消耗、NTP offset采集、DNS解析采集等指标。这些都可以作为对系统层监控的关键指标。另外，网络监控也是系统监控中很重要的部分，对交换机、路由器、防火墙、VPN进行的监控都属于网络监控的范畴，内网和外网的丢包率、网络延迟等也都是很重要的监控指标。

市面上的监控系统可以说是五花八门，Apache的SkyWalking、百度的DP、美团的CAT、蚂蚁金服的九色鹿、宜信的UAVstack、滴滴的Omega、360和头条的Sentry、腾讯的badjs、阿里云的arms，以及已经商业化的Fundbug、听云和神策等，都是很知名的监控系统。每种监控系统都有各自的价值，通常来说，Zabbix是针对系统层的监控系统，ELK（Elasticsearch+Logstash+Kibana）主要是做日志监控的，而Prometheus和Grafana可以实现对端、业务层、应用层、中间件、系统层进行监控，因此Prometheus是打造一站式通用监控架构的最佳方案之一。

在CNCF全景图^[5]中，也罗列了一系列的监控产品，如图1-2所示。

图1-2　CNCF监控全景图

监控系统中的监控功能可以告诉我们系统的哪些部分正常工作，哪里出现了问题；监控系统具有的可观察性可以帮助我们判断出有问题的地方为何不能工作了。除了监控功能和可观察性外，数据分析对监控系统来说也非常重要。监控系统获取的数据可以使用大数据、漏斗分析、分析模型和算法等进行分析（Analysis）。

监控功能和可观察性相辅相成，可观察性已经作为一个新的理念进入人们的视野，如图1-2所示，云原生计算基金会在其Landscape中将可观察性和数据分析单独列为一个分类——Observability and Analysis，这个分类主要包括Monitoring、Logging、Tracing、Chaos Engineering这4个子类。

·Monitoring子类中的产品与监控相关，包括Prometheus、Grafana、Zabbix、Nagios等常见的监控软件，以及Prometheus的伴侣Thanos。

·Logging子类中的产品与日志相关，比如Elastic、logstash、fluentd、Loki等开源软件。

·Tracing^[6]子类中的产品与追踪相关，包括Jaeger、SkyWalking、Pinpoint、Zipkin、Spring Cloud Sleuth等。

·Chaos Engineering是一个新兴的领域。随着云原生系统的演进，系统的稳定性受到很大的挑战，混沌工程通过反脆弱思想，在系统中模拟常见的故障场景，以期提前发现问题。Chaos Engineering可以帮助分布式系统提升可恢复性和容错性。

监控是为技术人员和业务人员提供服务的。一般来说，在技术团队，往往会由专职的运维人员负责管理和维护监控系统（在某些公司中，这样的运维团队可能会被称为效能组、DevOps团队或SRE团队），目的是通过监控系统了解技术应用或运行的环境状况，并检测、洞察、诊断、解决因环境引发的故障或潜在风险。除了运维部门外，中间件团队、业务团队中的技术人员同样需要了解监控。

[1] SPM（Super Position Model）全称超级位置模型，是Web端Aplus日志体系和App端UserTrack日志体系共同使用的重要规范。SPM的作用类似于IP地址，可以直接定位前端控件区块。阿里的SPM位置编码由A.B.C.D四段构成，其中A代表站点/业务，B代表页面，C代表页面区块，D代表区块内的点位。

[2] SCM（Super Content Model）全称超级内容模型，是一种与业务内容一起下发的埋点数据，用来唯一标识一块内容。在客户端埋点时，将SCM编码作为埋点的参数上传给UT服务器，SCM编码也采用含义与SPM相同的A.B.C.D格式。

[3] 黄金令箭，即用户在页面上进行交互行为触发的一个异步请求，用户按照约定的格式向日志服务器发送请求，展现、点击、等待、报错等都可以作为交互行为。规则为/goldenkey_xxx，其中x为一串数字，用于标识某个具体的交互事件。

[4] 小米开源产品Open-Falcon文档：http://book.open-falcon.org/zh/faq/linux-metrics.html。

[5] CNCF即云原生计算基金会，2015年由谷歌牵头成立，基金会成员目前已有100多家企业与机构，包括亚马逊、微软、思科等巨头。其公布的Cloud Native Landscape，给出了云原生生态的参考体系，参考地址为https://github.com/cncf/landscape。

[6] 云栖社区：如果将分布式系统比作高速公路网，每个前端的请求就相当于在高速公路上行驶的车辆，而处理请求的应用就是高速公路上的收费站，收费站会将车辆通行信息记录成日志，日志中包括时间、车牌、站点、公路、价格等。如果将所有收费站上的日志整合在一起，便可以通过唯一的车牌号确定该车的完整通行记录。而分布式调用系统会对每一次请求进行跟踪，进而明确每个请求所经过的应用以及所消耗的时间等。