点击上方“民工哥技术之路”，选择“设为星标”
回复“”获取独家整理的学习资料！
本文摘自于朱政科撰写的《Prometheus云原生监控：运维与开发实战》，介绍了监控的概念、监控的分类、MDD理念、Google四大黄金指标、USE方法、RED方法等监控理论。监控是一门学问，也是一门艺术。亚马逊副总裁、CTOWernerVoegls说过：“Youbuildit,yourunit,youmonitorit.”（你构建了它，你运行它，你就有责任监控它。）爱尔兰第一代开尔文男爵LordKelvin和现代管理学之父彼得·德鲁克也曾说过：“Ifyoucan’tmeasureit,youcan’timproveit.”（如果没有了如指掌，你就无法做出改进。）监控无处不在，对软硬件进行监控，并实现系统的可观察性是监控技术人员的必备技能。近几年来，随着微服务、容器化、云原生等新架构思想的不断涌入，企业的IT架构逐渐从实体的物理服务器，迁移到以虚拟机为主的IaaS（Infrastructure-as-a-Service）云和以容器云平台为主的PaaS（Platform-as-a-Service）云上。日新月异的IT架构为监控系统带来了越来越多的挑战，也对技术人员提出了越来越高的要求。年阿里“双十一”期间，订单峰值达到54.4万笔/秒，创下了新的纪录。“双十一”期间的单日数据处理量也达到PB。面对世界级流量洪峰，阿里巴巴实现了%核心应用以云原生的方式上云，并交出了一份亮眼的成绩单：1）“双十一”基础设施%上云；2）“双十一”在线业务容器规模达到万；3）采用基于神龙架构的弹性裸金属服务器，使计算性价比提升了20%。阿里云在上万个Kubernetes（简称K8S）集群大规模实践中，保证了全球跨数据中心的可观测性，这正是基于PrometheusFederation的全球多级别监控架构实现的。在正式介绍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）应用层监控：主要是对分布式应用和调用链应用的性能进行管理和监控，如对SpringBoot、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统计输出、端口、核心服务的进程存活情况、关键业务进程资源消耗、NTPoffset采集、DNS解析采集等指标。这些都可以作为对系统层监控的关键指标。另外，网络监控也是系统监控中很重要的部分，对交换机、路由器、防火墙、VPN进行的监控都属于网络监控的范畴，内网和外网的丢包率、网络延迟等也都是很重要的监控指标。市面上的监控系统可以说是五花八门，Apache的SkyWalking、百度的DP、美团的CAT、蚂蚁金服的九色鹿、宜信的UAVstack、滴滴的Omega、和头条的Sentry、腾讯的badjs、阿里云的arms，以及已经商业化的Fundbug、听云和神策等，都是很知名的监控系统。每种监控系统都有各自的价值，通常来说，Zabbix是针对系统层的监控系统，ELK（Elasticsearch+Logstash+Kibana）主要是做日志监控的，而Prometheus和Grafana可以实现对端、业务层、应用层、中间件、系统层进行监控，因此Prometheus是打造一站式通用监控架构的最佳方案之一。在CNCF全景图中，也罗列了一系列的监控产品，如图1-2所示。监控系统中的监控功能可以告诉我们系统的哪些部分正常工作，哪里出现了问题；监控系统具有的可观察性可以帮助我们判断出有问题的地方为何不能工作了。除了监控功能和可观察性外，数据分析对监控系统来说也非常重要。监控系统获取的数据可以使用大数据、漏斗分析、分析模型和算法等进行分析（Analysis）。监控功能和可观察性相辅相成，可观察性已经作为一个新的理念进入人们的视野，如图1-2所示，云原生计算基金会在其Landscape中将可观察性和数据分析单独列为一个分类—ObservabilityandAnalysis，这个分类主要包括Monitoring、Logging、Tracing、ChaosEngineering这4个子类。Monitoring子类中的产品与监控相关，包括Prometheus、Grafana、Zabbix、Nagios等常见的监控软件，以及Prometheus的伴侣Thanos。Logging子类中的产品与日志相关，比如Elastic、logstash、fluentd、Loki等开源软件。Tracing子类中的产品与追踪相关，包括Jaeger、SkyWalking、Pinpoint、Zipkin、SpringCloudSleuth等。ChaosEngineering是一个新兴的领域。随着云原生系统的演进，系统的稳定性受到很大的挑战，混沌工程通过反脆弱思想，在系统中模拟常见的故障场景，以期提前发现问题。ChaosEngineering可以帮助分布式系统提升可恢复性和容错性。监控是为技术人员和业务人员提供服务的。一般来说，在技术团队，往往会由专职的运维人员负责管理和维护监控系统（在某些公司中，这样的运维团队可能会被称为效能组、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用于健康监控（这种监控方式在微服务SpringBoot中使用较多），如图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进行全链路压测，尤其是针对复杂业务场景和海量数据冲击，要保障整个业务系统链的可用性和稳定性。3MDD思想：从指标到洞察力躺在GitHub仓库中的代码，即使风格再好、注释再详细、算法再精妙，如果没有运行，则对于业务而言依然是没有任何意义的。运行中的代码才是有价值的。以Prometheus为代表的遵从MDD理念的产品，并不会做静态代码检查，而是会对执行过的代码、代码执行次数、错误位置、错误数量等信息进行运行时动态监控。下面就对MDD理念进行详细介绍。3.1MDD理念综述MDD（Metrics-DrivenDevelopment）主张整个应用开发过程由指标驱动，通过实时指标来驱动快速、精确和细粒度的软件迭代。指标驱动开发的理念，不但可以让程序员实时感知生产状态，及时定位并终结问题，而且可以帮助产品经理和运维人员一起转载请注明：http://www.guyukameng.com/aspnet/aspnet/2021-02-25/12536.html