精华内容
下载资源
问答
  • 监控之美——Prometheus云原生监控

    千次阅读 2020-11-14 09:00:00
    朱政科读完需要25分钟速读仅需 3 分钟本文摘自于朱政科撰写的《Prometheus 云原生监控:运维与开发实战》,介绍了监控的概念、监控的分类、MDD 理念、Google 四大黄金指标...

    朱政科

    读完需要

    25

    分钟

    速读仅需 3 分钟

    本文摘自于朱政科撰写的《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内置函数等实际工作中需要时常查阅的内容。

    - EOF -

    想要加入中生代架构群的小伙伴,请添加群合伙人大白的微信

    申请备注(姓名+公司+技术方向)才能通过哦!

    好文推荐

    蚂蚁研究员玉伯:做一个简单自由有爱的技术人

    2020-11-13

    腾讯游戏许振文:王者荣耀实时大数据平台黑科技解密

    2020-11-12

    多隆:从工程师到阿里巴巴合伙人

    2020-11-10

    58 转转技术总监骆俊武:一个核心系统 3 万多行代码的重构实战篇

    2020-11-09

    徐昊:运用四色建模法进行领域分析

    2020-11-11

    中台实践:数据中台构建五步法

    2020-11-06

    为什么说IT科技公司应该留住35岁员工?

    2020-11-05

    混沌工程:苏宁系统稳定性之道

    2020-11-03

    贝壳找房技术总监肖鹏:高速成长下的技术团队怎么带?

    2020-11-02

    阿里技术专家楚衡:架构制图的工具与方法论

    2020-10-30

    蚂蚁集团技术专家山丘:性能优化常见压测模型及优缺点

    2020-10-28

    京东平台研发朱志国:领域驱动设计(DDD)理论启示

    2020-10-27

    架构专家高磊:缓存为王——无线缓存架构优化

    2020-10-22

    阿里文娱技术专家战獒: 领域驱动设计详解之What, Why, How?

    2020-10-20

    工程师的基本功是什么?如何练习?听美团技术大咖怎么说

    2020-10-19

       END     
    #架构师必备#
    
    点分享点点赞点在看
    
    展开全文
  • 作者领读 | Prometheus云原生监控

    千次阅读 2020-11-16 07:00:00
    撰文:朱政科01 作者导读昨天收到书,用了两天时间,我也亲自把这本书读完了一遍。今天写这篇文章的目的是带读者用正确的方式读这本书。《Prometheus云原生监控:运维与开发实战》‍‍上...

    撰文:朱政科

    01 作者导读

    昨天收到书,用了两天时间,我也亲自把这本书读完了一遍。今天写这篇文章的目的是带读者用正确的方式读这本书。

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

    上下滑动查看书籍目录

    赞誉

    前言

    第1章 监控之美  1

    1.1 监控:把握应用的脉搏  2

    1.2 监控架构分类  6

    1.3 MDD思想:从指标到洞察力  10

    1.3.1 MDD理念综述  10

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

    1.4 监控系统选型分析及误区探讨  13

    1.4.1 黑盒监控和白盒监控  14

    1.4.2 监控检查的两种模式—拉取和推送  14

    1.4.3 5种常见的监控系统  15

    1.4.4 监控系统的选型分析及误区探讨  24

    1.5 本章小结  32

    第2章 Prometheus入门  33

    2.1 Prometheus发展简史  34

    2.2 Prometheus的主要特点  35

    2.3 Prometheus架构剖析  37

    2.4 Prometheus的3大局限性  43

    2.5 快速安装并启动Prometheus  43

    2.6 本章小结  49

    第3章 Spring Boot可视化监控实战  50

    3.1 用Micrometer仪表化JVM应用  50

    3.2 在Spring Boot 2.x中集成Prometheus的方法  53

    3.2.1 引入Maven依赖  54

    3.2.2 application.properties配置  56

    3.2.3 通过MeterBinder接口采集和注册指标  57

    3.2.4 以埋点的方式更新指标数据  58

    3.2.5 效果展示  59

    3.3 针对Spring Boot 2.x采集并可视化相关数据  61

    3.4 第三方专业可视化工具—Grafana  62

    3.5 Grafana高级模板  67

    3.6 邮件告警的生成与扩展  77

    3.6.1 通过Alertmanager生成邮件告警  77

    3.6.2 邮件告警扩展:cc和bcc  79

    3.7 构建钉钉告警系统  80

    3.7.1 安装MacOS Docker  80

    3.7.2 安装Docker镜像  81

    3.7.3 钉钉接入设置  83

    3.7.4 钉钉告警功能验证  84

    3.8 本章小结  86

    第4章 PromQL让数据会说话  87

    4.1 初识PromQL  87

    4.1.1 PromQL的4种数据类型  89

    4.1.2 时间序列  90

    4.1.3 指标  91

    4.2 PromQL中的4大选择器  94

    4.2.1 匹配器  95

    4.2.2 瞬时向量选择器  98

    4.2.3 区间向量选择器  99

    4.2.4 偏移量修改器  100

    4.3 Prometheus的4大指标类型  101

    4.3.1 计数器  101

    4.3.2 仪表盘  103

    4.3.3 直方图  104

    4.3.4 摘要  107

    4.4 13种聚合操作  109

    4.5 Prometheus的3种二元操作符  117

    4.5.1 算术运算符  118

    4.5.2 集合/逻辑运算符  119

    4.5.3 比较运算符  120

    4.5.4 优先级  122

    4.6 向量匹配  122

    4.6.1 一对一匹配  122

    4.6.2 一对多和多对一匹配  123

    4.6.3 多对多匹配  124

    4.7 本章小结  124

    第5章 PromQL高级实战  125

    5.1 Prometheus内置函数  125

    5.1.1 动态标签函数  126

    5.1.2 数学运算函数  128

    5.1.3 类型转换函数  133

    5.1.4 时间和日期函数  133

    5.1.5 多对多逻辑运算符函数  137

    5.1.6 排序函数  138

    5.1.7 Counter函数  139

    5.1.8 Gauge函数  141

    5.1.9 Histogram函数  144

    5.1.10 时间聚合函数  145

    5.2 HTTP API  146

    5.2.1 API响应格式  148

    5.2.2 表达式查询  149

    5.2.3 元数据管理  150

    5.2.4 其他拓展  151

    5.3 两种可定期执行的规则  155

    5.3.1 记录规则  155

    5.3.2 告警规则  159

    5.4 指标的抓取与存储  160

    5.4.1 用relabel_conf?igs抓取指标  160

    5.4.2 用metric_relabel_conf?igs存储指标  163

    5.5 通过调优解决PromQL耗尽资源问题  166

    5.6 本章小结  166

    第6章 Prometheus告警机制深度解析  167

    6.1 Alertmanager架构解析  167

    6.2 AMTool的安装与用法  169

    6.3 配置文件的编写与解读  171

    6.4 告警规则的定义  177

    6.5 关于告警的高级应用与问题处理  180

    6.5.1 Prometheus告警失灵  180

    6.5.2 出现告警轰炸的问题  182

    6.6 构建高可用告警集群  184

    6.7 本章小结  186

    第7章 Prometheus独孤九剑:通过定制Exporter监控一切  187

    7.1 Exporter概述  187

    7.2 Exporter的数据规范  189

    7.3 Exporter数据采集方式  191

    7.4 一个最简单的Exporter示例  192

    7.5 自己动手编写一个Exporter  195

    7.6 高质量Exporter的编写原则与方法  198

    7.6.1 分配合理的端口号  198

    7.6.2 设计落地页  201

    7.6.3 将软件版本信息提供给Prometheus的正确方法  201

    7.6.4 必备指标的梳理  202

    7.6.5 编写高质量Exporter的其他注意事项  209

    7.7 Node Exporter源码解析  210

    7.8 Exporter高级应用:开启TSL连接和Basic Auth认证  214

    7.8.1 准备证书  214

    7.8.2 支持TLS的配置方法  214

    7.8.3 支持Basic Auth的配置方法  215

    7.9 本章小结  216

    第8章 Spring Boot高级监控实战  217

    8.1 Controller监控实战  217

    8.2 业务代码监控实战  218

    8.3 通过注解进行监控的设置与实战  221

    8.4 Dubbo监控实战  223

    8.5 SPI机制原理解析  225

    8.6 SPI高级实战:基于Dubbo的分布式日志链路TraceID追踪  228

    8.7 集成Spring Boot时的常见问题及其解决方案  231

    8.8 关于Micrometer的两个常见问题及其解决方案  234

    8.8.1 极大值BUG问题  235

    8.8.2 Actuator内存溢出问题  237

    8.9 micrometer-spring-legacy源码解析  242

    8.9.1 spring.factories  244

    8.9.2 CompositeMeterRegistryAuto-Conf?iguration  246

    8.9.3 XX-MeterRegistry的注册  248

    8.9.4 WebMvcMetricsFilter过滤器  249

    8.9.5 其他  250

    8.10 本章小结  251

    第9章 Prometheus集群实战  252

    9.1 校时  252

    9.2 Prometheus的3种常见HA架构

     方案  255

    9.2.1 简单HA  256

    9.2.2 简单HA+远程存储  256

    9.2.3 简单HA+远程存储+联邦集群  257

    9.2.4 联邦集群配置方式  261

    9.2.5 功能分区配置方式  262

    9.2.6 K8S单点故障引发的POD漂移问题  263

    9.3 Prometheus集群架构采集优化方案  263

    9.4 在企业中从零推广Prometheus架构  266

    9.4.1 研发团队  266

    9.4.2 运维团队  267

    9.4.3 借助K8S一起推进上线  268

    9.5 搭建基于M3DB的简单HA+远程存储Prometheus K8S集群  268

    9.5.1 架构说明  268

    9.5.2 K8S内部Prometheus  270

    9.5.3 K8S外部Prometheus  270

    9.5.4 M3DB  276

    9.6 多租户、可横向扩展的Prometheus即服务—?Cortex  277

    9.7 本章小结  280

    第10章 Prometheus存储原理与问题分析  281

    10.1 本地存储文件结构解析  282

    10.2 存储原理解析  286

    10.3 存储配置方法  287

    10.4 本地存储容量规划原则与方法  290

    10.5 RAM容量规划原则与方法  291

    10.6 本地存储及时性和时序性问题分析  293

    10.7 本章小结  294

    第11章 Prometheus其他相关技术分析与实战  296

    11.1 Thanos架构与监控实战  296

    11.1.1 Thanos架构解析  297

    11.1.2 Thanos在Prometheus监控中的作用与实战  299

    11.1.3 Thanos存在的问题  302

    11.2 M3DB技术详解  303

    11.3 Loki的特性、架构与应用  306

    11.3.1 Loki特性  307

    11.3.2 Loki架构简介  308

    11.3.3 Loki使用方法  310

    11.4 ELK的5种主流架构及其优劣分析  311

    11.4.1 为什么要用ELK  312

    11.4.2 基础架构  313

    11.4.3 改良架构  314

    11.4.4 二次改良架构  315

    11.4.5 基于Tribe Node概念的架构  316

    11.4.6 带有冷热分离功能的架构  316

    11.5 Fluentd和Fluent Bit项目简介  317

    11.6 Operator模式现状与未来展望  319

    11.7 关于灵活运用Prometheus的几点建议  321

    11.8 本章小结  323

    附录A Prometheus相关端口列表  324

    附录B PromQL速查手册  350

    附录C Prometheus 2.x(从2.0.0到2.20.0)的重大版本变迁  354

    附录D Prometheus自监控指标  363

    附录E SLA服务可用性基础参考指标  366

    首先要和大家说的是,这本书除了上百个案例以外,是配有免费视频的。重要的事情说三遍,配有免费视频的、配有免费视频的、配有免费视频的!!!地址如下:

    https://www.imooc.com/learn/1231

    其次要和大家说的是,在写这本书的期间,我的确读过了很多同类型的书籍。

    第一章

    第一章是理论基础,第一章的内容我写了足足一个月时间,耗时之久。它非微观,而是宏观上从方法论上几近全方位的覆盖了监控的方方面面。建议读者朋友们不要略过本章节,相信本章节一定会对大家有所启发。

    举个例子,本章甚至对很多监控系统的英文名都做了罗列,可以看出作者是很用心的在做这件事,诸如:

    Nagios 原名NetSaint,是NagiosAin'tGonna Insist On Sainthood的缩写,Sainthood 翻译为圣徒,而Agios是saint的希腊表示方法。

    Ganglia的英文直译为神经节、中枢神经,项目的名称其实已经反映了作者的设计思路,即将服务器集群理解为生物神经系统,每台服务器都是独立工作的神经节,这些神经节通过多层次树突结构连接起来,既可以横向联合,也可以从低向高逐层传递信息。具体例证就是Ganglia的收集数据可以工作在单播(unicast) 或多播(multicast) 模式下(默认为多播模式)。很多通过cacti或者Zabbix看不出来的集群总体负载问题,都能在Ganglia中体现,其集群的熵图可以明确集群负载状况,这是Ganglia最大的亮点。

    Falcon 是猎鹰、隼的意思,鹰眼具有精准、洞穿的特点。

    第一章精心准备了大量的表格,比如Zabbix、Nagios、Ganglia、Open-Falcon、Prometheus等主流监控系统全方位的对比;比如Go语言开发的系统生态,监控系统、微服务框架、WEB框架、WEB工具、容器项目、PAAS工具、数据库工具、存储工具及分布式文件系统、消息系统、服务管理工具、安全工具、网络工具、分布式系统、区块链项目等;以及从功能、性能、数据存储、服务发现、运维管理、开发语言、社区力度及生态发展、误区探讨等九个角度进行监控系统的选型分析思路。

    第一章最后给读者的启示是,千万不要迷信权威。不要迷信权威,不能人云亦云。不是别人说好就是好,一定要自己亲身试验过才有发言权,实践出真知,比如Prometheus的作者就亲自怼过社区关于VictoriaMetrics的不实言论:

    【原创|译】PromCon上VictoriaMetrics和Prometheus的权威性能和正确性评估

    第一章部分原文:

    不同的企业成长时期也可以选择不一样的监控系统,CMDB+Zabbix在一定的量级以内还是非常靠谱和稳定的,一台机器就可以扛住很多的监控业务。如果您的业务和技术并没有达到那个量级且中长期达不到那个量级,投入大量人力物力搞出来的那个“巨无霸”,真的非常有意义和价值吗?很多经验丰富的技术人员用过的监控系统应该不下十种,每款监控工具都有自己的优缺点,并不是越新的技术就越好,不能盲目跟风,没有最好的只有最合适的。Nagios,虽然历史悠久,但是在实际运维中依然有它独立存在的意义,在一些基本的监控项目中甚至比高大上的Prometheus更加方便:比如针对ping和telnet port这两项最基本的监控,prometheus有一个up功能函数进行支持,但是只有两个状态up和down,而Nagios对这种状态比较少的监控更为简单直接。盲目追新并不是监控选型的态度,专业的监控架构是综合实际使用情况去做设计做规划,多种监控可以根据实际情况结合使用、相辅相成。

    十万的用户有十万的架构方案,百万的用户有百万的架构方案,千万的用户有千万的架构方案,亿级的用户有亿级的架构方案。就好比,我团队一个成员开会时曾提出,“现在我维护的网关系统,界面不太好看,我想请前端资源帮我美化一下”。我直接回复:“现在应该没有人接入你的网关吧,当前第一要务是接入,美化的事情并没有接入那么重要,当前也没有必要浪费前端资源”。什么阶段就应该做什么阶段的事情。

    第二、三、八章有免费视频辅助阅读!

    第二章和第三章,手把手带大家搭建基于Spring Boot 2.x的实战监控体系,让大家体会企业项目面向DevOps开发的监控情景。

    第八章是第二、三章的升级,大家可以和二、三章以及视频内容结合起来学习。另外,市面上的Prometheus邮件告警内容都没有cc和bcc功能,本书79页针对抄送和密送能力进行了补充。

    这是有免费视频的,如果看不懂的同学请结合免费视频学习:

    https://www.imooc.com/learn/1231

    第四、五章请作为工具书使用

    第四章和第五章,用了80多页介绍了PromQL,作者给出了上百个实际案例,这是其他Prometheus书籍和官方文档都没有的。这部分内容,阅读了大量的资料,也做了不少的实践。一个个案例剖析,甚至精确到PromQL的极致优化。

    没有深度使用Prometheus的用户,第四章和第五章的实战部分可以直接跳过,看看概念就行。如果需要使用的时候可以当作工具书使用。含有大量的思考、误区规避、注意事项、案例等

    第六章请大家一定要围绕这张架构图去理解Prometheus告警机制的原理:

    也给出了非常详细的类似代码注释一般的配置文件的编写与解读,希望对读者有帮助

    第六章还给出了关于告警过程中分组、抑制、静默等问题做了分析指导。解答技术人员在运维Prometheus过程中,普遍遇到的问题:

    • 为什么该告警的时候不告警 ?

    • 为什么不该告警的时候偏偏告警了 ?

    第七

    第七章分析了很多Exporter的实现原理,并指导读者如何编写自己的Go语言Exporter。

    该章节运用软件工程的知识,通过专业的软件研发流程指导开发者编写Exproter过程中需要注意的方方面面。

    对于安全问题,本章还给出了一个彩蛋,《Exporter高级:开启TSL连接和Basic Auth认证》,感兴趣的读者可以阅读本内容。

    第九


    第九章介绍了Prometheus集群实战的架构问题,讨论多种集群集解决方案的理念、方法及优化手段,探究如何构建更具有扩展性和可靠性的集群实现。对集群感兴趣的同学可以关注本章节。

    02 作者介绍

    朱政科

    资深架构师,中间件技术专家,对数据库连接池和Prometheus等监控技术有深入研究。

    有10余年IT行业从业经验,现就职于国内某大型世界百强企业。

    曾在阿里等一线互联网公司长期从事中间件的研发及团队管理工作。

    先后主导和参与了多个重要的与物联网、人工智能等相关的大型项目。

    著有《HikariCP数据库连接池实战》。

    03 本书的不同之处在哪里?

    • 被誉为Prometheus“百科全书”

    • 可以指导读者快速搭建一个Prometheus监控系统并将其应用到实际工作中

    • 囊括私有云、公有云、混合云环境下的大量案例

    • 针对运维人员,分享Prometheus对接各种云原生应用并实现事前预警、事中报警、事后提供翔实数据的方法

    • 针对开发人员,给出了Prometheus主要组件的源码分析以及部分功能的二次开发实现

    • 从入门知识到高级技巧,全面解读PromQL,并给出上百个PromQL实际案例

    • 以附录的形式给出端口、数据类型、选择器、指标类型、PromQL内置函数等实际工作中需要时常查阅的内容

    04 专家推荐

    Prometheus凭借优秀的表现和简单极致的用户体验,在时序数据库领域脱颖而出,并在监控方面表现优异,成为基础设施建设中不可或缺的部分。在CNCF中,其是除Kubernetes之外最早毕业的项目,这见证了它在云原生领域的影响力和声望。

    本书系统阐述了Prometheus开发与运维的知识和技巧,并且辅助以大量实战案例,能够帮助读者更加立体地掌握Prometheus这项技术。

    很开心看到朱政科将自己的所学所悟集结成书,也很惊讶他如此高效地出版了自己第二本著作。希望他的书籍能够持续给读者提供帮助。

    张 亮

    京东数科数字技术中心架构专家,Apache ShardingSphere、ElasticJob创始人

    Prometheus作为源自Google INFRA的通用开源监控工具,在业界被广泛使用。学习、理解和熟练使用Promehteus,可以帮你快速构建轻量级监控体系。推荐大家通过本书系统学习Prometheus的特性、使用方法和作者的实战经验。

    吴 晟

    Tetrate.io创始工程师,Apache软件基金会会员,

    Apache SkyWalking创始人兼项目VP,

    Apache ShardingSphere、APISIX和Incubator PMC成员

    一辆好车除了要有好的发动机和变速箱之外,还需要仪表盘和各种显示设备,以显示油量、速度等各种车辆状态数据。同理,互联网在线服务如果没有良好的监控告警系统,就如同一个人闭着眼睛开车,那是非常可怕的。

     对于监控系统而言,简单、可配置、可靠、高性能是必要条件,海量数据的采集、存储与可分析是关键。Prometheus 是一套基于时序数据库的、目前最为流行的、较完善的监控解决方案,其可通过监控、告警及性能优化等,帮助企业及时发现问题、定位问题,是不可多得的SRE(网络可靠性工程)利器。

    政科在阿里、华为等一线互联网公司长期从事中间件的研发工作,多次经历“双11”大促,在实践中积累了丰富的经验。这本书从架构、中间件研发、SRE等多个角度详细介绍了Prometheus,以及PromQL等知识,包括相关原理和实战要点,具有较强实战指导意义,是不可多得的佳作。

    徐 巍

    恺英网络技术中心总经理

    监控是温度计,也是指标仪。在监控、告警、应急处置三部曲中,监控是基础。本书全面介绍了Prometheus的应用方法和产品内核,内容翔实,是该领域的佳作。

    于君泽

    《深入分布式缓存》《程序员的三门课》联合作者

    相较以往的系统监控,监控作为可观察性实践(监控、日志、追踪)中的关键一环,在云原生时代产生了诸多变化:一是微服务和容器化,导致监控对象和指标呈指数级增加;二是监控对象的生命周期更加短暂,导致监控数据量和复杂度成倍增加。所以需要一款统一监控指标和数据查询语言的工具,Prometheus 应运而生。Pemetheus可以很方便地与众多开源项目集成,帮助我们了解系统和服务的运行状态,另外还可收集分析大数据,帮助我们进行系统优化和做出决策。它不仅可以应用在IT领域,还可以应用于任何需要收集指标数据的场景中。本书实用、凝练,是一本云原生时代监控领域难得的好书。

    宋净超

    云原生社区创始人

    Prometheus作为第二个从CNCF毕业的项目,目前已经在全球各大企业中广泛使用,可以说是云原生架构首选的开源监控工具。作者作为该领域实战派专家,在本书中全方位阐述了Prometheus的系统架构和工作原理。更难能可贵的是,书中还包含大量实际项目落地指引、最佳实践,以及常见问题的解决方案,是学习Prometheus不可多得的好书。

    张 乐

    京东DevOps与研发效能技术总监

    监控系统是DevOps工程师或SRE工程师必须掌握的系统,因为他们80%以上的线上运维事务都与监控密切相关。完美的监控系统,可以大力促进运维向智能化发展,结合业务报警实现故障快速自愈、无人化运维,并可及时定位问题根源,以及依据历史监控数据对指标做出预测。Prometheus几乎是为云原生而生的监控系统,它具有易于管理、可扩展、易集成、易获取服务内部状态、拥有高效灵活的查询语句、支持统计分析数据、生态强大等特点,因此迅速被各大云厂商使用。本书由入门到精通全方位介绍了如何玩转Prometheus,适合关注监控的广大互联网技术从业者阅读。

    王 伟

    Oracle ACE For MySQL,京东零售数据库运维专家

    Prometheus是一款造福广大DevOps、SRE工程师们的分布式监控系统神器。借助愈演愈烈的容器化部署和云原生的浪潮,Prometheus成为CNCF的基石项目。本书作者有深厚的基础中间件研发背景和丰富的实践经验,对Prometheus进行过深入研究和深度应用,他把自己的理解和实战经验总结出来,著成本书。本书文字简洁而不失其味,对技术原理的剖析鞭辟入里,实用性极强,相信能给读者带来不一样的启发。

    张 聪

    税友软件集团研发中心副总,基础中间件、持续交付工具和大数据平台研发负责人

    我本人接触和使用Prometheus已经很久了,很高兴看到国内有Prometheus相关的书籍出版。本书不局限于Prometheus本身,还对比了市面上其他常见的监控系统,可以帮助读者更好地理解Prometheus。本书还介绍了很多常见的方法论。配合这些方法论,以及书中的实战内容,读者可以更好地建设自己的监控体系。

    张晋涛

    网易有道资深运维开发人员,云原生技术布道师

    基于云的技术,不论是上层应用还是底层云平台,都离不开监控,而Prometheus是云化场景下的事实性标准。作者结合丰富的Prometheus实战经验写成本书。本书有概念,有方法,有实例,非常值得广大云化技术的从业者阅读。

    苏光牛  

    华为云数据库业务总裁,Gaussdb负责人

    监控是整个运维乃至整个产品生命周期中重要的一环,选择一款开源的监控系统,是一个省时省力且高效的方案。目前业界有很多不错的开源产品可供选择,其中Prometheus已成为企业构建现代云原生架构的首选开源监控工具。本书通过理论和实践相结合的方式展开,非常适合运维人员及对运维监控感兴趣的开发者阅读。

    史健(无济) 

    原阿里云资深技术专家,原奇点云CTO 

    政科曾主导Kubernetes+Prometheus项目,并一举拿下了公司年度产研类项目奖,他拥有丰富的实战经验,本书是他对这些经验的总结。本书在内容上深入浅出,注重实战性、实用性,不仅适用于运维人员,也很好地满足了开发人员的诉求,值得推荐。

    殷柱伟  

    腾讯WeTest产品总监 

    监控的开源项目有很多,但是能像Prometheus这样优秀的作品并不多;讲述监控和Prometheus的书籍有很多,但是像本书一样完整地对Prometheus的方方面面进行剖析的并不多。所以我想,本书一定会对正走在奋斗路上的"监控者"们有所帮助。

    王晓波  

    同程旅行 机票事业群 CTO

    作为作者多年的朋友加同事,熟知作者如何将Prometheus应用在平时的开发、运维工作中。本书便是作者在监控领域多年开发、运维经验的总结,书中对Prometheus的方方面面进行了深入剖析,从入门到精通全方面介绍如何体系化学习Prometheus系统,特别适合在监控或运维领域奋斗的互联网技术同胞们阅读。

     吕飞 

     华为云SRE技术专家,原阿里巴巴运维技术专家

    更多精彩回顾

    书讯 |11月书讯(下)| 这些好书必须“买买买”!

    书讯 |11月书讯(上)| 这些好书必须“买买买”!

    资讯 |DB-Engines 10月数据库排名:“三大王”无人能敌,PostgreSQL紧随其后

    上新 | 百度官方出品 | 全面解读PaddlePaddle,零基础快速入门深度学习
    书单 | 开学季——计算机专业学生必读的10本畅销经典

    干货 | 数据分析必读干货:简单而实用的3大分析方法

    收藏 | (万字长文)Spring的核心知识尽揽其中

    点击阅读全文购买

    展开全文
  • 分享时间:12月3日 20:30分享主题:基于Prometheus的云原生监控系统架构演进分享人介绍:Ray,腾讯云高级工程师,拥有多年大规模Kubernetes集群联邦运维经验,曾就职...

    分享时间:12月3日 20:30

    分享主题:基于Prometheus的云原生监控系统架构演进

    分享人介绍:Ray,腾讯云高级工程师,拥有多年大规模Kubernetes集群联邦运维经验,曾就职于腾讯云监控团队,目前在腾讯云容器团队负责集群可观测性提升相关工作。

    分享摘要:Prometheus作为云原生时代最流行的监控组件,已然成为社区监控的实际标准,拥有活跃的社区和丰富的周边项目。但在多集群,大集群等场景下,Prometheus由于没有分片能力和多集群支持,难以满足生产需求。本次分享将从Prometheus的原理出发,循环渐进,深入浅出得介绍不同场景下的Prometheus监控系统解决方案。

    主要内容

     

    • Prometheus基本原理

    • 单集群监控方案

    • 多集群场景的特点

    • 使用Thanos实现多集群监控

    • 大集群场景的特点

    • Thanos方案的不足

    • 加入Kvass实现大集群监控

    • 总结

    分享群:DockOne技术交流微信群

    DockOne每周都会组织定向的技术分享,欢迎感兴趣的同学加微信:liyingjiesz,或者扫描下方二维码加群主微信,进群参与分享,进群暗号『加群』。如果已经在DockOne技术交流群那等待晚上的分享即可。

    展开全文
  • 监控基础 为什么需要监控 监控如同切脉诊断,是技术人员先于用户发现问题的最佳手段。完善的监控系统能够引导技术人员快速定位问题并解决,可以将系统的问题扼杀于萌芽状态。完善的监控系统,是技术人员运筹帷幄的...

    监控基础

    1. 为什么需要监控

    监控如同切脉诊断,是技术人员先于用户发现问题的最佳手段。完善的监控系统能够引导技术人员快速定位问题并解决,可以将系统的问题扼杀于萌芽状态。完善的监控系统,是技术人员运筹帷幄的强有力保障。我们应建立完善的监控体系.监控系统可以贯穿于移动端、前端、业务服务端、中间件、应用层、操作系统等,渗透到IT系统的各个环节。

    1. 监控要达到的效果
    • 趋势分析:长期收集并统计监控样本数据,对监控指标进行趋势分析。例如,通过分析磁盘的使用空间增长率,可以预测何时需要对磁盘进行扩容。
    • 对照分析:随时掌握系统的不同版本在运行时资源使用情况的差异,或在不同容量的环境下系统并发和负载的区别。
    • 告警:当系统即将出现故障或已经出现故障时,监控可以迅速反应并发出告警。这样,管理员就可以提前预防问题发生或快速处理已产生的问题,从而保证业务服务的正常运行。
    • 故障分析与定位:故障发生时,技术人员需要对故障进行调查和处理。通过分析监控系统记录的各种历史数据,可以迅速找到问题的根源并解决问题。
    • 数据可视化:通过监控系统获取的数据,可以生成可视化仪表盘,使运维人员能够直观地了解系统运行状态、资源使用情况、服务运行状态等.
    1. 五层轻量监控体系

    监控系统分为端监控、业务层监控、应用层监控、中间件监控、系统层监控这5层。
    在这里插入图片描述

    • 端监控:针对用户在体验上可以感知的对象进行监控,如网站、App、小程序等。在移动客户端的系统中,端监控的对象主要有H5、小程序、Android系统、iOS系统等,完善的端监控可以反馈地域、渠道、链接等多维度的用户体验信息;用户终端为传统的Web页面时,端监控仍会围绕用户体验采集数据,比如页面打开速度(测速)、页面稳定性(JS)和外部服务调用成功率(API),这3个方面的数据反映了Web页面的健康度.
    • 业务层监控:对于业务层,可按需深度定制监控系统,实现对业务属性的监控告警功能,生成业务数据监控大盘。比如用户访问QPS、DAU日活、转化率、业务接口(如登录数、注册数、订单量、支付量、搜索量)等都是常见的监控对象.
    • 应用层监控:主要是对分布式应用和调用链应用的性能进行管理和监控,如对Spring Boot、JVM信息、服务链路、Dubbo等应用在进行诸如RPC调用、Trace链路追踪动作时产生的数据进行监控。
    • 中间件监控:监控的主要对象是框架自身的埋点、延迟、错误率等。这里的中间件包括但不限于消息中间件(RabbitMQ、Kafka、RocketMQ等)、数据库中间件(MySQL、Oracle、PostgreSQL、TIDB、PolarDB等)、数据库连接池中间件(HikariCP、Druid、BoneCP等)、缓存中间件(Redis、Memcached等)和Web服务中间件(Tomcat、Jetty等)。
    • 系统层监控:如何对系统层进行监控. 主要包含CPU、Load、内存、磁盘I/O、网络相关参数、内核参数、ss统计输出、端口、核心服务的进程存活情况、关键业务进程资源消耗、NTP offset采集、DNS解析采集等指标。这些都可以作为对系统层监控的关键指标。另外,网络监控也是系统监控中很重要的部分,对交换机、路由器、防火墙、VPN进行的监控都属于网络监控的范畴,内网和外网的丢包率、网络延迟等也都是很重要的监控指标。

    Zabbix是针对系统层的监控系统.

    ELK(Elasticsearch+Logstash+Kibana)主要是做日志监控的

    Prometheus和Grafana可以实现对端、业务层、应用层、中间件、系统层进行监控,因此Prometheus是打造一站式通用监控架构的最佳方案之一.

    • 监控功能
    • 可观察性
    • 数据分析

    监控是为技术人员和业务人员提供服务的

    目的是通过监控系统了解技术应用或运行的环境状况,并检测、洞察、诊断、解决因环境引发的故障或潜在风险.

    概念解析

    • SPM(Super Position Model)全称超级位置模型,是Web端Aplus日志体系和App端UserTrack日志体系共同使用的重要规范。SPM的作用类似于IP地址,可以直接定位前端控件区块。阿里的SPM位置编码由A.B.C.D四段构成,其中A代表站点/业务,B代表页面,C代表页面区块,D代表区块内的点位。
    • SCM(Super Content Model)全称超级内容模型,是一种与业务内容一起下发的埋点数据,用来唯一标识一块内容。在客户端埋点时,将SCM编码作为埋点的参数上传给UT服务器,SCM编码也采用含义与SPM相同的A.B.C.D格式。
    • 黄金令箭,即用户在页面上进行交互行为触发的一个异步请求,用户按照约定的格式向日志服务器发送请求,展现、点击、等待、报错等都可以作为交互行为。规则为/goldenkey_xxx,其中x为一串数字,用于标识某个具体的交互事件。

    监控架构分类

    1. 监控三要素
      在这里插入图片描述
    • Metrics的特点是可聚合(Aggregatable),它是根据时间发生的可以聚合的数据点。通俗地讲,Metrics是随着时间的推移产生的一些与监控相关的可聚合的重要指标(如与Counter计数器、Historgram等相关的指标)。
    • Logging是一种离散日志(或称事件),分为有结构的日志和无结构的日志两种。
    • Tracing是一种为请求域内的调用链提供的监控理念。
      在这里插入图片描述

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

    Prometheus是基于Metrics的监控系统,具有投入成本(CapEx)中等、运维成本(OpEx)低、响应能力(Reaction)高等特点

    在业务开发中,通过查日志的方式就能定位到系统存在问题,通过Tracing模式可以查到链路上出现问题的环节.

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-7Jq76cqw-1620462817929)(https://uploader.shimo.im/f/pfqcWLRufepZNsq9.png!thumbnail?fileGuid=ZzkLVnyxwahQyW3Q)]

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

    MDD思想:从指标到洞察力

    1.MDD思想综述

    MDD(Metrics-Driven Development)主张整个应用开发过程由指标驱动,通过实时指标来驱动快速、精确和细粒度的软件迭代。指标驱动开发的理念,不但可以让程序员实时感知生产状态,及时定位并终结问题,而且可以帮助产品经理和运维人员一起关注相关的业务指标.
    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-iAyYscei-1620462817932)(https://uploader.shimo.im/f/SkQqOr2kSQDCf3PK.png!thumbnail?fileGuid=ZzkLVnyxwahQyW3Q)]

    MDD的关键原则

    * 将指标分配给指标所有者(业务、应用、基础架构等)。
    * 创建分层指标并关联趋势。
    * 制定决策时使用的指标。
    

    MDD则主张将上线、监控、调试、故障调查及优化等纳入设计阶段,而不是等到实施后才补充。相对于通过制定各种复杂、严格的研发规定,以及开无数的评审、研讨会议来确保软件的安全发布、稳定运行,MDD理念的特别之处在于应用程序本身。在MDD理念下,采集必要的监控信息,通过持续交付方式进行快速迭代并进行反馈和修正,所有决定都是基于对不断变化的情况的观察做出的。在软件的设计初期就包括Metrics设计,设计一套规则来评价系统的稳定性、健康状态,并监控其他考核目标,将这些作为服务本身的KPI。因此,通过应用MDD理念,可将Dev与Ops之间或多个Dev团队之间出现的责任博弈降至最低,甚至使矛盾完全消失,这也有利于团队稳定发展。因此,MDD可以用于决策支持、预测趋势、测试系统的补充、关联性分析等。依照MDD的理念,在需求阶段就可以考虑设置关键指标监控项,随着应用的上线,通过指标了解系统状态,通过对现状的可视化和具体化,帮助用户对未来进行规划和预测,进而实现业务改善。传统模式中,Dev和Ops是割裂的,而MDD是DevOps文化的纽带,对于敏捷开发、持续集成、持续交付,以及各个职能岗位提升DevOps意识有很大的帮助。

    MDD理念的监控分层主要有3种

    * Infrastructure/System Metrics:如服务器状态、网络状态、流量等。
    * Service/Application Metrics:如每个API耗时、错误次数等,可以分为中间件监控、容器监控(Nginx、Tomcat)等
    * Business Metrics:运营数据或者业务数据,比如单位时间订单数、支付成功率、A/B测试、报表分析等.
    
    1. 指导实践的3大监控方法论
    • Google的四大黄金指标
      • 延迟(Latency):服务请求所需耗时,例如HTTP请求平均延迟。需要区分成功请求和失败请求,因为失败请求可能会以非常低的延迟返回错误结果。
      • 流量(Traffic):衡量服务容量需求(针对系统而言),例如每秒处理的HTTP请求数或者数据库系统的事务数量。
      • 错误(Errors):请求失败的速率,用于衡量错误发生的情况,例如HTTP 500错误数等显式失败,返回错误内容或无效内容等隐式失败,以及由策略原因导致的失败(比如强制要求响应时间超过30ms的请求为错误)。
      • 饱和度(Saturation):衡量资源的使用情况,例如内存、CPU、I/O、磁盘使用量(即将饱和的部分,比如正在快速填充的磁盘)。
    • Netflix的USE方法

    USE是Utilization(使用率)、Saturation(饱和度)、Error(错误)的首字母组合.

    主要用于分析系统性能问题,可以指导用户快速识别资源瓶颈及错误

    * **使用率**:关注系统资源的使用情况。这里的资源主要包括但不限于CPU、内存、网络、磁盘等。100%的使用率通常是系统性能瓶颈的标志。
    * **饱和度**:例如CPU的平均运行排队长度,这里主要是针对资源的饱和度(注意,不同于四大黄金指标)。任何资源在某种程度上的饱和都可能导致系统性能的下降。
    * **错误**:错误数。例如,网卡在数据包传输过程中检测到以太网络冲突了14次
    
    • Weave Cloud的RED方法

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

    * **(Request)Rate**:每秒接收的请求数。
    * **(Request)Errors**:每秒失败的请求数。
    * **(Request)Duration:**每个请求所花费的时间,用时间间隔表示。
    

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

    监控系统选型分析

    1. 黑盒监控和白盒监控

    监控系统必须支持探针(Probing)和内省(Introspection)。

    • 黑盒监控,对应探针的概念,常见的有HTTP探针、TCP探针等,可以在系统或者服务发生故障时快速通知相关人员进行处理。探针位于应用程序的外部,通过监听端口是否有响应且返回正确的数据或状态码等外部特征来监控应用程序。Nagios就是一个主要基于黑盒/探针的监控系统。
    • 白盒监控,对应内省的概念,通过白盒能够了解监控对象内部的实际运行状态,通过对监控指标的观察能够预判可能出现的问题,从而对潜在的不确定因素进行优化。白盒监控可以直接将事件、日志和指标发送到监控工具,它具有比黑盒监控更丰富的应用程序上下文信息。MDD理念主要对应的就是基于白盒的监控系统。
    1. 监控检查的两种模式-拉取和推送

    监控系统执行监控检查的模式主要有拉取(Pull)和推送(Push)两种.

    • 拉取模式(简称拉模式)
      • **概念:**是一种从监控对象中通过轮询获取监控信息的方式。拉模式更多拉取的是采样值或者统计值,由于有拉取间隔,因此并不能准确获取数值状态的变化,只能看到拉取间隔内的变化,因此可能会产生一些毛刺现象,需要进一步进行数据处理。监控和性能测试更关注p95/p99位的原因就是存在长尾效应。数据采集过程中对数据进行的定义、采样、去尖刺等处理操作也是非常重要的.
      • **优点:**告警可以按照策略分片,告警模块只需要拉取自己需要的数据,且可以完美支持聚合场景;拉模式的缺点在于监控数据体量非常庞大,对存储有较高的要求,实战中可能还需要考虑数据的冷热分离.
    • 推送模式(简称推模式)
      • **概念:**是应用程序基于事件主动将数据推向监控系统的方式
      • **优点:**实时性好,一旦触发一个事件就可以立刻收集发送信息.
      • **缺点:**由于事件的不可预知性,大量的数据推送到监控系统,解析和暂存会消耗大量的内存,这可能对监控的进程产生影响。由于消息是推送过来的,所以主动权在推送方。在这种模式下,由于网络等迟迟没有得到确认,所以在ack等情况下很容易造成数据重复。这是因为推模式在进行推送中,如果发送失败,为了防止内存撑爆,系统会将数据持久化到文件或者队列。因此采用推模式时,若产生了重复数据,就需要进行去重等操作.
    • Prometheus和zabbix分别采用的模式
      • Prometheus在收集数据时,主要采用拉模式(服务端主动去客户端拉取数据),当然它也支持接收推送到Pushgateway的事件;
      • 以Zabbix为代表的传统监控系统采用推模式(客户端发送数据给服务端)。拉模式在云原生环境中有比较大的优势,原因是在分布式系统中,一定是有中心节点知道整个集群信息的,那么通过中心节点就可以完成对所有要监控节点的服务发现,此时直接去拉取需要的数据就好了;推模式虽然可以省去服务发现的步骤,但每个被监控的服务都需要内置客户端,还需要配置监控服务端的信息,这无形中加大了部署的难度
    1. 监控系统选型分析
    2. 功能维度: 直接决定了能否实现开箱即用,从而缩短项目周期、降低成本等

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-N9795VEk-1620462817934)(https://uploader.shimo.im/f/EiGv6WvznuCBYDOj.png!thumbnail?fileGuid=ZzkLVnyxwahQyW3Q)]

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-7X9GkJvI-1620462817936)(https://uploader.shimo.im/f/gBFYByoi893rMJFj.png!thumbnail?fileGuid=ZzkLVnyxwahQyW3Q)]

    1. 性能维度: 性能是根据当前业务量做技术评估的一个重要因素.
      • Zabbix:
        • MySQL写入瓶颈: Zabbix使用MySQL来存放监控历史数据
        • Zabbix有些数据采集会通过服务器端主动探测(拉取)的方式,当目标机器量大了之后,拉任务也经常出现积压.
      • Prometheus
        • 面对海量的监控数据和性能压力,阿里使用了联邦(Federation)的架构将监控压力分担到多个层次的Prometheus并实现全局聚合。在联邦集群中,每个数据中心部署单独的Prometheus,用于采集当前数据中心监控数据,并由一个中心的Prometheus负责聚合多个数据中心的监控数据
        • 针对每个集群的OS指标(如节点资源CPU、内存、磁盘等水位以及网络吞吐)、元集群以及用户集群K8S master指标(如kube-apiserver、kube-controller-manager、kube-scheduler等)、K8S组件(如kubernetes-state-metrics、cadvisor)、etcd指标(如etcd写磁盘时间、DB size、Peer之间吞吐量)等,架构被分层为监控体系、告警体系和展示体系3部分。监控体系按照从元集群监控向中心监控汇聚的角度,呈现为树形结构,其可以细分为3层:
          • 边缘Prometheus:为了有效监控元集群K8S和用户集群K8S的指标,避免网络配置的复杂性,将Prometheus下沉到每个元集群内。
          • 级联Prometheus:级联Prometheus的作用在于汇聚多个区域的监控数据。级联Prometheus存在于每个大区域,例如中国区,欧洲美洲区、亚洲区。每个大区域内包含若干个具体的区域,例如北京、上海、东京等。随着每个大区域内集群规模的增长,大区域可以拆分成多个新的大区域,并始终维持每个大区域内有一个级联Prometheus,通过这种策略可以实现灵活的架构扩展和演进。
          • 中心Prometheus:中心Prometheus用于连接所有的级联Prometheus,实现最终的数据聚合、全局视图和告警。为提高可靠性,中心Prometheus使用双活架构,也就是在不同可用区布置两个Prometheus中心节点,都连接相同的下一级Prometheus。
    2. 数据存储:
      • Zabbix采用关系数据库保存
      • Open-Falcon采用RDD数据存储,也加入了一致性Hash算法分片数据,并且可以对接到OpenTSDB.
      • Prometheus自研了一套高性能的时序数据库,在V3版本可以达到每秒千万级别的数据存储,通过对接第三方时序数据库扩展历史数据的存储。
    3. 服务发现
      • Prometheus的动态发现机制
    4. 运维管理
      • Zabbix:
        • Zabbix管理成本高昂
        • Zabbix易用性问题: Zabbix的模板是不支持继承的,机器分组也是扁平化的,监控策略不容易复用。Zabbix要采集哪些数据,是需要在服务器端做手工配置的
      • 运维管理还需要考虑到Web功能、画图展示、默认监控等
      • 微服务监控有四大难点
        • 配置难。监控对象动态可变,无法进行预先配置
        • 融合难。监控范围非常繁杂,各类监控难以互相融合
        • 排查难。微服务实例间的调用关系非常复杂,故障排查会很困难
        • 建模难。微服务架构仍在快速发展,难以抽象出稳定的通用监控模型
    5. 开发语言
      • Go语言凭借简单的语法和优雅的并发, 在云原生场景使用广泛.
      • Go语言的应用方向:
        • 服务器编程
        • 脚本编程
        • 网络编程
        • 云平台
    6. 社区力度和生态发展
    7. 误区探讨
      • 监控选型时切忌一味地追求性能或者功能,性能可以优化,功能可以二次开发。如果要在功能和性能方面做一个抉择的话,那么首选性能,因为总体上来说,性能优化的空间没有功能扩展的空间大。然而对于长期发展而言,生态又比性能以及功能都重要。
      • 监控系统选型还有一个标准,就是尽量贴合团队的自身技术体系栈.没有最好的,只有最合适的
      • 盲目追新并不是监控选型的态度,专业的监控架构是综合实际使用情况去做设计、做规划的,可以根据实际情况结合使用多种监控.

    参考链接和书籍

    展开全文
  • 翻译:陆离校对:杨乾坤(欧文)本文描述了程序开发人员如何使用 Apache Flink 内置的 Metrics 系统和Prometheus结合的方式,有效的观测和监控流式...
  • 首先感谢活动主办方举办了本次技术交流会,演讲的内容多多少少能对现在公司项目的优化或功能开发带来些积极的影响。... 黄俊华-虎曼(阿里平台技术部资深开发工程师) 走进企业微信小程序 肖文(腾讯前端高...
  • 监控和日志是大型分布式系统的重要基础设施:监控可以帮助开发者查看系统的运行状态,而日志可以协助问题的排查和诊断。云原生应用具有分布与动态的特性,而所有此类应用通常都会用到容器和无服务器...
  • 负责 TKE 集群,弹性集群和云原生监控等模块控制台开发。 概述 Prometheus 是一套开源的系统监控报警框架。2016 年,Prometheus 正式加入 Cloud Native Computing Foundation,成为受欢迎度仅次于 Kubernetes 的项目...
  • 云原生应用的设计理念已经被越来越多的开发者接受与认可,而Kubernetes做为云原生的标准接口实现,已经成为了整个stack的中心,云服务的能力可以通过CloudProvider、CRDController、Operator等等的方式从Kubernetes...
  • 云原生应用 Kubernetes 监控与弹性实践
  • 从 Kubernetes 成为容器管理领域的事实标准开始,基于云原生也就是基于 Kubernetes 原生。在云的体系下,基础硬件基本上都被抽象化、模糊化,硬故障需要人为干预的频次在逐渐降低,健康检查、失败自愈、负载均衡等...
  • 2016年由Google发起Linux基金会旗下的原生云基金会(Cloud Native Computing Foundation), 将Prometheus纳入其下第二大开源项目。 Prometheus目前在开源社区相当活跃。 Prometheus和Heapster(Heapster是K8S的
  • 云原生应用的设计理念已经被越来越多的开发者接受与认可,而Kubernetes做为云原生的标准接口实现,已经成为了整个stack的中心,云服务的能力可以通过Cloud Provider、CRD Controller、Operator等等的方式从...
  • 文章目录目录云原生应用的特征云原生应用的架构如何构建云原生应用 云原生应用的特征 普遍可访问(Universal Availability):服务可在任何地方从多前端访问。 高可用性(High Availability):基本服务随时...
  • 这里写目录标题云原生的基础架构1. 微服务2. 容器3. 服务网格5. 声明式 API云原生应用的特征:云原生与“12 因素”1. 方法论和核心思想2. 编码、部署和运维原则3. 具体内容小结参考 云原生的基础架构 云原生中既有...
  • 监控(Monitoring)和日志(Logging),是大型分布式系统中最关键的基础设施之一,因为没有监控,就没办法知晓服务的运行情况,也没办法知道集群中有没有Down机、机器的CPU使用率和负载是否正常、网站的Traffic是否...
  • 云原生

    2021-01-03 20:14:26
    云原生技术发展史 云原生基金会(CNCF)简介 Cloud Native Computing Foundation,云原生计算基金会(以下简称CNCF)是一个开源软件基金会,它致力于云原生(Cloud Native)技术的普及和可持续发展。云原生技术是...
  • 把应用迁移到云上就是云原生架构吗?什么才是云原生架构?为什么要作云原生架构?本文告诉你,除了把应用搬到云上,要实现云原生,你还要做很多。
  • 文章目录目录DevOps云原生的运维 DevOps DevOps 就是为了解决应用 “持续交付问题”。DevOps 平台包括:GitHub、Travis、Artifactory、Spinnaker、FIAAS、Kubernetes、Prometheus、Datadog、Sumologic 和 ELK 等组件...
  • 12月16-17日,由CNCF、网易数帆、VMware、PingCAP和阿里云联合主办2020 Cloud Native Day云原生生态大会线上召开,来自联合主办方及字节跳动、Zilliz、百胜中国等公司的17位重磅演讲嘉宾,带来2天主题分享,解析...
  • 云原生时代下的监控

    千次阅读 2020-04-10 10:04:38
    概述现代可观察性的三大支柱:日志log记录,metric收集和请求跟踪trace 每个方面在资源利用率,易用性,易操作性和成本效益方面的优缺点 日志、指标、trace 结合使用时涉及的挑战 在现代云原生环境中监控什么以及...
  • 在这个人人都谈“云原生”的时代,企业在建设内部相关系统时常常会优先考虑云原生架构。那么,云原生架构的系统与传统架构系统有什么不同?又该如何建设呢?本文我们邀请京东架构师韩超老师分享了京东基...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 26,996
精华内容 10,798
关键字:

云原生监控