logo
logo

使用 DeepFlow 开启 Redis 可观测性

林嘉炜 2022-12-29

我们已经有了 IngressMySQLDNS 的 Dashboard 和可观测方案,但在一个较大规模的架构中,通常还会有 Redis 作为应用的缓存层,而 Grafana 上的 Redis Dashboard 仅站在 Redis 的角度,但我们排查问题时,需要知道客户端与服务端之间的交互情况,甚至还需要知道是哪个应用造成的异常,在分析了这些需求之后,我们基于 DeepFlow 构建了一个高效无侵入的 Redis 监控面板,用以实现对 Redis 的可观测,让应用集群里每一个部件都实现可观测,以快速进行问题定位和排障。

前往我们的在线 Demo 可快速体验 Dashboard

0x0: Dashboard 介绍

为了方便使用,我们的 Dashboard 分成了两种类型,分别对应部署在 K8S 内的 Redis 服务以及进程形式部署的 Redis 服务,可以根据不同场景选择 Dashboard 使用。

其中,在 K8S 内的 Redis,可以使用如下变量:

①:使用 Cluster 选择集群,并根据 Redis Service 选择对应的服务,使用 Redis Wildcard 以通配符的形式筛选 Redis Service。

②:DeepFlow 可在多个位置采集数据,通过 Tap Side 来选择不同的数据统计位置,可以分别站在客户端角度服务端角度查看应用交互情况。位置点的详细说明,可参考文档

③:当我们已经定位到某个应用与 Redis 的交互有异常,则可以输入应用名称,并在 Log Analysis 面板中查看应用与服务之间的请求情况。

k8s variablesk8s variables

而部署在 vm 上的 Redis,则可通过如下变量快速找到目标宿主机上的服务:

④:选择 Redis 服务所在的主机。

⑤:如果使用了云厂商提供的云上 Redis,则可以输入目标 IP 找到 Redis 服务。

cloud host variablescloud host variables

0x1: Dashboard 使用

接下来,我们结合 Dashboard 的设计与实际案例分析,来完整体验一次异常定位与分析的全过程。

我们接收到前方报障某个请求时延高,我们通过 PodMap 分析,了解到应用的拓扑包含了 Redis 组件,同时发现应用本身的进程运行正常、CPU、内存消耗、磁盘 IO 都在正常范围内,于是我们开始排查 Redis 实例,首先,我们打开 Redis Dashboard 开始排查:

Overview: 进入总览,看到总请求数客户端与服务端错误及比例,在左下角我们可以看到请求时延分布情况,右边我们可以看到服务拓扑网络请求速率,帮助我们快速定位是否有错误发生是否有高时延请求是否有大请求占用带宽、以及查看当前请求量大小

OverviewOverview

Overview 来看,我们的服务没有发生错误,但是请求量比较大,在服务拓扑中我们得知这个集群里有三个 Redis 实例,左下角的时延分布可以看到最近一段时间里的请求时延处于较低水平,右侧的吞吐量仪表可以看到请求量也不高。

对服务的运行状态有个大概把握之后,查看 Request ,检查是否有暴增的请求量,并结合客户端分析,判断是否某个客户端在某个时间点突然产生了大量的请求

RequestRequest

经过 Request 排查之后,我们发现请求数偶有抖动,但基本维持在 20 qps 以下,这不算高并发场景,那我们继续从应用时延趋势来判断过去一段时间的请求时延变化:

Delay:通过 P90/P95/P99 时延分析,我们发现网络连接的平均时延均在100-300 ms 间波动,且最近几分钟在持续增长:

DelayDelay

Error:经过上面的分析,我们已经得知集群内的服务没有发生错误,但是有请求时延不稳定的情况发生,通过这个面板的超时 Top10,我们定位到了客户端应用:

ErrorError

Log Analysis:我们使用 client_for_Redis_Analysis 变量过滤客户端,检查具体的请求过程:

TopNTopN

通过 TopN Key 与 TopN Command 分析,我们发现,尽管 Auth 请求量大,但这是因为 GET 请求的 Key 不固定,所以显得 GET 请求少,从 TopN Command 分析发现 GET Key 就是最近一段时间的热点请求,这提示我们有两种可能:1. 可能发生了缓存雪崩,即大量缓存 Key 失效,导致应用不得不频繁查询数据库;2. 可能是大量的 GET 请求占用服务器资源,使得 Redis 实例响应延迟;

snowslidesnowslide

那究竟真实请求过程中发生了什么?我们通过 Distributed Traing ,查看所有大于 100 ms 的请求,并通过一次追踪来分析请求过程:

TracingTracing

通过这个链路,我们发现 Redis 服务的返回时间仅有3 ms,而应用本身则耗费500 ms,时延消耗在应用到 Redis 中间的网络上,由于这是一个简单的点对点请求,我们去排查这中间的网络问题即可。

同时,基于 TopN Command 我们还可以试图分析其他场景,如果发生了缓存击穿,我们可能会看到 TopN Command 同时是 GET 与 SET 请求,表明应用请求缓存失败,只能去数据库获取数据并尝试创建缓存,如图:

breakdownbreakdown

如果有这种现象,我们可以通过 SQL Monitoring 排查,判断请求是否透过了缓存层,直接打到了后端存储上,从而定位到异常原因。

0x2: 什么是 DeepFlow

DeepFlow 是云杉网络开发的一款可观测性产品,旨在为复杂的云基础设施及云原生应用提供深度可观测性。DeepFlow 基于 eBPF 实现了应用性能指标、分布式追踪、持续性能剖析等观测信号的零侵扰Zero Code)采集,并结合智能标签SmartEncoding)技术实现了所有观测信号的全栈Full Stack)关联和高效存取。使用 DeepFlow,可以让云原生应用自动具有深度可观测性,从而消除开发者不断插桩的沉重负担,并为 DevOps/SRE 团队提供从代码到基础设施的监控及诊断能力。

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

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