其他
监控之美——Prometheus云原生监控
朱政科
读完需要
25分钟速读仅需 3 分钟
监控是一门学问,也是一门艺术。亚马逊副总裁、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)端监控:针对用户在体验上可以感知的对象进行监控,如网站、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所示。
Monitoring子类中的产品与监控相关,包括Prometheus、Grafana、Zabbix、Nagios等常见的监控软件,以及Prometheus的伴侣Thanos。 Logging子类中的产品与日志相关,比如Elastic、logstash、fluentd、Loki等开源软件。 Tracing子类中的产品与追踪相关,包括Jaeger、SkyWalking、Pinpoint、Zipkin、Spring Cloud Sleuth等。 Chaos Engineering是一个新兴的领域。随着云原生系统的演进,系统的稳定性受到很大的挑战,混沌工程通过反脆弱思想,在系统中模拟常见的故障场景,以期提前发现问题。Chaos Engineering可以帮助分布式系统提升可恢复性和容错性。
2
监控架构分类
在我的第一本书《HikariCP数据库连接池实战》的第10章中,介绍过3种应用于微服务架构的监控体系—Metrics、Tracing和Logging,这里补充第四种监控体系—HealthCheck。HealthCheck用于健康监控(这种监控方式在微服务Spring Boot中使用较多),如图1-3所示。
Metrics的特点是可聚合(Aggregatable),它是根据时间发生的可以聚合的数据点。通俗地讲,Metrics是随着时间的推移产生的一些与监控相关的可聚合的重要指标(如与Counter计数器、Historgram等相关的指标)。 Logging是一种离散日志(或称事件),分为有结构的日志和无结构的日志两种。 Tracing是一种为请求域内的调用链提供的监控理念。
3
MDD 思想:从指标到洞察力躺在GitHub仓库中的代码,即使风格再好、注释再详细、算法再精妙,如果没有运行,则对于业务而言依然是没有任何意义的。运行中的代码才是有价值的。以Prometheus为代表的遵从MDD理念的产品,并不会做静态代码检查,而是会对执行过的代码、代码执行次数、错误位置、错误数量等信息进行运行时动态监控。下面就对MDD理念进行详细介绍。
MDD 理念综述MDD(Metrics-Driven Development)主张整个应用开发过程由指标驱动,通过实时指标来驱动快速、精确和细粒度的软件迭代。指标驱动开发的理念,不但可以让程序员实时感知生产状态,及时定位并终结问题,而且可以帮助产品经理和运维人员一起关注相关的业务指标,如图1-6所示。
将指标分配给指标所有者(业务、应用、基础架构等)。 创建分层指标并关联趋势。 制定决策时使用的指标。
对软件研发人员来说,可以实时感知应用各项指标、聚焦应用优化。 对运维人员来说,可以实时感知系统各项指标、快速定位问题。 对产品经理、商务人士来说,可以实时掌控业务各项指标,通过数据帮助自己做出决策。
Infrastructure/System Metrics:如服务器状态、网络状态、流量等。 Service/Application Metrics:如每个API耗时、错误次数等,可以分为中间件监控、容器监控(Nginx、Tomcat)等。 Business Metrics:运营数据或者业务数据,比如单位时间订单数、支付成功率、A/B测试、报表分析等。
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:每个请求所花费的时间,用时间间隔表示。
- EOF -
想要加入中生代架构群的小伙伴,请添加群合伙人大白的微信
申请备注(姓名+公司+技术方向)才能通过哦!
好文推荐
2020-11-13
2020-11-12
2020-11-10
2020-11-09
2020-11-11
2020-11-06
2020-11-05
2020-11-03
2020-11-02
2020-10-30
2020-10-28
2020-10-27
2020-10-22
2020-10-20
2020-10-19
END
#架构师必备#