作者：来自 Elastic Costas Pipilas, Jenny Pavlova, Miriam Aparicio
我们没有直接采信 agent 给出的根本原因。服务地图和追踪数据佐证了它的判断，而一条 ES|QL 查询则量化了问题：138 笔黄金等级客户的扣款中有 80 笔失败，其他等级的扣款均未失败。
使用 Elastic 端到端追踪每个请求。亲自体验应用性能监控（application performance monitoring），探索应用性能监控文档（APM docs），或立即开始免费云试用（free cloud trial）。
结账失败率达到 25% 时触发了告警，而告警所在的服务位于根本原因上游两个服务的位置。Elastic 人工智能 Agent（Elastic AI Agent）读取告警后，将问题定位到了前端之外。支付服务以“无效令牌”为由拒绝银行卡扣款，这一错误向上传递到结账服务，最终表现为订单失败。于是，我们展开了调查。
在 agent 的服务地图中选择支付服务，便打开了 Elastic 应用性能监控服务浮出面板，随后可以查看失败的事务、完整追踪以及抛出异常的跨度。堆栈追踪指向 charge.js 的第 37 行。一条 Elasticsearch 查询语言（ES|QL）查询确认了 agent 尚不确定的部分：在 30 分钟内，138 笔黄金等级客户的扣款中有 80 笔失败，其他等级的扣款均未失败。
在这篇博文中，我们将使用开放遥测演示（OpenTelemetry (OTel) Demo）和 Elastic 可观测性 9.6，完整展示这次调查。
下图展示了三种入口。告警或完整服务地图会将其上下文发送给 人工智能 agent，后者会在回答中提供自己的服务地图。在该地图中选择某个服务，或在探索界面中选择一个 service.name 值，即可打开服务浮出面板。
Elastic 可观测性 9.6 中的调查流程：通过告警、服务地图或探索界面，进入人工智能 agent 和 Elastic 应用性能监控浮出面板，从服务逐层深入到跨度。
在开放遥测演示中设置支付故障（Set up a payment fault in the OTel Demo）
开放遥测演示是一个在线商店，由使用多种语言编写的服务构成，并通过开放遥测软件开发工具包进行插桩。我们运行了 Elastic 的演示分支（Elastic's fork of the demo）（版本 2.2.1），并将其连接到 本地部署 的 Elastic 技术栈 9.6。它通过以开放遥测模式运行的 Elastic Agent 9.5.5（Elastic Agent 9.5.5 running in OpenTelemetry mode）发送追踪、指标和日志。
该演示内置了用于注入故障的功能开关，由其功能开关服务 flagd 提供。我们将 paymentFailure 开关设置为 25%。随后，支付服务会使四分之一的扣款请求失败，并为每个失败请求标记 app.loyalty.level=gold。
购物者看不到支付服务。他们看到的是结账时订单失败，因此我们的告警从购物者的角度监控结账：针对前端的 POST /api/checkout 事务设置事务失败率阈值规则，当五分钟内的失败率超过 10% 时触发。开启该开关几分钟后，告警便触发了，原因为：“服务：前端，类型：请求，最近五分钟内的事务失败率为 25%。超过 10% 时告警。”
前端 POST /api/checkout 事务的结账失败告警详情。点击顶部的“添加到聊天”，即可打开人工智能 agent，并附上该告警。
如何查找 Elastic 应用性能监控告警的根本原因？
这次调查分为四个步骤，每一步都对前一步的结果进行验证。
1. 从 Elastic 人工智能 agent 中的告警入手
告警详情页顶部有一个添加到聊天（Add to chat）按钮。点击后，会打开人工智能 agent，附上告警，并替你发送_调查此告警_。agent 会根据你的权限检索规则、状态、原因和相关实体，因此你无须一开始就描述问题。
几秒钟后，agent 就将问题定位到了前端之外：“结账失败并非前端问题：支付服务以‘无效令牌’为由拒绝银行卡扣款，错误经由结账服务向上传递到前端。”它在支付、结账和前端日志中发现了相同的错误，并指出这三个服务的失败率几乎相同，因此支付失败几乎解释了所有结账失败。该 agent 通过 Elastic 推理服务（EIS）使用 Anthropic 的 Claude Opus 5.5 运行。每次运行的回答可能有所不同，因此你看到的措辞和数字也可能不同。
告警旁显示人工智能 agent 的调查结果。支付服务以“无效令牌”为由拒绝银行卡扣款，错误经由结账服务向上传递到前端。
Agent 还列出了它尚不确定的地方。它抽样检查的每条错误消息都包含 app.loyalty.level=gold，因此它以中等置信度推测，只有一个客户等级受到影响：“每个样本都标记为黄金等级。我还没有检查是所有黄金等级请求都失败，还是只有部分失败。”接下来的章节将验证这条线索。
2. 在 Elastic 应用性能监控服务地图上验证人工智能 agent 的回答
我们告诉 agent：显示支付服务的服务地图。它返回了与服务页面相同的交互式地图，以支付服务为中心：结账服务调用支付服务，支付服务调用 flagd。地图带有告警、服务等级目标（SLO）和异常徽章。它还会记录捕获时间（显示为“拓扑截至时间”），并通过**在服务地图中探索（Explore in Service map）**链接到完整地图。除了地图，agent 还指出：“来自结账服务的调用很快就失败了，平均约为 2.3 毫秒。请求被立即拒绝，而不是超时。”
人工智能 agent 以交互式服务地图回应“显示支付服务的服务地图”。结账服务调用支付服务，支付服务调用 flagd。
在该地图上选择支付服务（payment），即可在对话旁打开其服务浮出面板，查看该服务的延迟、事务失败率和吞吐量。故障开始时，事务失败率图表骤然上升，无须离开对话即可验证 agent 的说法。
从 agent 的地图打开的支付服务浮出面板，显示延迟、事务失败率和吞吐量。故障开始时，事务失败率骤然上升。
3. 从服务浮出面板逐层深入到故障跨度
服务浮出面板列出了支付事务。选择 grpc.oteldemo.PaymentService/Charge（扣款事务），即可在其上方打开事务浮出面板，查看该事务的指标、单独显示失败事务的延迟分布，以及追踪样本。失败样本会在扣款操作上显示“错误”徽章。
grpc.oteldemo.PaymentService/Charge 的事务浮出面板。延迟分布单独显示失败事务，失败的追踪样本带有“错误”徽章。
选择样本时间线中的事务，即可打开完整追踪。它展示了一笔订单从负载生成器经过 frontend-proxy 和 frontend，到达 checkout 的完整过程，随后结账服务依次调用购物车、商品目录、货币、配送，最后调用支付服务。从负载生成器的 POST 请求到支付服务的 charge 跨度，沿途的每个跨度都标记为失败，结账服务对支付服务的调用在 3.3 毫秒后失败。
一笔失败订单的完整追踪，从负载生成器经过前端和结账服务，到达支付服务的扣款跨度。该路径上的每个跨度都标记为失败。
选择支付服务的扣款（charge）跨度，即可打开其文档。错误（Errors）部分显示了原因：“支付请求失败。无效令牌。app.loyalty.level=gold。/Payment request failed. Invalid token . app.loyalty.level=gold.” 点击查看错误（View error），即可打开异常本身，其中的堆栈追踪指向支付服务 charge.js 的第 37 行。
支付服务扣款跨度的跨度文档。“错误”部分显示：“支付请求失败。无效令牌。app.loyalty.level=gold。”
扣款失败背后的异常，堆栈追踪指向支付服务 charge.js 的第 37 行。
以下是四种浮出面板及其各自提供的信息：
| 浮出面板（Fyout） | 打开入口（Opens from） | 显示内容（Shows） | 深入查看（Drills to） |
|---|---|---|---|
| 服务 | 人工智能 agent 的地图、服务地图或探索界面中的服务名称 | 延迟、事务失败率、吞吐量、事务列表 | 事务 |
| 事务 | 在服务浮出面板中选择事务 | 事务指标、单独显示失败事务的延迟分布、追踪样本 | 追踪 |
| 追踪 | 在样本时间线中选择事务 | 路径上所有服务的完整跨度时间线 | 跨度 |
| 跨度 | 在追踪中选择跨度 | 跨度文档，包括“错误”部分和“查看错误”入口 | 异常和堆栈追踪 |
点击返回（Back），即可逐个浮出面板地返回追踪、事务和服务。在逐层查看时，浮出面板会保留服务的环境和时间范围。如果你在服务浮出面板中更改环境，且该环境中存在相应事务，事务浮出面板也会随之切换。如果你更改事务类型，或选择不包含该事务的环境，事务浮出面板会保留之前的数据并显示警告。
4. 用一条 ES|QL 查询确认根本原因
追踪解释了一笔订单为何失败。agent 尚未解答的问题则涉及所有订单：是否只有黄金等级客户的扣款失败？他们的扣款是否全部失败？ 对支付服务的扣款跨度执行一条 ES|QL 查询，就能得到答案。我们在探索界面中运行了该查询，时间范围由时间选择器设置：
`
1. FROM traces-*
2. | WHERE service.name == "payment" AND span.name == "charge"
3. | STATS charges = COUNT(*), failed = COUNT(CASE(event.outcome == "failure", 1, null))
4. BY attributes.app.loyalty.level
5. | EVAL failure_rate = ROUND(failed * 100.0 / charges, 1)
6. | SORT failure_rate DESC
`AI代码解释
过去 30 分钟内，138 笔黄金等级客户的扣款中有 80 笔失败，而铂金、白银和青铜等级客户的扣款均未失败。agent 发现的线索得到了证实。只有黄金等级客户受到影响，但并非每笔黄金等级客户的扣款都会失败。在这个演示中，答案是预设的，因为故障会将它导致失败的请求标记为黄金等级。在真实服务中，同样的查询可以帮助你在采取行动之前，区分观察到的现象究竟是规律还是巧合。Elastic Agent 将开放遥测跨度属性存储在带有 attributes. 前缀的字段中，因此，来自 Elastic 应用性能监控 agent 的数据需要使用不同的字段名称。
探索界面中的一条 ES|QL 查询按忠诚度等级对支付扣款进行分组。138 笔黄金等级客户的扣款中有 80 笔失败，其他等级均未出现失败。
当你没有通过告警就定位到故障服务时，9.6 版本中的另外两项改进也能提供帮助。
在服务地图面板中查看服务依赖关系
服务概览和事务详情页（包括移动服务的对应页面）现在都包含服务地图面板（Service map panel）。在支付服务概览中，它将结账服务显示为依赖支付服务的调用方，并将 flagd 显示为支付服务调用的服务。跳数（Hops）设置沿连接追踪的层数（默认为 1），最大可见数量（Max visible）限制显示的节点数量（默认为 8）。较小的默认值可在服务依赖关系较多时保持面板清晰易读。
支付服务概览中的服务地图面板。结账服务依赖支付服务，支付服务调用 flagd。“跳数”和“最大可见数量”控制地图的显示范围。
在服务地图中探索（Explore in Service map）会打开完整地图，保留时间范围、环境和 Kibana 查询语言（KQL）查询，并选中该服务。在完整地图中，你可以通过搜索栏中的 **service.name（服务名称）控件同时选择多个服务，例如结账服务和支付服务，地图会高亮显示这两个服务及其连接。将地图复制到仪表板时，面板会保留这些高亮显示和筛选条件，点击面板上的在服务地图中查看（View in Service map）**即可恢复这些设置。
该面板取代了各服务原有的服务地图（Service map）选项卡。
从服务地图页面或探索界面开始调查
如果尚未出现告警，可以从完整服务地图页面开始。工具栏中的**调查地图（Investigate map）**会将当前视图发送给人工智能 agent，包括时间范围、环境、KQL 查询、服务组和高亮显示的服务。
agent 会检查该视图中的每个服务，并按严重程度排列调查结果：
- 活跃告警。
- 已违反或正在恶化的服务等级目标。
- 机器学习异常。
- 异常的错误率或延迟。
在我们的地图上，即使没有以告警为起点，它也得出了相同的结论：“主要问题是支付服务正在拒绝黄金等级忠诚度客户的扣款请求。”
完整服务地图页面上的“调查地图”会将当前视图发送给人工智能 agent。agent 发现支付服务正在拒绝黄金等级客户的扣款请求。
如果你已经在探索界面中，只需点击一下即可打开同一组浮出面板（same flyout stack）。打开一份追踪文档，在其**概览（Overview）**选项卡中选择服务名称，即可打开服务浮出面板，再从中依次进入事务、追踪和跨度浮出面板。服务浮出面板打开时，会采用该文档所属的环境，以及你在探索界面中设置的时间范围。
探索界面中的一个失败支付跨度，其“概览”选项卡已打开。选择服务名称 payment，即可打开服务浮出面板。
在探索界面中点击失败支付跨度的 service.name，即可打开支付服务浮出面板，并沿用该文档所属的环境和探索界面中的时间范围。
Elastic 应用性能监控浮出面板和“调查地图”的当前限制
- 对于使用未经处理的开放遥测数据的服务，例如直接从社区贡献版收集器发送的数据，服务浮出面板会显示关键指标，以错误率（Error rate）代替事务失败率（Failed transaction rate），但不显示事务表，因此无法深入查看事务。你仍可在探索界面中，通过文档展开后的追踪时间线打开其跨度。
- **调查地图（Investigate map）**操作仅在完整服务地图页面上可用。嵌入告警详情和仪表板中的地图不会显示此操作。
- **调查地图（Investigate map）**最多向 agent 发送 50 个高亮显示的服务。
- 从探索界面打开的服务浮出面板不会继承探索界面的查询或筛选标签。
- 对于采用当前远程过程调用语义约定（
rpc.system.name）的 gRPC 调用，服务地图中的连接需要使用 Elastic 开放遥测发行版收集器 9.3.3 或更高版本，或以开放遥测模式运行的 Elastic Agent 9.5 或更高版本。使用该收集器的 9.3.0 版本时，地图未能将结账服务连接到支付服务。
要求：Elastic 技术栈版本、许可证和权限
这些功能需要满足以下要求。
- 版本：（Version:） Elastic 技术栈 9.6 或更高版本，或 Elastic 可观测性无服务器服务。
- 许可证：（License:） Elastic 技术栈需要企业版许可证，Elastic 可观测性无服务器服务则需要可观测性完整功能层级（Observability Complete feature tier）。
- 模型：（Model:） 人工智能 agent 需要通过 Elastic 推理服务或生成式人工智能连接器使用模型。
- 角色权限：（Role privilege:） 用户的角色需要具备人工智能 agent 权限（列为 agent 构建器），才能看到添加到聊天（Add to chat）和调查地图（Investigate map）。
- 高级设置：（Advanced setting:） 聊天体验必须设置为 agent，这是 9.6 版本的默认设置。（此前选择了人工智能助手的部署会保留原有选择。）
- 可用性：（Availability:） 调查浮出面板已正式发布。探索界面中的其余追踪体验仍处于技术预览阶段。
在你自己的服务上开展这项调查
选择一个最近触发过告警的服务，打开告警，然后选择添加到聊天（Add to chat）。agent 回答后，在其地图中选择一个服务，再沿着浮出面板逐层深入到跨度。文档涵盖了各个环节：
- 调查告警或服务地图（Investigate an alert or the service map）
- 使用浮出面板调查服务（Investigate a service with flyouts）
- Elastic 应用性能监控中的服务地图（Service map in Elastic APM）
如需分享反馈，请通过 Elastic 社区论坛联系我们，或在 Kibana 代码仓库中提交问题。
常见问题
Elastic 人工智能 agent 能调查 Elastic 应用性能监控告警吗？
可以。点击告警详情页上的“添加到聊天”，即可打开人工智能 agent，附上告警并开始调查。agent 可以在回答中提供交互式服务地图，点击每个节点都能打开对应服务的浮出面板，让你根据追踪数据验证其结论。
我能否直接在探索界面中调查追踪，而无须切换到 Elastic 应用性能监控应用？
可以。在探索界面中打开追踪文档，选择其“概览”选项卡中的服务名称，即可打开服务浮出面板。随后，你可以在支持“返回”导航的一组浮出面板中，依次打开事务、完整追踪，以及单个跨度或错误。
原文：APM service map investigation: Alert to failing span | Elastic Observability Labs
