作者来自 Elastic Joe Reuter学习如何使用 Elasticsearch 日志聚类和 AI agents 自动化错误分诊将生产日志转化为可执行的根因报告。工程反馈循环通常被描绘为一个清晰的周期发布功能、监控其健康状态、进行问题分诊、识别 bug以及部署修复。然而在大规模云环境中从监控到问题识别的路径往往成为瓶颈。当运行在 Elastic Cloud 上的数千个 Kibana 实例在庞大的代码库中产生数百万条日志时从错误发生到工程师理解其根因之间的延迟——即维护鸿沟Maintenance Gap——可能从数小时延长到数月。为了弥合这一鸿沟我们构建了一个超越简单监控的自动化管道。通过自动化发现和调查阶段我们将工程师的关注点从 “发生了什么”转变为 “这个修复是否正确”反馈循环中的瓶颈在一个高速度的工程环境中从部署到解决问题的路径包括多个不同阶段发布Ship、监控Monitor、分诊Triage、识别Identify、修复Fix以及评审/部署Review/Deploy。速度通常在分诊和识别阶段停滞。虽然灾难性故障会被立即报告但较小的错误 —— 例如间歇性的 UI 故障或后台任务失败 —— 往往不会被报告。这种对人工报告的依赖会导致解决时间被拉长在报告被提交并路由之前问题可能已经影响整个系统数天。通过自动化发现和调查即使是这些“纸割”类的小问题也能在累积成重大技术债务之前被量化。目标是确保当开发人员进入编写修复的阶段时所有的排查工作已经完成。发现自动化日志聚类在这个过程中第一个挑战是信噪比。在大规模生产环境中为每一个错误事件创建工单是不可管理的。我们不再分析单独的日志行而是使用 ES|QL 的 CATEGORIZE 分组函数自动化分诊过程。CATEGORIZE 会将文本消息聚类为格式相似的分组将非结构化遥测数据转化为按优先级排序的不同错误模式待办列表。例如类似如下的查询会在所有 Kibana 错误日志上以滚动窗口运行FROM kibana-server-logs | WHERE log.level ERROR AND timestamp NOW() - 7 days | STATS count COUNT() BY category CATEGORIZE(message) | SORT count DESC结果是一个包含类似 regex 的类别及其出现次数的表格countcategory1,247.?TypeError.?Cannot.?read.?properties.?of.?undefined.?reading.?document.?812.?Connection.?error.?3.?Disconnected.?像TypeError Cannot read properties of undefined reading document这样在过去一周内出现 1,200 次的类别表明这是一个真实且反复出现、值得调查的缺陷。而像Connection error这种在整个系统中均匀分布的类别更可能是基础设施噪声。输出结果会被用来自动在待办列表中创建按优先级排序的问题每个问题都包含类别、其 regex、出现次数以及指向原始遥测数据的深度链接。这种自动化确保反馈循环不再等待用户报告来触发调查发现过程是主动且即时的。这些优先级排序后的聚类随后作为自主调查 agent 的直接输入。调查自动化侦探一旦识别出错误模式管道就会进入识别阶段。我们部署了一个 AI agent 来对问题进行完整调查。在像 Kibana 这样复杂的代码库中导航非常耗时该 agent 通过使用ES|QLElasticsearch Query Language在整个技术栈中关联信息来加速这一过程。基于协议的调查需要将该 agent 与传统自动化脚本区分开来。该 agent 并不遵循硬编码的状态机相反它被提供了一个协议用于描述调查目标和可用工具。该协议规定了一种分阶段的方法理解错误、分析其分布、与其他数据源进行关联、找到源头并生成报告。每个阶段都是以目标来描述而不是命令。以下摘录展示了协议如何定义第一个调查步骤### Phase 1: Understand the Error - Review the pre-extracted error details from the backlog issue - Check for similar/overlapping error backlog issues (include closed!) - the categorization is often imperfect; closed issues may have valuable context about fixes - Query for error overview statistics - Get sample error messages to understand the actual content该 agent 还提供了一个 ES|QL 参考指南和一组查询模板库。以下是一个用于分析版本分布的模板这是判断错误是否为回归问题的常见第一步FROM logging-*:cluster-kibana-* | WHERE timestamp NOW() - 4 hours AND log.level ERROR AND message : TypeError Cannot read properties | STATS error_count COUNT(*), deployments COUNT_DISTINCT(ece.deployment) BY docker.container.labels.org.label-schema.version | SORT error_count DESC由于该 agent 可以根据先前查询结果自主决定调用哪些工具以及调用顺序因此它能够针对具体错误调整策略。如果遥测数据显示是后台任务失败它可能会跳过 proxy 分析如果 ES|QL 显示该 bug 仅存在于某个特定版本它则可能深入分析 git 历史。这种灵活性使其能够在无需为每种可能的故障模式预定义路径的情况下应对大规模代码库的复杂性。经验总结查询纪律直接让 LLM 访问生产集群需要策略性约束以管理成本和性能。我们将若干要求固化到调查工作流中以确保效率查询预算每次调查中 agent 被限制在约 15-20 次查询内迫使其在数据检索前先形成假设。4 小时规则agent 从较小的时间窗口最近 1-4 小时开始以利用缓存并降低计算成本。最优操作符agent 优先使用等值过滤和 MATCH:操作符而不是 LIKE 或 regex这可以让查询速度提升 50-1000 倍。快速失败超时每个查询都有严格的超时时间要求 agent 优化过滤条件而不是重试高成本操作。源代码上下文关联为了完成识别阶段agent 会将遥测数据与 git 历史和源代码文件进行关联。它利用堆栈跟踪和日志模式缩小搜索范围比手动搜索更快地解析潜在代码匹配。通过定位产生错误的具体代码行并检查最近的 PRagent 能将生产中的症状直接关联到其技术根因。真实案例研究Streams UI 崩溃这种自动化调查的价值在其发现罕见边界情况时尤为明显。在一个案例中聚类系统发现了一个偶发模式.?TypeError.?Cannot.?read.?properties.?of.?undefined.?reading.?document.?人工可能会将其视为普通遥测噪声但 agent 的调查揭示了 Streams UI 中一个可复现的竞争条件量化使用 ES|QLagent 分析了错误分布并识别出具体应用上下文Streams以及相关日志记录器。代码分析它在 processor_outcome_preview.tsx 中发现了一个逻辑错误。代码在未验证元素是否存在的情况下访问数组originalSamples[currentDoc.index].document。根因agent 发现当用户在行展开时更改过滤条件currentDoc.index 在下一次渲染清除之前变得过期。结果agent 提供了建议修复方案对访问进行保护并建议为行展开期间的过滤变化添加回归测试。该案例突显了自动化分诊的经济规模价值。在数千条 “噪声” 日志中筛选出少数真正可修复的 UI 崩溃对高级工程师来说不可行。agent 以极低成本处理这一规模的数据充当高精度过滤器确保人工时间只用于已验证且可执行的问题。工程效率的未来自动化分诊和识别只是第一步。我们目前正在逐步加入将这些发现传递给 coding agent 以生成 Pull Requests 草稿的能力。除了生产环境错误之外我们还在探索 agent 驱动的探索性测试在发布前阶段对功能进行压力测试并在 bug 到达用户之前将其捕获。这一自主层是对传统质量门禁的补充而不是替代。单元测试、API 级检查以及 UI 集成测试仍然是主要防线。我们的方法为那些在复杂环境中不可避免绕过这些门禁的失败提供了安全网确保它们能像发布前 bug 一样被严格处理。随着我们迈向更加 agent 驱动的开发流程快速验证变更是否安全以及控制整体质量的能力成为工程效率的主要瓶颈。虽然代码生成本身正逐渐商品化但用于验证变更既正确又安全所需的 “推理” 能力仍然是最关键的障碍。通过将自动化聚焦于故障的发现和根因分析我们确保工程团队能够在不被维护质量的运维负担压垮的情况下扩大其影响力。目标是构建一个能够理解、诊断并最终自我修复的系统。有关 Elastic 及其可观测性能力的更多信息请查看 Elastic Observability。你也可以注册免费试用亲自体验。原文https://www.elastic.co/observability-labs/blog/automated-error-triaging Observabilty：自动化错误分诊 - 从被动到自主
作者来自 Elastic Joe Reuter学习如何使用 Elasticsearch 日志聚类和 AI agents 自动化错误分诊将生产日志转化为可执行的根因报告。工程反馈循环通常被描绘为一个清晰的周期发布功能、监控其健康状态、进行问题分诊、识别 bug以及部署修复。然而在大规模云环境中从监控到问题识别的路径往往成为瓶颈。当运行在 Elastic Cloud 上的数千个 Kibana 实例在庞大的代码库中产生数百万条日志时从错误发生到工程师理解其根因之间的延迟——即维护鸿沟Maintenance Gap——可能从数小时延长到数月。为了弥合这一鸿沟我们构建了一个超越简单监控的自动化管道。通过自动化发现和调查阶段我们将工程师的关注点从 “发生了什么”转变为 “这个修复是否正确”反馈循环中的瓶颈在一个高速度的工程环境中从部署到解决问题的路径包括多个不同阶段发布Ship、监控Monitor、分诊Triage、识别Identify、修复Fix以及评审/部署Review/Deploy。速度通常在分诊和识别阶段停滞。虽然灾难性故障会被立即报告但较小的错误 —— 例如间歇性的 UI 故障或后台任务失败 —— 往往不会被报告。这种对人工报告的依赖会导致解决时间被拉长在报告被提交并路由之前问题可能已经影响整个系统数天。通过自动化发现和调查即使是这些“纸割”类的小问题也能在累积成重大技术债务之前被量化。目标是确保当开发人员进入编写修复的阶段时所有的排查工作已经完成。发现自动化日志聚类在这个过程中第一个挑战是信噪比。在大规模生产环境中为每一个错误事件创建工单是不可管理的。我们不再分析单独的日志行而是使用 ES|QL 的 CATEGORIZE 分组函数自动化分诊过程。CATEGORIZE 会将文本消息聚类为格式相似的分组将非结构化遥测数据转化为按优先级排序的不同错误模式待办列表。例如类似如下的查询会在所有 Kibana 错误日志上以滚动窗口运行FROM kibana-server-logs | WHERE log.level ERROR AND timestamp NOW() - 7 days | STATS count COUNT() BY category CATEGORIZE(message) | SORT count DESC结果是一个包含类似 regex 的类别及其出现次数的表格countcategory1,247.?TypeError.?Cannot.?read.?properties.?of.?undefined.?reading.?document.?812.?Connection.?error.?3.?Disconnected.?像TypeError Cannot read properties of undefined reading document这样在过去一周内出现 1,200 次的类别表明这是一个真实且反复出现、值得调查的缺陷。而像Connection error这种在整个系统中均匀分布的类别更可能是基础设施噪声。输出结果会被用来自动在待办列表中创建按优先级排序的问题每个问题都包含类别、其 regex、出现次数以及指向原始遥测数据的深度链接。这种自动化确保反馈循环不再等待用户报告来触发调查发现过程是主动且即时的。这些优先级排序后的聚类随后作为自主调查 agent 的直接输入。调查自动化侦探一旦识别出错误模式管道就会进入识别阶段。我们部署了一个 AI agent 来对问题进行完整调查。在像 Kibana 这样复杂的代码库中导航非常耗时该 agent 通过使用ES|QLElasticsearch Query Language在整个技术栈中关联信息来加速这一过程。基于协议的调查需要将该 agent 与传统自动化脚本区分开来。该 agent 并不遵循硬编码的状态机相反它被提供了一个协议用于描述调查目标和可用工具。该协议规定了一种分阶段的方法理解错误、分析其分布、与其他数据源进行关联、找到源头并生成报告。每个阶段都是以目标来描述而不是命令。以下摘录展示了协议如何定义第一个调查步骤### Phase 1: Understand the Error - Review the pre-extracted error details from the backlog issue - Check for similar/overlapping error backlog issues (include closed!) - the categorization is often imperfect; closed issues may have valuable context about fixes - Query for error overview statistics - Get sample error messages to understand the actual content该 agent 还提供了一个 ES|QL 参考指南和一组查询模板库。以下是一个用于分析版本分布的模板这是判断错误是否为回归问题的常见第一步FROM logging-*:cluster-kibana-* | WHERE timestamp NOW() - 4 hours AND log.level ERROR AND message : TypeError Cannot read properties | STATS error_count COUNT(*), deployments COUNT_DISTINCT(ece.deployment) BY docker.container.labels.org.label-schema.version | SORT error_count DESC由于该 agent 可以根据先前查询结果自主决定调用哪些工具以及调用顺序因此它能够针对具体错误调整策略。如果遥测数据显示是后台任务失败它可能会跳过 proxy 分析如果 ES|QL 显示该 bug 仅存在于某个特定版本它则可能深入分析 git 历史。这种灵活性使其能够在无需为每种可能的故障模式预定义路径的情况下应对大规模代码库的复杂性。经验总结查询纪律直接让 LLM 访问生产集群需要策略性约束以管理成本和性能。我们将若干要求固化到调查工作流中以确保效率查询预算每次调查中 agent 被限制在约 15-20 次查询内迫使其在数据检索前先形成假设。4 小时规则agent 从较小的时间窗口最近 1-4 小时开始以利用缓存并降低计算成本。最优操作符agent 优先使用等值过滤和 MATCH:操作符而不是 LIKE 或 regex这可以让查询速度提升 50-1000 倍。快速失败超时每个查询都有严格的超时时间要求 agent 优化过滤条件而不是重试高成本操作。源代码上下文关联为了完成识别阶段agent 会将遥测数据与 git 历史和源代码文件进行关联。它利用堆栈跟踪和日志模式缩小搜索范围比手动搜索更快地解析潜在代码匹配。通过定位产生错误的具体代码行并检查最近的 PRagent 能将生产中的症状直接关联到其技术根因。真实案例研究Streams UI 崩溃这种自动化调查的价值在其发现罕见边界情况时尤为明显。在一个案例中聚类系统发现了一个偶发模式.?TypeError.?Cannot.?read.?properties.?of.?undefined.?reading.?document.?人工可能会将其视为普通遥测噪声但 agent 的调查揭示了 Streams UI 中一个可复现的竞争条件量化使用 ES|QLagent 分析了错误分布并识别出具体应用上下文Streams以及相关日志记录器。代码分析它在 processor_outcome_preview.tsx 中发现了一个逻辑错误。代码在未验证元素是否存在的情况下访问数组originalSamples[currentDoc.index].document。根因agent 发现当用户在行展开时更改过滤条件currentDoc.index 在下一次渲染清除之前变得过期。结果agent 提供了建议修复方案对访问进行保护并建议为行展开期间的过滤变化添加回归测试。该案例突显了自动化分诊的经济规模价值。在数千条 “噪声” 日志中筛选出少数真正可修复的 UI 崩溃对高级工程师来说不可行。agent 以极低成本处理这一规模的数据充当高精度过滤器确保人工时间只用于已验证且可执行的问题。工程效率的未来自动化分诊和识别只是第一步。我们目前正在逐步加入将这些发现传递给 coding agent 以生成 Pull Requests 草稿的能力。除了生产环境错误之外我们还在探索 agent 驱动的探索性测试在发布前阶段对功能进行压力测试并在 bug 到达用户之前将其捕获。这一自主层是对传统质量门禁的补充而不是替代。单元测试、API 级检查以及 UI 集成测试仍然是主要防线。我们的方法为那些在复杂环境中不可避免绕过这些门禁的失败提供了安全网确保它们能像发布前 bug 一样被严格处理。随着我们迈向更加 agent 驱动的开发流程快速验证变更是否安全以及控制整体质量的能力成为工程效率的主要瓶颈。虽然代码生成本身正逐渐商品化但用于验证变更既正确又安全所需的 “推理” 能力仍然是最关键的障碍。通过将自动化聚焦于故障的发现和根因分析我们确保工程团队能够在不被维护质量的运维负担压垮的情况下扩大其影响力。目标是构建一个能够理解、诊断并最终自我修复的系统。有关 Elastic 及其可观测性能力的更多信息请查看 Elastic Observability。你也可以注册免费试用亲自体验。原文https://www.elastic.co/observability-labs/blog/automated-error-triaging