EdgeOne Makers 可观测性概览

项目部署上线之后，最让人头疼的事就是”不知道它到底跑得好不好”。用户说页面打不开，你查了半天发现是某个接口报错。用户说响应慢，你测了一下发现是自己网络问题。这种靠猜的排查方式效率太低。可观测性就是来解决这个问题的，让你对项目的运行状态一目了然。

什么是可观测性

可观测性(Observability)说的是一个系统从外部判断内部状态的能力。放在 EdgeOne Makers 的场景里就是: 你不用登录服务器、不用翻日志文件，通过控制台就能看到项目的健康状况、性能表现和安全情况。

传统的可观测性需要自己搭三套系统:

三套系统搭下来，工程量不小。EdgeOne Makers 把这三层能力内置到平台里了，不需要你额外配置，打开控制台就能用。

指标分析

指标分析是最直观的部分。打开控制台，在项目概览页面就能看到关键性能指标。

能看到什么数据

指标分析的使用场景

场景一: 发现流量异常

某天你发现请求量突然涨了三倍，但业务没有做推广。这时候就要排查是不是被爬虫扫了、被攻击了，或者某个外部链接突然火了。指标分析能帮你快速定位异常时间点。

场景二: 定位慢接口

用户反馈某个页面加载慢，你在指标分析里看响应延迟的分布图，找到耗时最长的请求路径，就能精准定位到是哪个接口慢。

场景三: 监控错误率

错误率平时接近 0，突然涨到 2%。虽然绝对值不大，但说明有问题在发生。顺着错误日志往下查，可能是数据库连接超时，也可能是某个第三方接口挂了。

维度查看

指标支持按不同维度查看:

日志分析

指标告诉你”有问题”，日志告诉你”什么问题”。日志分析让你在控制台里搜索和查看每一次函数调用的详细日志。

日志包含什么

日志查询方式

日志查询支持多种过滤条件:

按时间范围查询: 最近 15 分钟 / 最近 1 小时 / 自定义时段
按状态码过滤: 只看 4xx 或 5xx 的错误请求
按路径过滤: 只看某个特定接口的请求
按关键词搜索: 搜索日志内容中的关键词

举个例子，线上有人反馈接口报错，你大概知道是下午两点左右发生的，那就:

时间范围: 14:00 - 14:30
状态码: 500
路径: /api/submit

一搜就能找到那几条错误日志，看到具体的错误信息。

链路追踪

链路追踪解决的是”一个请求经过了哪些环节、每个环节花了多少时间”这个问题。对于 Agent 应用来说特别重要，因为 Agent 的一次调用可能包含多轮模型推理、多次工具调用、多个中间步骤。

Agent 的调用链路

普通 Web 请求的链路比较简单: 用户请求 -> 服务器处理 -> 返回响应。

Agent 的调用链路要复杂得多:

用户请求
  -> 模型推理(决定调用哪个工具)
    -> 工具1: 查天气 API
    -> 模型推理(分析工具返回结果)
      -> 工具2: 查数据库
      -> 模型推理(生成最终回答)
        -> 返回响应

链路追踪把这条链路上每个步骤的耗时、输入、输出都记录下来。哪个步骤慢、哪个步骤报错，一眼就能看到。

追踪面板能看什么

三层可观测性的配合使用

指标、日志、链路追踪不是孤立的，排查问题时通常是三层配合:

第一步: 看指标发现异常
  -> 错误率突然升高
  -> 响应延迟变长
  -> 请求量异常

第二步: 看日志定位问题
  -> 找到具体的错误请求
  -> 看到错误信息和堆栈
  -> 确认是哪个接口、什么时间

第三步: 看链路追踪找到根因
  -> 请求经过了哪些步骤
  -> 哪个步骤慢或者报错
  -> 是模型推理慢还是工具调用失败

举个实际例子。你收到用户反馈说 Agent 回复很慢。

第一步，看指标面板，发现响应延迟中位数从 2 秒涨到了 8 秒。

第二步，看日志，找到那个耗时长的请求，发现它调用了 /api/chat 接口。

第三步，看链路追踪，发现那次请求中模型推理只用了 1 秒，但工具调用”查天气 API”花了 6 秒。进一步排查发现天气 API 的第三方服务响应慢。

问题定位了，不是你的代码有问题，是外部依赖拖慢了速度。解决方案可以是给工具调用加超时时间、加缓存、或者换一个更稳定的天气 API。

可观测性对 Agent 应用的意义

Agent 应用相比普通 Web 应用，可观测性更加重要。原因如下:

EdgeOne Makers 的可观测性专门为 Agent 做了优化，Trace 里能看到每次模型调用的输入输出、Token 消耗、工具调用详情。这些信息对调试和优化 Agent 至关重要。

速查卡片