作者：张城(元乙)，张宝龙(众学)
线上告警响了。frontend 接口 P95 飙到 1800ms，顺着链路往下追——Redis 连接数在波动，RDS 活跃会话在涨——线索逐渐收拢，线索慢慢收拢到数据库层。到这一步，再多开几个监控面板也没用，你要的是能对着数据库做深度诊断的东西。
问题不在监控数据不够多——日志服务 SLS、应用监控 APM、可视化 Grafana，什么都有。真正缺的是把跨层数据串成因果链的能力。STAROps 擅长全栈关联分析，把排查范围从多个组件收拢到少数嫌疑对象。可一旦证据指向数据库层，就需要一个能基于真实指标下钻的数据库诊断搭档。瑶池 Agent Skill（产品标识 alibabacloud-yaochi-agent，以下简称瑶池 Agent）填补的就是这个位置。接下来，我们先讲清楚跨层根因诊断的难点在哪，再用三个真实案例走一遍：一个 RDS、两个 Redis，难度从单实例诊断（L3）爬到跨层根因分析（L4）。
跨层根因诊断的难点在哪里
STAROps 拉通应用、中间件、基础设施的指标、日志和链路，在全栈层面做关联分析。这是它的强项。可范围一收到数据库层，问题就换了性质。“Redis 异常”不够——你需要知道是 Lua 脚本阻塞了单线程，还是热点 Key 打满了 CPU。“RDS 会话升高”也不够——你需要知道是哪张表缺了哪个索引，哪条 SQL 在全表扫描。这些是数据库诊断的专业领域，不是通用可观测平台覆盖的范围。瑶池 Agent 覆盖 RDS、PolarDB、Tair（兼容 Redis）、MongoDB、Lindorm 、AnalyticDB、ClickHouse、SelectDB 等全产品覆盖，能基于真实指标做实例诊断和根因分析。把它做成 Skill 挂到 STAROps 数字员工上，一条证据链就能从应用层一路拉到数据库里的具体命令。
数字员工是 STAROps 中可挂载 Skill 的 AI 运维助手。给数字员工挂上瑶池 Agent，它就具备了数据库层的专业诊断能力。瑶池 Agent 能做的不止故障诊断。实例诊断之外，它还覆盖规格选型、内核参数变更评估、成本分析、表建模分析、内核参数释义、备份状态查询等日常场景。
frontend 服务链与告警传播路径
后文的跨层场景都涉及同一个电商应用。以下是从云监控 2.0 提取的 frontend 服务调用链，也是告警传播的实际路径：
frontend 作为入口接收用户请求，通过 frontend-proxy 将请求分发到 wishlist、promotion 等业务服务，这些服务再调用 Redis（Tair，下文统称 Redis）和 RDS 等数据存储。当 Redis 出现单线程阻塞时，最先超时的是下游这些业务服务，错误顺着 wishlist/promotion → frontend-proxy → frontend 逐层向上传播，最终表现为接口响应变慢告警。
以下场景中展示的 Agent 回复是最终诊断结论。在实际使用过程中，Agent 会先显示分析进度（正在查询指标、正在分析慢命令……），单实例诊断通常几分钟内完成，跨层根因分析约需 5-10 分钟。如果问题信息不够完整，Agent 可能会追问补充信息。
场景一：活跃会话异常升高，根因是一个缺失的索引
提问
分析在 2026-07-18T12:21:30+08:00 → 2026-07-18T12:38:30+08:00 期间，RDS 实例 rm-j6c3l32c730ti37ur 活跃会话数异常升高的原因。
Agent 回复
数字员工识别到问题明确指向 RDS 数据库层，调用瑶池 Agent 进行实例诊断。
在指定时间窗口内，RDS 实例活跃会话数从正常水平急剧上升至峰值，持续约 17 分钟后回落。经分析，告警时段内大量查询集中在inventory表，均带有对product_id字段的关联子查询。客户端来源为 IP 10.0.20.210，共 540 个并发连接同时执行这些查询。由于inventory表缺少 product_id 索引，每次查询均执行全表扫描，在高并发场景下导致活跃会话堆积。 根因：inventory表缺少product_id索引，540 个并发高代价关联子查询打满 RDS 实例。建议：为inventory表添加product_id索引。
小结
这是一个 L3 级诊断——告警直接指向单个 RDS 实例，不涉及跨层传播。瑶池 Agent 的诊断路径为：确认指标异常 → 分析 SQL 分布 → 追溯客户端来源（IP 10.0.20.210，540 并发）→ 定位缺失索引（inventory.product_id）。从“活跃会话升高”到“哪张表缺了哪个索引”，诊断精度足够直接指导修复。可以直接在 RDS 控制台执行修复操作，进行索引变更。
点击下方链接，查看操作视频：https://mp.weixin.qq.com/s/OEsDGniBL_NLG6_OFOQw6g
场景二：告警在 frontend，根因在 Redis 的 Lua 脚本里
提问
2026-08-10 10:31 至 10:50 期间发生了 frontend 接口响应慢告警，帮我诊断一下问题根因，并提出解决方案。
Agent 回复
数字员工首先启动 STAROps 全栈关联分析，通过时间线比对、拓扑追踪和变更记录交叉，将排查范围从 frontend 层逐步收拢到 Redis 层。随后调用瑶池 Agent 在 Redis 层做深度诊断。
进入 Redis 深度诊断后，发现以下关键指标：CPU 打满（98%）但吞吐量反降（QPS 从 1200 跌至 180），表明有操作阻塞了 Redis 的处理线程。慢命令日志分析定位到阻塞源：一个包含大量计算逻辑的 Lua 脚本独占了 Redis 单线程，且在告警时段内反复发作两次。级联传播路径：Redis 单线程冻结 → promotion 和 wishlist 服务 SocketTimeout → frontend-proxy 返回超时错误 → frontend 接口响应变慢。 根因：托管 Redis 实例的单线程被包含重计算逻辑的 Lua 慢命令独占，且反复发作两次。建议：重构 Lua 脚本，避免在脚本体中做重计算，考虑用 pipeline 拆批。
小结
这是一个 L4 级诊断——告警在 frontend 层触发，根因在 Redis 层，涉及跨层传播。这一次的诊断路径是这样的：frontend 告警 → STAROps 全栈关联分析 → 范围缩小到 Redis → 瑶池 Agent Redis 指标分析 → 慢命令日志定位 Lua 脚本阻塞 → 级联传播确认（Redis → 微服务 → frontend）。诊断精度具体到命令类型和行为特征，而不只是回答“Redis 有性能问题”。
点击下方链接，查看操作视频：https://mp.weixin.qq.com/s/OEsDGniBL_NLG6_OFOQw6g
场景三：frontend 响应时间突增，根因在 Redis 的 EVAL 命令
提问
分析 2026-08-10 06:19 至 06:25 期间，frontend 响应时间突增告警的原因。
Agent 回复
与场景二相同的排查路径：STAROps 全栈关联分析将范围指向 Redis 层，瑶池 Agent 接手做 Redis 深度诊断。
Redis 实例指标显示 CPU 接近饱和、QPS 骤降，与场景二的指标模式相似。慢命令日志分析定位到阻塞源：EVAL 命令。这些命令包含大量内联逻辑，直接在 Redis 内执行复杂计算，单线程在执行期间被完全占用，其他命令排队等待。 根因：Redis 单线程被 EVAL 慢命令独占，所有命令排队。建议：定位并阻断发起异常 EVAL 调用的客户端来源，优化脚本逻辑避免大规模循环。
小结
同样是 L4 级跨层 RCA，同样的“告警在 frontend、根因在 Redis”传播链，指标表现也几乎一致。但成因细节不同：场景二是业务常驻 Lua 脚本自身的重计算问题，修复方向是重构脚本；场景三是异常来源发起的临时 EVAL 内联脚本（EVAL 正是 Redis 执行内联 Lua 脚本的命令），修复方向是阻断异常来源、把计算逻辑移出 Redis。同样的症状，处置路径并不相同。
点击下方链接，查看操作视频：https://mp.weixin.qq.com/s/OEsDGniBL_NLG6_OFOQw6g
对比：同症不同因
把场景二和场景三放在一起看：
同一个症状，同一个中间件，根因机制都是“慢命令独占单线程”——但具体成因和处置动作不同。这正是把诊断精度做到命令级的价值：它能把结论落到“哪条命令、从哪来、该怎么处理”，而不是仅仅回答“Redis 有性能问题”。
适用范围
当前瑶池 Agent 支持以下阿里云数据库产品：RDS、PolarDB、Tair（兼容 Redis）、MongoDB、Lindorm、AnalyticDB、ClickHouse、SelectDB。不支持自建数据库和非阿里云数据库。
当证据不足以给出确定性结论时，Agent 会标注置信度并列出可能的排查方向，而非强行给出根因。所以真正动手执行修复前，最好由 DBA 或研发负责人复核诊断结论。
快速开始
- 登录 STAROps 控制台（ https://starops.console.aliyun.com/ ），创建一个数字员工。
- 在「技能中心 → 官方推荐」中搜索
alibabacloud-yaochi-agent并挂载。 - 在对话框里提问。单实例诊断通常几分钟内返回结果，跨层根因分析耗时略长（本文场景约 5-10 分钟）。
可以使用以下模板构造你的 prompt，替换方括号中的内容：
分析在 [开始时间] 至 [结束时间] 期间，[实例类型：RDS/Redis/Tair/MongoDB/PolarDB] 实例 [实例 ID] [异常现象描述] 的原因
例如：“分析在 2026-08-10 10:00 至 11:00 期间，Redis 实例 r-xxxxx CPU 使用率异常升高的原因”。用自然语言描述你遇到的问题及问题发生的时间，如果你不确定具体的实例 ID，可以描述应用名称和异常现象，Agent 会尝试关联底层数据库实例。
瑶池 Agent 把数据库层的诊断精度从“某个中间件有问题”提升到“具体是哪条命令、哪个索引引发的问题”，STAROps 则负责把跨层证据串成完整的因果链。两者配合，SRE 和 DBA 可以用同一套工具完成从告警到修复的全链路排查。对于涉及跨层传播的复杂故障，这个组合值得一试。
目前 STARops 提供新用户首月 1 万积分以及每月 2500 积分免费额度。立即体验 STAROps 吧，把你手里最近的一个线上故障告诉它，看看是否能真的帮你解决问题，追到具体是哪条命令、从哪来、该怎么修。
