开箱即用的 eBPF 可观测性：中国移动磐基 PaaS 平台案例

在上一篇文章中国移动磐基PaaS平台基于eBPF的应用可观测性建设实践中分享了中国移动磐基 PaaS 平台如何将 eBPF 数据与现有的可观测数据整合，提供了开箱即用的应用可观测性，全栈无盲点的调用链追踪等能力。本篇文章将主要介绍开箱即用的可观测性能力如何快速实现故障定界、高效发现性能隐患。

0x0: 背景介绍

磐基 PaaS 平台的可观测性能力已经在多个省份推广试运行了，下面将详细讲述如何利用开箱即用的能力，如何发现自身异常及潜在风险的。磐基 PaaS 平台共分为六大核心能力：

磐基 PaaS 平台

• PaaS 平台门户：集成平台能力，为平台用户提供一站式运营管理服务
• 弹性计算平台：为上层应用提供标准化运行环境，南向对接 IaaS 层
• 微服务体系：通过服务治理形成分布式架构基础
• 组件管理体系：提供组件自动化部署能力
• 运营运维体系：提供监控、告警、推送、巡检、日志、调用链、可观测等日常运维能力
• 持续交付体系：为应用上云提供一站式持续交付管理

磐基 PaaS 平台自身业务模块都已经微服务化，都部署在 K8s 平台上，eBPF 开箱即用的可观测性能力立马可用。

0x1: 案例分析

以下将介绍一些比较典型的分析案例。将充分利用 DeepFlow 社区目前已经提供的 Dashboard 来排障：

• Step 1: Application - K8s Pod Map，过滤服务，根据 RED（request/error/delay）指标分析存在异常的路径及时间范围。
• Step 2: Application - Request Log，过滤路径与时间范围，得到路径所有调用的详情信息，包含客户端、服务端、请求域名、请求URI、响应码、响应状态、响应时延等信息。获取高时延调用或异常调用
• Step 3: Distributed Tracing，过滤调用与时间范围，对高时延调用或异常调用发起分布式追踪，根据火焰图分析时延瓶颈以及异常根因

整个分析过程，需要在多个 Dashboard 流转，涉及到各种搜索条件的切换，使用起来还是有一些麻烦。将此信息与 DeepFlow 社区同步后，社区在此基础上推出了仅查看一个 Dashboard、只需两三步点击操作的开箱即用 Dashboard。

业务页面空白 - 服务注册中心变更

早上运维同事发现磐基-巡检页面一直未有数据刷新，页面空白，F12 也未报任何错误。

报障截图

查看 Application - K8s Pod Map，发现很多服务访问 nacos-c* 都存在异常（其中也包含巡检功能）：

Application - K8s Pod Map

在 Application-Request Log 页面看到有不少调用 nacos 服务报 403 (Forbidden) 异常：

Application-Request Log

在 Distributed Tracing 的中对存在 403 异常的 /nacos/*/*/*/*er 与 /nacos/*/*/*/l*?u*=nacos 调用分别发起追踪，发现此异常都是 nacos-c* 服务本身返回：

Distributed Tracing

Distributed Tracing

总结：找巡检功能的开发反馈了此问题，确认 Nacos 存在一些问题影响了功能。安全组在漏洞扫描的过程中发现当前 Nacos 版本存在漏洞，负责 Nacos 的研发组对其镜像进行了更新，需要每一个使用 Nacos 服务的业务方在代码层面都增加对应的加密配置，但未及时通知其他研发组，影响了业务正常运行。通过eBPF监控告警，能够发现问题根因，及时处理。

业务潜在性能问题 - Jedis 未升级

日常巡检的过程中，利用 Application-K8s Pod Map 面板发现 e*-k*-a*服务访问 redis 服务存在大概 30% 左右的异常：

Application-K8s Pod Map

结合 Application - Request Log 发现都是 HELLO 3 命令的请求（Redis 客户端希望使用 RESP3 (Redis Serialization Protocol) 来进行通信），但服务端返回了 -ERR unknown command `HELLO 。从错误可以推测，推测目前 Redis 服务端版本低于客户端版本，不支持 Hello 命令（Hello 命令在 Redis version 6.0.0 以后才支持）：

Application - Request Log

对异常的调用发起 Distributed Tracing 也可看出确实是redis服务端返回的 error：

Distributed Tracing

结论：经研发测确认，其弹性计算的部分业务中使用的 Jedis 客户端版本 v3.6.1 高于 Redis 服务端 v5.0.14 版本，导致 Hello 命令报错。分析过程中发现，有部分 Jedis 客户端版本使用的 v4.3.2 版本却未报错，进一步调查发现原来 Jedis 在 v3 版本上刚支持 Redis v6 还存在 bug，会不停的发送 Hello 命令，升级到 v4 后，如果发现 Redis 服务端是低版本，则会改为发送 AUTH 命令。为规避此报错，与存在报错的业务方进行了统一沟通，将 Jedis 统一升级到 v4.3.2 版本，方便统一管理。

故障排查中 Redis 服务团队也更深入的了解了 Redis v6 新特性，Redis v6版本引入了一系列新特性和改进，增强的数据类型支持、支持服务端主动向客户端推送消息、更好的错误处理等能力。为了更好的满足业务方的需求，目前 Redis 服务团队已经在排期对 Redis 服务进行升级，eBPF 的零侵扰可观测性不止发现了隐患，还帮助进行了架构优化。

业务高峰期不可用 - 服务 503 异常

业务方反馈磐基平台的监控中心偶现访问异常（ 503 Service Unavailable），运维团队并未主动挂过 503。业务服务调用关系复杂，分析日志多日也并未找到具体的原因，测试环境也一直未复现，问题悬住。最后利用基于 eBPF 的开箱即用可观测性能力，分钟级定位到了问题服务。

503 截图

利用 Application-K8s Pod Map 发现 100...* 访问 m*--c 服务存在 25% 的服务端异常情况。在 Application - Request Log 面板分析，调用 /web*-p*-c*/*/*/h* 接口存在 503 异常：

Application-K8s Pod Map

利用 Distributed Tracing 面板，对异常调用发起追踪：

Distributed Tracing

Distributed Tracing

总结：通过火焰图可知，100...* 调用 m*--c 服务 /web*-p*-c*/*/*/h* 接口，然后 m*--c 服务又调用了 m*-a* 服务的 /?c*=1&e*=0&d*=w* 接口，不过 m-a 返回都是正常的，是 m*--c 服务返回了 503 异常**，经过研发分析，每天早上上班后大家都会集中先查看一波查看监控数据，从而带来了一波高峰数据。

整个运营运维业务一直在快速迭代发布，还未来得及分析整个链路的瓶颈点，因此生产部署的微服务 Pod 的副本数都一样，通过早上高峰的数据，结合 eBPF 的 RED 指标和调用链追踪功能，快速的找到了整个运营运维业务的服务瓶颈点（因调用处理不过来，会导致偶现的返回 503 异常）。与业务运维的同事沟通此问题后，他们给 m*--c 在最大副本数在其他微服务的基础上增加了 1 倍（增加的副本数的数目，也是根据线上的 RED 指标最终调整得到的最优解）。

访问门户时延高 - 业务性能瓶颈

在磐基 PaaS 平台中，客户端访问门户的路径构成异常复杂，涵盖了从物理网络层面到高级应用层的多个环节。这一路径依次经过物理网络层的直接连接、基于云的L4层负载均衡器、云原生的L7层网关（Istio-Ingress 实现）、以及 Kubernetes 环境下的 API 网关（APISIX），最终到达门户业务所依赖的微服务集群。在面对潜在的时延增加情况时，要精确地追踪到具体的瓶颈点变得尤为棘手。目前 APM 已经覆盖了门户业务对应的微服务，对于客户端访问路径中的前置环节，例如云四层负载均衡器、云七层网关以及 Kubernetes 的 API 网关（如APISIX）—APM 均未能覆盖到。

目前磐基提供的 eBPF 的可观测性能力覆盖了整个 K8s 环境，无需任何插码完全自动化的追踪 APISIX 与后端门户服务（云环境覆盖 eBPF 的可观测性能力也能实现完整追踪），快速的定位客户端访问门户， APSIX 慢还是后端服务慢？K8s 网络慢还是云网络慢？门户服务慢还是 Redis 慢？

分布式追踪示意图

告警发现门户认证服务存在响应时延超过 1s 的情况（后端服务的响应时延的取决于具体的应用场景，因为门户相对为低敏感度的业务，所以响应时延阈值设置的为 1s），利用 Application-K8s Pod Map 面板可以看出来，apisix 访问门户认证偶发的时延高的情况（> 1s）：

Application-K8s Pod Map

在 Distributed Tracing 面板可以查看是访问 apisix.apisix:*/api/*/t* 时延高，对时延高的调用发起追踪，分析整个追踪过程，如下：

• 调用由 100...* 服务器通过 curl 命令触发了 /apisix/*/*/s* 调用，时延持续 1.14s
• 调用转发到 apisix 服务对应的一个 pod 的 openresty 进程，时延持续 1.14s
• 再由 apisix 的 openresty 进程对门户认证服务发起 /api/*/t* 请求，时延持续 1.14s
• 门户认证服务又对门户服务端发起 /p*s/l*/c* 的请求，时延持续 1.14s
• 门户服务端又对 redis服务的 redis-s* 进程发起了 GET l* 请求，redis-s 进程在 52us 就回复了请求*

Distributed Tracing

结论：此时从火焰图分析，门户服务端对 Redis 服务发起请求后，Redis 服务快速响应并返回了，而门户服务端大概 1.13s 的时间才往上返回结果，因此可快速推断时延瓶颈在门户服务端自身（图中蓝色 Span 对应的服务），将此观测结果反馈给研发同事，需要优化门户服务端的瓶颈问题。利用eBPF 开箱即用的可观测性能力可完全自动化零插码的形式覆盖 APM 工具未能插码的点，将 API 网关、Redis 中间件、K8s 网络与业务微服务通过自动化追踪全关联起来，不仅可以大幅提高问题解决的效率，也能更好地理解系统的运行状况。

0x2: 总结

通过深入分析和应用 eBPF 开箱即用的可观测性能力在中国移动磐基PaaS平台的实战案例，包括服务间调用异常、资源访问延迟、服务配置更新漏洞等多方面的问题，我们得以见识到开箱即用的可观测性技术在实际应用中的带来的便捷性。这些技术不仅能够帮助技术团队迅速识别并解决潜在的服务问题，还能够优化系统性能，确保业务稳定运行，从而提升用户体验。磐基PaaS平台的六大核心能力，结合eBPF的先进可观测性技术，为企业提供了一个强有力的支持，使其在面对复杂的生产环境和不断变化的业务需求时，能够更加自信和从容。