监控之美——Prometheus 云原生监控

本文摘自于朱政科撰写的《Prometheus 云原生监控：运维与开发实战》，介绍了监控的概念、监控的分类、MDD 理念、Google 四大黄金指标、USE 方法、RED 方法等监控理论。

监控是一门学问，也是一门艺术。

亚马逊副总裁、CTO Werner Voegls 说过：“You build it, you run it, you monitor it.”（你构建了它，你运行它，你就有责任监控它。）爱尔兰第一代开尔文男爵 Lord Kelvin 和现代管理学之父彼得·德鲁克也曾说过：“If you can’t measure it, you can’t improve it.”（如果没有了如指掌，你就无法做出改进。）监控无处不在，对软硬件进行监控，并实现系统的可观察性是监控技术人员的必备技能。

近几年来，随着微服务、容器化、云原生等新架构思想的不断涌入，企业的 IT 架构逐渐从实体的物理服务器，迁移到以虚拟机为主的 IaaS（Infrastructure-as-a-Service）云和以容器云平台为主的 PaaS（Platform-as-a-Service）云上。日新月异的 IT 架构为监控系统带来了越来越多的挑战，也对技术人员提出了越来越高的要求。2019 年阿里“双十一”期间，订单峰值达到 54.4 万笔/秒，创下了新的纪录。“双十一”期间的单日数据处理量也达到 970PB。面对世界级流量洪峰，阿里巴巴实现了 100%核心应用以云原生的方式上云，并交出了一份亮眼的成绩单：

1）“双十一”基础设施 100%上云；

2）“双十一”在线业务容器规模达到 200 万；

3）采用基于神龙架构的弹性裸金属服务器，使计算性价比提升了 20%。

阿里云在上万个 Kubernetes（简称 K8S）集群大规模实践中，保证了全球跨数据中心的可观测性，这正是基于 Prometheus Federation 的全球多级别监控架构实现的。

在正式介绍 Prometheus 之前，本章我们先来了解一些关于监控的基础知识。按照由浅入深的顺序，本章将依次讲解以下内容：监控的概念、监控的黄金指标、监控的手法、基于 Metrics 的 MDD（Metrics-Driven-Development，指标驱动开发）思想、常见的监控技术产品及选型等。最后，补充一些后续章节会涉及的术语和概念。

1　监控：把握应用的脉搏

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

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

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

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

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

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

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

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

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

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

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

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 系统的运维基础采集项，主要包含 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 全景图中，也罗列了一系列的监控产品，如图 1-2 所示。

监控系统中的监控功能可以告诉我们系统的哪些部分正常工作，哪里出现了问题；监控系统具有的可观察性可以帮助我们判断出有问题的地方为何不能工作了。除了监控功能和可观察性外，数据分析对监控系统来说也非常重要。监控系统获取的数据可以使用大数据、漏斗分析、分析模型和算法等进行分析（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 子类中的产品与追踪相关，包括 Jaeger、SkyWalking、Pinpoint、Zipkin、Spring Cloud Sleuth 等。

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

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

2　监控架构分类

近年来，随着以 Kubernetes 为代表的云原生技术的崛起，软件的研发流程已经逐步进化到 IaaS 层、Kubernetes 层、团队组织层。

Kubernetes 是强大的声明式容器编排工具，可以提供计算、存储、网络等功能接口，通过这些接口以插件形式实现相关功能。这种灵活、开放的设计理念使 Kubernetes 非常容易集成外部工具，强化相应的功能。所以 Kubernetes 逐渐发展成中间件和微服务的“底座”，同时也成为企业上云的“底座”。如表 1-1 所示，Kubernetes 和 IaaS 有着天然的联系，Kubernetes 已经可以和诸如 OpenStack、AWS、Google 云等 IaaS 云平台进行集成，在弹性、敏捷、动态方面，它都可以发挥巨大作用。在 IaaS 层可以实现对硬件、网络等的监控；在 Kubernetes 层则可以实现对日志、健康检查、自愈系统、分布式链路等的监控，Kubernetes 层作为中间件和微服务的“底座”，很多产品的监控都可以在这一层完成。

在我的第一本书《HikariCP 数据库连接池实战》的第 10 章中，介绍过 3 种应用于微服务架构的监控体系—Metrics、Tracing 和 Logging，这里补充第四种监控体系—HealthCheck。HealthCheck 用于健康监控（这种监控方式在微服务 Spring Boot 中使用较多），如图 1-3 所示。

一般来说，开源监控系统由集中式日志解决方案（以 ELK 为代表）和时序数据库解决方案构成。时序数据库解决方案以 Graphite、TICK 和 Prometheus 等为代表，其中前两个是推模式，后一个则以拉模式为主，拉模式对整体代码和架构的侵入较小。

当代新的监控三要素为 Metrics、Logging 和 Tracing。

• Metrics 的特点是可聚合（Aggregatable），它是根据时间发生的可以聚合的数据点。通俗地讲，Metrics 是随着时间的推移产生的一些与监控相关的可聚合的重要指标（如与 Counter 计数器、Historgram 等相关的指标）。

• Logging 是一种离散日志（或称事件），分为有结构的日志和无结构的日志两种。

• Tracing 是一种为请求域内的调用链提供的监控理念。

Prometheus 同时覆盖了 Logging 和 Metrics 两个要素。

关于 Metrics、Logging、Tracing 的比较如图 1-4 所示，其中 CapEx 代表搭建的投入成本，OpEx 代表运维成本，Reaction 代表监控手段的响应能力，Investigation 代表查问题的有效程度。一般来说，Metrics 和 HealthCheck 对于监控告警非常有帮助，Metrics、Tracing 和 Logging 对于调试、发现问题非常有帮助。

Prometheus 是基于 Metrics 的监控系统，具有投入成本（CapEx）中等、运维成本（OpEx）低、响应能力（Reaction）高等特点。图 1-4 中查问题的有效程度（Investigation）较低，是相对于 logging 和 Tracing 等模式而言的。一般在业务开发中，通过查日志的方式就能定位到系统存在问题，通过 Tracing 模式可以查到链路上出现问题的环节。但是这并不代表 Metrics 监控的有效程度是最低的，合理的监控埋点、完美的监控大盘配置、超前的监控告警往往能让开发者在业务方发现问题之前就已经发现问题。

微服务的监控反馈环节是非常重要的。姑且不提那些让人眼花缭乱的监控软件，单从宏观上来说，云原生、微服务场景下的监控该如何按类别使用呢？如图 1-5 所示，成熟的分布式软件系统在使用过程中可以分为监控告警、问题排查和稳定性保障这 3 个部分。

进行监控告警时，HealthCheck 是运维团队监测应用系统是否存活、是否健康的最后一道防线，这是必须引起重视的一道防线。HealthCheck 在微服务中通过对一个特定的 HTTP 请求进行轮询实现监控。通过对这个请求进行轮询，不但可以得到微服务的监控状态，还可以得到相关中间件如 MQ、Redis、MySQL、配置中心等的健康状态。当然，开发人员最为关心的监控还是自身定制的 Metrics 监控，所以监控告警的优先级依然是 Metrics 监控最高，HealthCheck 最低。

进行问题排查时，在监控系统不那么先进的年代，研发人员往往是通过查日志解决问题的。但是如果需要查询分布式集群上几十台到几百台机器的日志，不借助一些日志软件，而是使用命令行集中查询，那将是一件非常麻烦的事情。而在当下这个云原生和微服务架构盛行的时代，监控系统百花齐放，往往会基于 Metrics 的监控大盘进行查询从而定位问题。比如 Prometheus 就支持非常强大的 Metrics 查询—PromQL 语句查询。Metrics 查询是基于时间序列的数据库设计得到的，其可以直接定位到过去的任意时间点，可以对系统层、中间件层、应用层、业务层乃至端上的所有监控指标进行查询。如果 Metrics 无法定位问题或者需要更多信息，Tracing 监控手段可以提供协助，帮助定位该问题发生在微服务链路的哪个环节（比如是物流服务、订单服务还是支付服务）。最后，可以再根据日志找到最根本的问题。通过 Metrics→Tracing→Logging 的顺序分析问题，比直接去查日志更高效，很多问题都可以在日志之前的环节直接被定位并解决。

在流量洪峰到来之前，比如“双十一”大促，研发团队往往要进行技术演练以保障系统的稳定性（性能、多机房、高可用），此时会使用 Chaos 混沌工程以建立抵御生产环境中失控条件的能力及信心，还会使用 Tracing 进行全链路压测，尤其是针对复杂业务场景和海量数据冲击，要保障整个业务系统链的可用性和稳定性。

3　MDD 思想：从指标到洞察力

躺在 GitHub 仓库中的代码，即使风格再好、注释再详细、算法再精妙，如果没有运行，则对于业务而言依然是没有任何意义的。运行中的代码才是有价值的。以 Prometheus 为代表的遵从 MDD 理念的产品，并不会做静态代码检查，而是会对执行过的代码、代码执行次数、错误位置、错误数量等信息进行运行时动态监控。下面就对 MDD 理念进行详细介绍。

3.1　MDD 理念综述

MDD（Metrics-Driven Development）主张整个应用开发过程由指标驱动，通过实时指标来驱动快速、精确和细粒度的软件迭代。指标驱动开发的理念，不但可以让程序员实时感知生产状态，及时定位并终结问题，而且可以帮助产品经理和运维人员一起关注相关的业务指标，如图 1-6 所示。

MDD 理念最早是在 2011 年 3 月 12 日 Etsy 公司举办的一次技术交流会“Moving Fast at Scale: a microcon-ference at SXSW”上，由 Etsy 核心平台部负责人 Mike Brittain 提出的。其实技术领域有很多驱动开发的理念，如表 1-2 所示。

MDD 可使所有可以测量的东西都得到量化和优化，进而为整个开发过程带来可见性，帮助相关人员快速、准确地做出决策，并在发生错误时立即发现问题并修复。MDD 可以感知应用的“脉搏”，并不断根据运行时的数据提供改进策略。MDD 的关键原则如下。

• 将指标分配给指标所有者（业务、应用、基础架构等）。

• 创建分层指标并关联趋势。

• 制定决策时使用的指标。

TDD 主张在业务代码之前先编写测试代码，MDD 则主张将上线、监控、调试、故障调查及优化等纳入设计阶段，而不是等到实施后才补充。相对于通过制定各种复杂、严格的研发规定，以及开无数的评审、研讨会议来确保软件的安全发布、稳定运行，MDD 理念的特别之处在于应用程序本身。在 MDD 理念下，采集必要的监控信息，通过持续交付方式进行快速迭代并进行反馈和修正，所有决定都是基于对不断变化的情况的观察做出的。在软件的设计初期就包括 Metrics 设计，设计一套规则来评价系统的稳定性、健康状态，并监控其他考核目标，将这些作为服务本身的 KPI。因此，通过应用 MDD 理念，可将 Dev 与 Ops 之间或多个 Dev 团队之间出现的责任博弈降至最低，甚至使矛盾完全消失，这也有利于团队稳定发展。因此，MDD 可以用于决策支持、预测趋势、测试系统的补充、关联性分析等。

依照 MDD 的理念，在需求阶段就可以考虑设置关键指标监控项，随着应用的上线，通过指标了解系统状态，通过对现状的可视化和具体化，帮助用户对未来进行规划和预测，进而实现业务改善。传统模式中，Dev 和 Ops 是割裂的，而 MDD 是 DevOps 文化的纽带，对于敏捷开发、持续集成、持续交付，以及各个职能岗位提升 DevOps 意识有很大的帮助。

• 对软件研发人员来说，可以实时感知应用各项指标、聚焦应用优化。

• 对运维人员来说，可以实时感知系统各项指标、快速定位问题。

• 对产品经理、商务人士来说，可以实时掌控业务各项指标，通过数据帮助自己做出决策。

在 Prometheus 官网（https://prometheus.io/）的首页展示的宣传语是 From metrics to insight（从指标到洞察力），如图 1-7 所示，由此也可以看出 Prometheus 与 MDD 的关系。

MDD 理念的监控分层主要有 3 种，这 3 种监控分层对应着图 1-1 所示的 5 层轻量监控体系中的部分模块：

• Infrastructure/System Metrics：如服务器状态、网络状态、流量等。

• Service/Application Metrics：如每个 API 耗时、错误次数等，可以分为中间件监控、容器监控（Nginx、Tomcat）等。

• Business Metrics：运营数据或者业务数据，比如单位时间订单数、支付成功率、A/B 测试、报表分析等。

业界有很多 Metrics 实现方案，比如 dropwizard-metrics、prometheus-metrics 等，我个人推荐用开源产品 Micrometer 来实现 Metrics 监控。

3.2　指导实践的 3 大监控方法论

在了解了 MDD 理念以后，大家还需要了解一些基于指标的方法论，这里以小知识点的形式总结如下。

1 . Google 的四大黄金指标

有 4 个来自 Google SRE 手册的黄金指标，这 4 个指标主要针对应用程序或用户部分。

• 延迟（Latency）：服务请求所需耗时，例如 HTTP 请求平均延迟。需要区分成功请求和失败请求，因为失败请求可能会以非常低的延迟返回错误结果。

• 流量（Traffic）：衡量服务容量需求（针对系统而言），例如每秒处理的 HTTP 请求数或者数据库系统的事务数量。

• 错误（Errors）：请求失败的速率，用于衡量错误发生的情况，例如 HTTP 500 错误数等显式失败，返回错误内容或无效内容等隐式失败，以及由策略原因导致的失败（比如强制要求响应时间超过 30ms 的请求为错误）。

• 饱和度（Saturation）：衡量资源的使用情况，例如内存、CPU、I/O、磁盘使用量（即将饱和的部分，比如正在快速填充的磁盘）。

2. Netflix 的 USE 方法

USE 是 Utilization（使用率）、Saturation（饱和度）、Error（错误）的首字母组合，是 Netflix 的内核和性能工程师 Brendan Gregg 提出的，主要用于分析系统性能问题，可以指导用户快速识别资源瓶颈及错误。

• 使用率：关注系统资源的使用情况。这里的资源主要包括但不限于 CPU、内存、网络、磁盘等。100%的使用率通常是系统性能瓶颈的标志。

• 饱和度：例如 CPU 的平均运行排队长度，这里主要是针对资源的饱和度（注意，不同于四大黄金指标）。任何资源在某种程度上的饱和都可能导致系统性能的下降。

• 错误：错误数。例如，网卡在数据包传输过程中检测到以太网络冲突了 14 次。

3. Weave Cloud 的 RED 方法

RED 方法是 Weave Cloud 基于 Google 的 4 个黄金指标再结合 Prometheus 及 Kubernetes 容器实践得出的方法论，特别适用于对云原生应用以及微服务架构应用进行监控和度量。在四大黄金指标的原则下，RED 方法可以有效地帮助用户衡量云原生以及微服务应用下的用户体验问题。RED 方法主要关注以下 3 种关键指标。

• （Request）Rate：每秒接收的请求数。

• （Request）Errors：每秒失败的请求数。

• （Request）Duration：每个请求所花费的时间，用时间间隔表示。

一般来说，上述三大监控理论的最佳实践是：在遵循 Google 四大黄金指标的前提下，对于在线系统，结合 RED 方法和缓存命中率方式进行监测；对于离线系统或者主机监控，以 USE 方法为主进行监测；对于批处理系统，可以采用类似 Pushgateway 的形式进行监控。

*本文经出版社授权发布，更多关于 Prometheus 监控技术，推荐阅读《Prometheus 云原生监控：运维与开发实战》

《Prometheus 云原生监控：运维与开发实战》

推荐语：本书被誉为 Prometheus“百科全书”，可以指导读者快速搭建一个 Prometheus 监控系统并将其应用到实际工作中，囊括私有云、公有云、混合云环境下的大量案例。针对运维人员，分享 Prometheus 对接各种云原生应用并实现事前预警、事中报警、事后提供翔实数据的方法，针对开发人员，给出了 Prometheus 主要组件的源码分析以及部分功能的二次开发实现。从入门知识到高级技巧，全面解读 PromQL，并给出上百个 PromQL 实际案例。以附录的形式给出端口、数据类型、选择器、指标类型、PromQL 内置函数等实际工作中需要时常查阅的内容。