使用 DeepFlow 开启 Dubbo 可观测性

树欲静而风不止
发布于 2023-4-18 15:35
浏览
0收藏

微服务架构已经是后端架构领域老生常谈的话题了,微服务治理、发现等技术已经在业界有了很多成熟的解决方案,Dubbo 作为一个社区认可度较高的微服务治理框架也在这个方面颇有建树。但是在微服务架构中,服务的数量和复杂度都远超过之前的单体架构,如何保证服务的稳定和高效运行呢?这时候,可观测性就显得尤为重要。

我们都知道 Dubbo 自身有指标监控[1],但仅聚焦在应用代码层面,同时指标只是可观测性主要的数据之一,我们还需要联合日志、追踪等数据共同去观测服务,才能去多维度保证服务的稳定性和可靠性,而 DeepFlow 具备在应用、网络及系统等多个层面采集指标、日志及追踪等数据的能力,同时可基于 AutoTagging 能力,为所有的数据注入上统一的标签,解决数据孤岛的问题。

所以我们基于 DeepFlow 构建了一个针对 Dubbo 协议的可观测性 Dashboard,分别提供在应用、网络及系统三个层面的监控视角,通过分析时延、错误及访问量,可快速定位突发性能瓶颈和异常流量,帮助我们快速排查故障。

01|Dashboard 概览

进入 Dashboard,我们可以通过变量切换来查看不同集群、不同命名空间下的应用服务情况。通过切换 ​​Tap Side​​ 变量,我们可以基于应用、网络及系统三个不同视角进行分析。


使用 DeepFlow 开启 Dubbo 可观测性-鸿蒙开发者社区

Variables


首先,我们在 Overview 通过总请求量客户端与服务端的异常服务拓扑查看集群内服务的概况,如果微服务规模较大,有助于先对集群中的服务运行状况有个大概把握。


使用 DeepFlow 开启 Dubbo 可观测性-鸿蒙开发者社区

Overview


接下来我们有网络层时延应用服务时延,当出现故障时,可以快速判断是哪个服务发生了异常,并结合时延查看高时延发生在网络还是应用层。


使用 DeepFlow 开启 Dubbo 可观测性-鸿蒙开发者社区

Overview-时延

02|排障与分析

对集群内应用服务有个大概的把握之后,我们可以接着看具体不同面板视角下的分析:

Connection:查看集群中 Consumer 视角以及 Provider 视角对比分析 RequestResponse 的请求、响应速率,我们通过两端请求量与响应量对比判断连接情况:如果请求明显大于响应,说明服务端异常,大量消息无法回复。此时可以结合服务拓扑,快速定位哪两个应用之间发生了异常


使用 DeepFlow 开启 Dubbo 可观测性-鸿蒙开发者社区

Connections


Delay:找到目标应用之后,我们还可以继续分析时延发生的过程,通过基于ProviderConsumer 两端视角的时延序列分析 P90/P95/P99 指标,我们可以判断故障对应用集群的影响程度大小:如果发生故障时,P9x 指标维持在一个较低值,说明有 9x%的用户保证了正常使用,准确的判断有助于我们做出优秀的决策。根据高时延发生的时间点,我们可以结合基础设施、应用的变更情况判断是否某次变更引起了异常。


使用 DeepFlow 开启 Dubbo 可观测性-鸿蒙开发者社区

Delay


Error:掌握了连接时延信息之后,我们再来分析应用服务间异常的时序,这样可以更清晰地分析是否发生错误导致服务无法响应,从而产生了高时延,让我们能够快速定位具体异常位置。


使用 DeepFlow 开启 Dubbo 可观测性-鸿蒙开发者社区

Error


通过上方的错误分析,我们发现在这个时间段 Provider 有大量 Error ,根据错误码与错误异常汇总结合,发现错误为 ​​BAD_RESPONSE​​ 服务端异常,结合 Consumer 视角的错误概览,我们可以明确断定异常发生在 ​​web-shop​​​ 应用与 ​​svc-order​​​ 的调用之间,且就在 ​​svc-order​​ 内部发生了大量错误。


Request Log Analysis:最后我们根据请求调用日志分析访问量大小与发生时间点,对 TopN 访问量结合服务访问量时延分析,发现 ​​OrderService​​​ 内仅有 ​​createOrder​​ 一个函数有大量请求。


使用 DeepFlow 开启 Dubbo 可观测性-鸿蒙开发者社区

Request Log


对高时延请求(>100ms)的调用链分析,快速定位应用、网络及系统的瓶颈问题,找到发生异常的具体位置。


使用 DeepFlow 开启 Dubbo 可观测性-鸿蒙开发者社区

Distributed Tracing


经过时延异常调用日志分析,我们知道这些大量的错误就是发生在 ​​createOrder​​ 这个函数内,由于错误数调用次数不对等,我们还可以断定这个错误是由某个业务条件错误而引发的,我们只需要直接查看这个函数修改代码并解决问题即可。


最后有个彩蛋:在文章的开头,我们提过 Dubbo 有指标监控[2],那我们是否可以将 Dubbo 提供的指标与我们的可观测面板结合起来呢?当然!我们已经支持了集成 Prometheus[3],而且我们也支持 PromQL 查询,请期待我们即将推出的基于 PromQL 搭建指标监控的功能,在 DeepFlow 体验丝滑的可观测能力。

03|什么是 DeepFlow

DeepFlow[4] 是一款开源的高度自动化的可观测性平台,是为云原生应用开发者建设可观测性能力而量身打造的全栈、全链路、高性能数据引擎。DeepFlow 使用 eBPF、WASM、OpenTelemetry 等新技术,创新的实现了 AutoTracing、AutoMetrics、AutoTagging、SmartEncoding 等核心机制,帮助开发者提升埋点插码的自动化水平,降低可观测性平台的运维复杂度。利用 DeepFlow 的可编程能力和开放接口,开发者可以快速将其融入到自己的可观测性技术栈中。


GitHub 地址:​​https://github.com/deepflowio/deepflow​


访问 DeepFlow Demo[5],体验高度自动化的可观测性新时代。

参考资料

[1] 指标监控: ​​https://cn.dubbo.apache.org/zh-cn/overview/reference/metrics/standard_metrics/​

[2] 指标监控: ​​https://cn.dubbo.apache.org/zh-cn/overview/reference/metrics/standard_metrics/​

[3] 集成 Prometheus: ​​https://deepflow.io/docs/zh/agent-integration/metrics/prometheus/​

[4] DeepFlow: ​​https://github.com/deepflowio/deepflow​

[5] DeepFlow Demo: ​​https://deepflow.yunshan.net/docs/zh/install/overview/​

分类
收藏
回复
举报
回复
    相关推荐