错误率从 1% 爬到 10% 还不知道怪谁：STAROps 先巡日志里的新变化

错误率从 1% 爬到 10% 还不知道怪谁：STAROps 先巡日志里的新变化

阿里云云原生社区在 2026 年 10 月 23 日写了 STAROps（阿里云把日志、指标、链路和智能体串成巡检与排查的可观测方案）怎样在没人告警时看日志。文章不把「查日志」当成出事后的回放，而是写成一套还在跑的巡检：先压缩日志，再让智能体决定往下钻哪一层，最后只在问题变了的时候通知人。文中的数字来自他们对自己 Agent Thread 日志的几轮真实巡检，不是一份公开评测集上的平均分。

规则能抓住的，和规则还没写出来的

常见用法是出事之后才打开日志：接口报错就搜请求号，容器重启就看退出前的堆栈，用户说支付失败就拿账号和订单号追调用链。到这一步，故障已经发生，日志只负责把现场拼回来。

日志里还有没触发告警、也没人想到要搜的变化：新版本偶尔冒出没见过的异常栈；总错误率看起来正常，但一个地域在变差；一类高风险操作第一次出现在授权窗口之外。这些信号单独看不起眼，放着不管，可能就是下一次大面积故障的起点。

作者把问题和查找方式分成四格：

• 已知的已知。 知道哪个错误码代表失败、哪个阈值要盯。一条 SQL 或一条告警规则可以一直盯着。
• 已知的未知。 知道出事了，但不知道集中在哪。错误率从 1% 爬到 10%，一时说不清是哪个服务、接口、版本或租户。
• 未知的已知。 团队心里有数，系统不知道。例如 BizException(code=USER_CANCEL) 是正常取消，/healthz 上的 404 可以忽略，ci-bot 在凌晨轮换密钥是授权操作。没有这些背景，系统会把它们都报成问题。
• 未知的未知。 事先没定义问题，也不知道搜什么。可能是新的日志模式、从未同时出现的字段组合，或刚偏离常态的长尾维度。

智能日志巡检不承诺找出每一个未知问题。它做的是把搜索面拉开：在已有检查之外，继续看新模式、分布偏移、数值长尾和互相矛盾的信号，把值得查的候选尽量提前交出来。

巡检怎么拆：先压缩，再规划，再跨源

把巡检交给智能体时，难点是在大量日志里把异常找稳，同时留下人能复核的证据。上下文装不下整个时间窗的每一行。随便抽样会漏掉低频异常，几条扎眼的样本又会带偏判断。用关键词和固定 SQL 预过滤，只能覆盖已经知道的错误。

STAROps 把工作拆成相连的几段：

1. SLS（Simple Log Service，阿里云日志服务）先在数据侧做宽分析。
2. LogReduce 和维度下钻这两个 AI 算子压缩搜索空间。
3. 智能体根据每一步的结果动态改调查路径。
4. 确认过的问题进入观察名单，持续跟踪。
5. 再用代码、指标、链路、Skill（领域技能）和 UModel（UnifiedModel，把实体和数据放在一张关系图里的统一可观测模型）跨实体追查。

LogReduce 从已索引文本里抽出稳定常量和动态变量，把相似日志收成模式（日志模板），再比较不同时间窗的模式次数和变量分布，找出新增、消失或突增的模式。也可以按服务或模块聚类，让当前窗口直接对比昨天同时段、上周同时段，或发布前的窗口。连接池耗尽不必事先写成关键词，只要它形成新模式，巡检仍有机会把它抬出来。

维度下钻先建当前窗口和历史基线，再在服务、地域、版本、操作及其组合里找偏离最大、贡献最大的范围，并给出实际值、基线值和差值。流量最大的维度不一定是导致异常的那个；单看一个字段可能什么都没有，异常只出现在 project-a 加某个 LogStore 这种组合上。两个算子负责发现变化和缩小范围，它们自己都不是根因结论。

调查路径不是写死的。第一次跑任务时，STAROps 按日志结构、可用历史和巡检目标生成初始计划。稳定检查之后按这个计划重复，当轮怎么查则由智能体看证据决定。失败率上升时，先核对分母和历史基线，再下钻贡献最大的范围。从新模式出发时，再看它是不是集中在某个版本、地域或上游依赖。字段解释不了，就改去聚类消息正文。怀疑发布，就查版本和变更。要判断用户影响，就去请求、链路或业务实体。

算子返回的第一层候选只是入口。智能体要核对当前窗口和历史基线能不能比，对领先候选再查一次真实差值，再把高贡献范围当成下一轮查询条件。可能先钉住 project-a，再只在这个项目里比 LogStore 和版本。每一步的结果决定下一步查什么，查询链留在 Finding（一条可连续跟踪的问题记录）里。

每一轮还留一小段有边界的自主探索。已有检查都报正常时，智能体仍挑一个方向继续看：解释不了的日志、新字段、模式变化、数值长尾或矛盾信号。证据已经能解释问题、再查没有明显增益、或数据确实不够时就停，并写明结论或数据缺口。

一次巡检发现的问题不该停在一条孤立通知上。Finding 保存稳定身份、当前证据、影响范围和状态变化。同一类问题再次出现时，挂到已有 Finding 上，并区分它是持续、变重、复发，还是影响在缩小。新异常、恶化、复发或范围明显扩大，可以发到钉钉或飞书；没变化的问题留在报告里，不在每个周期打断值班的人。

启动任务只需要写清业务范围、运行周期、优先级和通知方式。后面靠真实反馈改。如果某类取消是正常业务，就告诉智能体。健康检查、压测流量或授权操作不需要关注，就补上适用范围。STAROps 把确认过的业务语义和每次判断的理由记成 Learning，用来调整后面的巡检。人确认过的未知问题也会变成可复用经验：某类异常栈如果已经被确认和连接池配置有关，下次先看是不是同一个问题，再看是不是在变重。日志字段、业务范围或优先级变了，巡检计划会重新评估；只有验证过的调整才变成稳定检查。

自定义探针可以只盯结算窗口里的资金差异、授权时段外的高风险操作，或某一类业务错误码。它们和 LogReduce、维度下钻、智能体自己的探索一起跑。新的 Java 异常栈出现后，代码侧的 MCP（Model Context Protocol，让智能体调用外部工具的协议）服务可以取回对应文件、提交和已发布版本。数据库连接超时出现后，专门的排查 Skill 可以继续看连接池、慢 SQL 和数据库指标。单个 LogStore 解释不了时，智能体用 UModel 找到相关实体和数据在哪，再用 Skill 查指标、链路、变更或代码。原始数据不必搬进同一个存储。

拿自己的 Agent 日志跑出来的几轮结果

健康的服务指标不等于业务可靠。STAROps 里一个任务会经过入口网关、认证、AgentRuntime、Sandbox 和工具服务，任何一段出问题都可能让任务失败、变慢或结果不完整。他们把自己的 Agent Thread 日志放进例行巡检，按小时跑，持续看请求量、完成状态、时延、Agent 分布和用户分布。发现新的错误模式或关键指标变差时，再顺着 Agent 和 UModel 追到大模型、工具和网关，确认影响了什么、发生在哪。

第一轮发现日志条数比上一窗口增长 147%，增长集中在一次批任务执行时段。报告里有当前窗口、对比窗口、实际查询，以及对不确定性的说明。就现有证据看，这次增长更像调度行为变了，而不是直接伤到服务健康。结果有依据，但和 STAROps 自己的业务还不够贴：只看记录数和通用字段，看不出变化来自哪个入口、哪些用户，以及是否影响真实任务。

他们直接补了语义：skill 表示哪一个入口 Skill 处理了请求，employeeId 表示请求来自哪个用户，两个字段都要盯。智能体把巡检计划改成包含 Skill 的请求分布、完成状态、性能，用户请求分布，以及用户和 Skill 的交叉分析。检查项从 6 项加到 11 项，下一轮自动跑这些新检查。

更新后的一轮里，整体 P90 时延从 94 秒升到 171 秒，看起来像明显变慢。按 Skill 拆开之后，没有单个 Skill 的 P90 变差；变的是流量构成，慢请求占比更高的 Skill 在当前窗口里占得更多。最终报告把它判成流量构成变化，而不是服务性能下降。

巡检按小时跑，通知不必每小时发。触发条件写成错误率高于 5%，或出现新的重要发现。STAROps 再往下拆：只有新错误类型出现、某个 Skill 的未完成率明显偏高、P90 明显变差，或错误集中在少数用户时，才推到名为 STAROps Alerts 的钉钉机器人。后来一轮里，未完成率从上一窗口的 1.01% 升到 6.2%，过了通知阈值。机器人收到的内容带有按 Skill 和按用户的错误分布、性能指标和初步判断，问题已经收到某一时段、某一条 Skill 路径上聚在一起的 context canceled。没触发的巡检仍出报告，但不反复打断人。

跨源的一轮里，Thread 上的失败比仍是 0%，关联的大模型调用数据里却聚着 429 限流；一部分网关 SSE 统计和 /metrics 请求已被标成已知噪声。最终报告把证据分成 P1 正常、P2 异常、P3 已知噪声，而不是把所有变红的指标堆在一起。

这条链路的顺序是：从一个 LogStore 开始；第一轮和业务贴得不够，就补业务语义；检查计划跟着改；通知从「每轮都发」改成「有问题才发」；再用 Skill 和 UModel 扩到更多实体和数据源。

这些数字不能被读成什么

147% 的日志增长、P90 从 94 秒到 171 秒、未完成率从 1.01% 到 6.2%、Thread 失败比 0% 但对面是 429，都是文中各举的一个窗口，不是在固定样本上算出来的均值，也没有给出巡检轮次、误报率和与纯规则基线的对照。检查项从 6 项到 11 项，是补了 skill 和 employeeId 之后的这一次计划更新。错误率从 1% 到 10% 是用来说明「知道出事但不知道集中在哪」的例子，不是这次巡检测到的结果。

文章没有公开评测集，没有写漏报了哪些未知模式，也没有写这几轮之外的稳定性。智能巡检被明确写成不能承诺找全未知问题。作者是阿里云云原生社区，不是署名到个人的实验报告。先前已发的 STAROps 文章评的是根因分析打分，这一篇评的是日志巡检怎么把变化收成可跟踪的 Finding，两者不是同一次测量。

出处：阿里云，Alibaba Cloud Native Community，Inside STAROps: An Intelligent Log Inspection Architecture for Surfacing Unknown Anomalies，2026-10-23，https://www.alibabacloud.com/blog/inside-starops-an-intelligent-log-inspection-architecture-for-surfacing-unknown-anomalies_603661