关于阿里云:Apache-Dubbo-云原生可观测性的探索与实践

31次阅读

共计 3912 个字符,预计需要花费 10 分钟才能阅读完成。

作者:宋小生 – 安全壹钱包中间件资深工程师

Dubbo3 可观测能力速览

Apache Dubbo3 在云原生可观测性方面实现重磅降级,应用 Dubbo3 最新版本,你只须要引入 dubbo-spring-boot-observability-starter 依赖,微服务集群即原生具备以下能力:

能力一:可视化查看集群、单机流量指标与衰弱状态

Dubbo 3.2 最新版本反对以利用、单机、单条服务等多种不同粒度观测运行状态,包含 qps、rt、线程池、谬误分类统计等。

能力二:全链路追踪

Dubbo 3.2 最新版本通过内置链路过滤器在 RPC 申请中对链路数据进行采集,采集之后通过导出器将链路数据导出到各大厂商。

https://cn.dubbo.apache.org/zh-cn/overview/tasks/observability/

云原生可观测性的摸索

云原生降级的挑战

高质量交付的前一部分有 DevOps 保障开发与测试的品质与效率,后有云原生保障运维部署效率与品质,然而大规模疾速迭代意味着频繁变更,变更与零碎运行带来的稳定性问题不能被忽视,比方宕机,网络与零碎异样等,很多未知的问题难以避免,借助可观测零碎来及时感知问题、高效剖析异样、疾速复原零碎,提前躲避已知问题,深度开掘未知问题,高效晋升运维品质,能够看到建设一个欠缺的可观测平台对于发现已知和未知异样,晋升零碎的稳定性是十分必要的。

Dubbo 可观测建设指标

Dubbo 作为微服务 RPC 根底框架间接建设大而全的可观测零碎与定位不合乎也不是很事实,然而能够从本身登程提供更多的根底监控数据来为企业建设可观测零碎提供助力,可观测性与传统单维度监控不同,更关注的是数据的关联性,通过单维度和多维度角度整体观测和剖析问题,首先从风行的三大支柱指标登程,在此基础之上,Dubbo 提供多维度聚合与非聚合指标帮忙用户疾速发现问题与诊断问题,多维指标中进而能够通过利用、主机等标签信息关联到链路零碎,链路零碎提供了服务申请级别的链路性能与异样问题剖析性能,Dubbo 通过提供链路门面对接各大全链路厂商,链路剖析之后能够通过链路数据例如:TraceId,SpanId 自定义数据等来追踪到具体日志,详情日志中 Dubbo 侧提供了丰盛的专家建议与错误码供开发与运维同学疾速诊断与定位问题。

Dubbo 多维度指标体系

Dubbo 多维度指标体系建设中从纵向和横向两个角度来看,纵向 Dubbo 侧提供繁难接入的门面外观,而后将零碎中采集到的指标存储在内存指标容器中,接着依据指标类型决定是否进行聚合计算,最初将指标导出到不同的指标零碎。从横向角度来看采集维度也笼罩到容易出问题的 RPC 申请链路,三大核心交互与线程资源应用状况等场景。

Dubbo 多维度指标体系采集哪些指标?

后面介绍了大面上的指标采集,然而 Dubbo 应该采集哪些具体的指标呢?接下来能够看到 Dubob 采集指标时参考的一些方法论。

依据谷歌 SRE 书:Google 针对大量分布式监控的经验总结提出 4 个黄金指标(提早、流量、谬误以及饱和度)能够在服务级别帮忙掂量终端用户体验、服务中断、业务影响等层面的问题。

RED 办法 (来自 Tom Wilkie),RED 办法则关注申请、理论工作以及内部视角(即来自服务生产方的视角)蕴含:速率、谬误与持续时间。

USE 办法 (来自 Brendan Gregg):USE 办法次要着眼于资源外部,蕴含:利用率、饱和度与谬误。

Dubbo 多维度指标体系接入 - 导出到 QOS

多维度指标体系在 3.2 之后的版本曾经公布与继续迭代中,对用户来说只须要引入一个依赖即可:

<dependency>
    <groupId>org.apache.dubbo</groupId>   
    <artifactId>dubbo-spring-boot-observability-starter</artifactId>        
    <version>3.2.x</version>
</dependency>

依赖引入之后默认状况下一些要害指标会默认被关上,只须要在命令行拜访以后服务 22222 服务端口和 metrics 门路即可获取到指标数据,其中 22222 端口是 Dubbo 提供的服务质量,衰弱治理端口能够用过 QOS 配置进行批改。

查问到的 Dubbo 指标以命名:dubbo_type_action_unit_otherfun 的格局进行展示。

当然也会有用户间接应用 SpringBoot 治理端口的状况,针对这种场景 Dubbo 侧曾经做了主动适配间接应用 SpringBoot 导出普罗米修斯格局的指标数据即可,如下配置所示:

在拜访 SpringBoot 治理端口查问指标数据时就能够看到 SpringBoot 内置的一些指标和 Dubbo 提供的一些指标一起展现给用户了。

Dubbo 多维度指标体系 Prometheus 查问

后面间接通过 curl 命令拜访指标服务获取到的只是刹时的指标数据,对于指标数据咱们往往更须要的是时序化的向量数据,这时候就要借助普罗米修斯来进行在内部采集,存储 Dubbo 指标,对于传统利用部署在物理机和虚拟机的服务能够应用动态,基于文件或者基于自有 CMDB 零碎建设的指标发现服务,当然后续也能够应用 Dubbo Admin 为指标零碎提供的服务发现服务,对于部署在 K8s 中的零碎来说能够间接借助 K8s 反对的服务发现,接入 Prometheus 主动采集配置如下:

普罗米修斯中查问指标如下所示:

Dubbo 多维度指标体系 Grafana 展现

普罗米修斯侧重于采集指标和存储指标等场景,在展现指标这里绝对简陋,Grafana 提供了丰盛的指标面板,应用 Grafana 来建设指标大盘更直观,也更容易,能够看到上面的图片中提供了多维度的筛选如利用级、实例级,接口级等场景对服务数据进行查问。在指标监控大盘中也能够看到基于后面指标方法论的一些维度指标,比方流量、申请数、提早、谬误,饱和度等。另外也能够看到一些利用于实例信息比方 Dubbo 版本散布,实例散布等。

Dubbo 链路追踪门面建设

Agent 用户接入简略,然而动静批改字节码的模式来提供反对,危险较大,一个代理层 agent 只做一个 Dubbo 层的链路性能仿佛有点大材小用,Dubbo 定位为微服务 RPC 框架,做通用的链路门面绝对更好一些,业余的事件交给业余的人做,Dubbo 通过适配各大全链路零碎来让用户接入更简略。

Dubbo 链路追踪门面选型

业界比拟通用的 OpenTelemetry 链路追踪门面更偏向于规范对立的标准,反对各大厂商,同时也是与 CNCF 孵化的我的项目,Micrometer 的劣势在于与指标埋点所用依赖起源雷同,并且在 SpringBoot3 中也默认集成用户接入更为不便,另外 Micrometer 定位为可观测门面与 Dubbo 链路零碎建设的定位相符,其中也能够通过桥接的模式来桥接 OpenTelemetry。

Micrometer + OpenTelemetry Bridge:

Dubbo 链路追踪构造

Dubbo 通过内置链路过滤器在 RPC 申请中对链路数据进行采集,采集之后通过导出器将链路数据导出到各大厂商。

Dubbo 链路追踪接入

Dubob 链路追踪门面曾经公布,须要接入链路追踪零碎只须要简略的引入对应链路追踪的 starter 集成包而后进行单件的配置即可,更具体的接入手册能够参考文档和案例。[ 1]

在链路追踪配置中能够配置开关,采样率,导出器等配置。

最初链路追踪零碎往往也须要通过链路 id 与日志进行关联来剖析更具体的根因,这个时候就须要提前在日志配置中减少日志 MDC 打印的配置了,如下 traceId 和 spanId 的获取。

Dubbo 链路追踪 Zipkin

这里是 Dubbo 接入链路追踪 Zipkin 的展现,能够看到一些接口的性能与元数据。

Dubbo 链路追踪 Skywalking

这里是 Dubbo 接入链路追踪 Skywalking 的展现,通过链路 id 检索到的申请级别的链路剖析。

Dubbo 日志治理

Dubbo 日志治理异样

Dubbo 框架倒退多年,性能越来越丰盛,其中蕴含了与三大核心的交互,客户端服务端的交互,这种内外部交互的场景更容易呈现一些异样,如果遇到问题通过通过观察日志常常摸不着头脑,最初通过剖析代码来定位根因又是绝对头疼的事件。

遇到问题不晓得起因:

Dubbo 日志治理专家建议

如果仔细观察 Dubbo3.x 新版本打印出的日志就能够看到日志中会打印一个问题帮忙手册,当发现问题时候复制此链接在浏览器中关上就能够看到出现异常日志时候的专家建议,比方下图所示的问题起因排查步骤,随着 Dubbo 的倒退专家建议也会越来越具体,当让这个过程要建设的更为欠缺就须要用户、开发者一起参加进来,Dubbo 社区十分 Open,激励用户、开发者一起参加进来进行建设。

Dubbo 可观测性 - 稳定性实际

最初就是围绕整个可观测平台来做稳定性实际了,稳定性实际中通过观测服务健康状况、排查剖析零碎问题、最初疾速复原零碎。其中观测零碎异样的状况能够通过值班人员被动观测监控大盘,也能够将异样剖析告警,被动接管到告警邮件、IM、短信、电话等来及时发现问题,发现异常时能够借助指标来剖析聚合与非聚合的服务信息来定位异样地位,而后通过链路追踪零碎找到服务级别的异样进行剖析,最初也能够依据链路信息找到具体的日志来剖析异样上下文排除根因,排查的过程要借助整个观测平台以疾速复原零碎为指标通过流量隔离,服务降级等策略复原零碎缩小损失,预先能够借助可观测平台提供的这些长久化的信息来详细分析异样与法则来定位根因。

[1] 文档和案例

https://cn.dubbo.apache.org/zh-cn/overview/tasks/observabilit…

正文完
 0