监控之美——Prometheus云原生监控 Posted 2021-04-03 中生代技术
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了监控之美——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%核心应用以云原生的方式上云，并交出了一份亮眼的成绩单：
3）采用基于神龙架构的弹性裸金属服务器，使计算性价比提升了20%。
阿里云在上万个Kubernetes（简称K8S）集群大规模实践中，保证了全球跨数据中心的可观测性，这正是基于Prometheus Federation的全球多级别监控架构实现的。
在正式介绍Prometheus之前，本章我们先来了解一些关于监控的基础知识。按照由浅入深的顺序，本章将依次讲解以下内容：监控的概念、监控的黄金指标、监控的手法、基于Metrics的MDD（Metrics-Driven-Development，指标驱动开发）思想、常见的监控技术产品及选型等。最后，补充一些后续章节会涉及的术语和概念。
以“脉搏”这个词语对监控的作用进行概括，取了老中医看病时切脉的意境。在《HikariCP数据库连接池实战》一书中介绍过“扁鹊三兄弟”的故事，当时用这个故事来阐释数据库连接池监控的重要性。
春秋战国时期，有位神医被尊为“医祖”，他就是扁鹊。一次，魏文王问扁鹊说：“你们家兄弟三人，都精于医术，到底哪一位最好呢？”扁鹊答：“长兄最好，中兄次之，我最差。”魏文王又问：“那么为什么你最出名呢？”扁鹊答：“长兄治病，是治病于病情发作之前，由于一般人不知道他事先能铲除病因，所以他的名气无法传出去；中兄治病，是治病于病情初起时，一般人以为他只能治轻微的小病，所以他的名气只及本乡里；而我是治病于病情严重之时，一般人都看到我在经脉上穿针放血，在皮肤上敷药，所以以为我的医术高明，名气因此响遍全国。”
监控如同切脉诊断，是技术人员先于用户发现问题的最佳手段。完善的监控系统能够引导技术人员快速定位问题并解决。虽然故事中的扁鹊名气最大，但在生产环境中我们要以扁鹊的兄长为榜样，将系统的问题扼杀于萌芽状态。这就需要做好对系统的完善监控。如同故事中的扁鹊那样，事后监控、不完整监控、不正确监控、不准确监控、静态监控、不频繁的监控、缺少自动化或自服务的监控，都是不完善的监控手法。完善的监控系统，是技术人员运筹帷幄的强有力保障。我们应建立完善的监控体系，以期达到如下效果。
趋势分析：长期收集并统计监控样本数据，对监控指标进行趋势分析。例如，通过分析磁盘的使用空间增长率，可以预测何时需要对磁盘进行扩容。
对照分析：随时掌握系统的不同版本在运行时资源使用情况的差异，或在不同容量的环境下系统并发和负载的区别。
告警：当系统即将出现故障或已经出现故障时，监控可以迅速反应并发出告警。这样，管理员就可以提前预防问题发生或快速处理已产生的问题，从而保证业务服务的正常运行。
故障分析与定位：故障发生时，技术人员需要对故障进行调查和处理。通过分析监控系统记录的各种历史数据，可以迅速找到问题的根源并解决问题。
数据可视化：通过监控系统获取的数据，可以生成可视化仪表盘，使运维人员能够直观地了解系统运行状态、资源使用情况、服务运行状态等。
工欲善其事，必先利其器。综上所述，一个完善的监控系统是IT系统构建之初就该考虑的关键要素。监控系统可以贯穿于移动端、前端、业务服务端、中间件、应用层、操作系统等，渗透到IT系统的各个环节。
如图1-1所示，通常情况下，监控系统分为端监控、业务层监控、应用层监控、中间件监控、系统层监控这5层。
1）端监控：
针对用户在体验上可以感知的对象进行监控，如网站、App、小程序等。有些公司会设置专门的端用户体验团队负责进行端监控。在移动客户端的系统中，端监控的对象主要有H5、小程序、android ios
箭（交互采集模型）等理论支撑外，还有一系列相关工具、相关系统与大数据分析提供实践支撑。
2）业务层监控：
对于业务层，可按需深度定制监控系统，实现对业务属性的监控告警功能，生成业务数据监控大盘。比如用户访问QPS、DAU日活、转化率、业务接口（如登录数、注册数、订单量、支付量、搜索量）等都是常见的监控对象。
3）应用层监控：
主要是对分布式应用和调用链应用的性能进行管理和监控，如对Spring Boot、JVM信息、服务链路、Dubbo等应用在进行诸如RPC调用、Trace链路追踪动作时产生的数据进行监控。
4）中间件监控：
监控的主要对象是框架自身的埋点、延迟、错误率等。这里的中间件包括但不限于消息中间件（RabbitMQ、Kafka、RocketMQ等）、数据库中间件
（mysql
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团队），目的是通过监控系统了解技术应用或运行的环境状况，并检测、洞察、诊断、解决因环境引发的故障或潜在风险。除了运维部门外，中间件团队、业务团队中的技术人员同样需要了解监控。
近年来，随着以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进行全链路压测，尤其是针对复杂业务场景和海量数据冲击，要保障整个业务系统链的可用性和稳定性。
躺在GitHub仓库中的代码，即使风格再好、注释再详细、算法再精妙，如果没有运行，则对于业务而言依然是没有任何意义的。运行中的代码才是有价值的。以Prometheus为代表的遵从MDD理念的产品，并不会做静态代码检查，而是会对执行过的代码、代码执行次数、错误位置、错误数量等信息进行运行时动态监控。下面就对MDD理念进行详细介绍。
MDD（Metrics-Driven Development）主张整个应用开发过程由指标驱动，通过实时指标来驱动快速、精确和细粒度的软件迭代。指标驱动开发的理念，不但可以让程序员
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
Business Metrics：运营数据或者业务数据，比如单位时间订单数、支付成功率、A/B测试、报表分析等。
业界有很多Metrics实现方案，比如dropwizard-metrics、prometheus-metrics等，我个人推荐用开源产品Micrometer来实现Metrics监控。
在了解了MDD理念以后，大家还需要了解一些基于指标的方法论，这里以小知识点的形式总结如下。
有4个来自Google SRE手册的黄金指标，这4个指标主要针对应用程序或用户部分。
延迟（Latency）： 服务请求所需耗时，例如HTTP请求平均延迟。需要区分成功请求和失败请求，因为失败请求可能会以非常低的延迟返回错误结果。
流量（Traffic）： 衡量服务容量需求（针对系统而言），例如每秒处理的HTTP请求数或者数据库系统的事务数量。
错误（Errors）： 请求失败的速率，用于衡量错误发生的情况，例如HTTP 500错误数等显式失败，返回错误内容或无效内容等隐式失败，以及由策略原因导致的失败（比如强制要求响应时间超过30ms的请求为错误）。
饱和度（Saturation）： 衡量资源的使用情况，例如内存、CPU、I/O、磁盘使用量（即将饱和的部分，比如正在快速填充的磁盘）。
USE是Utilization（使用率）、Saturation（饱和度）、Error（错误）的首字母组合，是Netflix的内核和性能工程师Brendan Gregg提出的，主要用于分析系统性能问题，可以指导用户快速识别资源瓶颈及错误。
使用率： 关注系统资源的使用情况。这里的资源主要包括但不限于CPU、内存、网络、磁盘等。100%的使用率通常是系统性能瓶颈的标志。
饱和度： 例如CPU的平均运行排队长度，这里主要是针对资源的饱和度（注意，不同于四大黄金指标）。任何资源在某种程度上的饱和都可能导致系统性能的下降。
错误：错误数。 例如，网卡在数据包传输过程中检测到以太网络冲突了14次。
RED方法是Weave Cloud基于Google的4个黄金指标再结合Prometheus及Kubernetes容器实践得出的方法论，特别适用于对云原生应用以及微服务架构应用进行监控和度量。在四大黄金指标的原则下，RED方法可以有效地帮助用户衡量云原生以及微服务应用下的用户体验问题。RED方法主要关注以下3种关键指标。
（Request）Errors： 每秒失败的请求数。
（Request）Duration： 每个请求所花费的时间，用时间间隔表示。
一般来说，上述三大监控理论的最佳实践是：在遵循Google四大黄金指标的前提下，对于在线系统，结合RED方法和缓存命中率方式进行监测；对于离线系统或者主机监控，以USE方法为主进行监测；对于批处理系统，可以采用类似Pushgateway的形式进行监控。
* 本文经出版社授权发布，更多关于Prometheus监控技术，推荐阅读《Prometheus云原生监控：运维与开发实战》
《Prometheus云原生监控：运维与开发实战》
