返回博客

最新

了解 orbitproxy可观测性:无需部署任何 ELK、ClickHouse 等额外复杂监控设施的情况下快速为云端点开启全量访问日志

话题：
了解 orbitproxy可观测性:无需部署任何 ELK、ClickHouse 等额外复杂监控设施的情况下快速为云端点开启全量访问日志

初创产品上线之后,你是否清楚有多少人访问了主页?

个人开发者是否知道自己站点每天的浏览量?企业内网里的演示项目,客户实际用得怎么样?生产环境的 API,是否能完整回溯每一次请求的内容?一个公开到互联网的站点,每天会遭遇多少恶意扫描和不明请求?

这些问题通常要靠自建日志体系来回答:部署 ELK 或 ClickHouse,编写采集和埋点代码,再长期维护。对于小团队和个人开发者,这个成本往往高于问题本身的价值。

在 orbitproxy 中,你只需要为云端点开启访问日志策略,即可获得完整的请求可观测性,无需部署、也无需维护任何监控基础设施,更不需要修改业务代码。

为什么在网关层做可观测性

在应用与互联网之间放置一层网关,最大的价值之一就是可观测性。网关位于所有流量的必经之路,因此可以在不侵入业务的前提下,记录每一次流向上游服务的请求。基于这些数据,你可以:

  1. 掌握网络运行状况:了解请求耗时、延迟等性能指标。
  2. 还原访问行为:明确谁在何时访问了产品的哪个模块,或调用了哪个 API。
  3. 前置发现恶意请求:在站点公开到互联网之后,及时发现钓鱼探测和恶意扫描并提前防御,而不是在攻击发生后再被动处置。
  4. 审计 AI 智能体的行为:记录 AI 智能体对 MCP 服务的每一次调用,明确它在你的服务器上执行了什么,并标记高危与异常行为。
  5. 收录并追踪 Webhook 回调:为每一次回调留存完整记录,便于对账、排查和重放。
  6. 缩短故障定位时间:异常发生时,直接通过访问日志定位问题,将对客户的影响降到最低。

orbitproxy 基于云端 Gateway 提供这套可观测性能力。你和团队无需自建监控设施,即可完整掌握从 orbitproxy 流向上游服务的 HTTP 流量,使任何 HTTP 服务在整个生命周期内都保持透明、可追踪。

traffic-inspector

如何开启

登录 orbitproxy 控制中心,按以下路径进行配置:

HTTP/TCP 云端点 → 选择目标云端点 → 流量策略 → 访问日志

访问日志策略只做记录,不会拦截请求,流量仍然正常转发到上游服务。你可以按需选择采集级别,三个级别逐级叠加:

采集级别 记录内容
元数据 请求的基本信息,包括 Method、来源 IP、状态码、Path 等
请求头 / 响应头 在元数据之外,记录完整的请求头与响应头
请求体 / 响应体 在以上内容之外,记录完整的请求体与响应体

此外可以按需配置日志保留天数。采集级别越高,记录的信息越完整,对应的存储占用也越多,请根据业务的敏感程度和排查需求选择。

access-log-panel

典型应用场景

1. 追踪异常请求,识别高危行为

在 AI 编程普及的今天,开发者、产品经理、设计师都能快速发布自己的产品。代码门槛降低了,但安全边界、基础设施这类通常由架构经验支撑的能力,却容易被忽视:产品是否正在被端口扫描,密钥是否已经泄露,在早期阶段很少被关注。

而攻击者的自动化扫描,恰恰偏好这类缺少防护的新产品。一旦探测或爆破成功,攻击者往往不会立即动手,而是长期潜伏;等产品获得市场验证、价值上升之后,再发起勒索或窃取数据,这类后果对产品而言可能是致命的。

orbitproxy 的访问日志可以在产品的任何阶段记录并识别异常请求,并为其标注风险级别。

dangrouse-req

上图是 orbitproxy 为用户捕获的一次典型扫描:攻击者持续探测 .env、config.json 以及各类 AI 服务的 API Key 等敏感文件。这类探测只要有一次返回 200,密钥就可能在无声无息间被窃取。

在这类场景下,真正的难点往往不是防护手段,而是看不见。许多团队在早期没有可观测性的概念,所以并不知道自己的服务已经被锁定为目标。orbitproxy 会记录每一个进入上游服务的请求,并对可疑请求标记高危。当你确认存在持续的恶意扫描时,即可立即采取应对措施,例如在访问日志中直接封禁来源 IP。

2. 访客记录与用户画像

在服务企业客户和创业团队的过程中,我们发现一个常见的困境:需要投放广告,却不清楚应当聚焦哪些城市、哪些功能。症结在于缺少用户画像数据。

orbitproxy 会汇总所有访问上游服务(官网、控制台或 API 等)的访客信息。你可以据此了解:

  • 产品的哪个模块、哪个页面最受关注;
  • 哪些城市和地域的用户更青睐你的产品。

iplocation

借助访问趋势,你还能直观地看到账户级和云端点级的流量走向,进而判断用户的使用高峰与使用习惯,为运营节奏和容量规划提供依据。

traffic-pic

3. 审计团队 AI 智能体对 MCP 服务的所有操作

Cursor、Claude、Codex 等 AI 智能体已经相当强大。一个生产环境的问题,人工定位可能需要十到二十分钟,而智能体通常只需要数十秒到几分钟。在远程支持或 B 端驻场时,客户的耐心会随时间快速消耗,把生产问题的排查交给 AI,已经成为很多团队的实际选择。

但对团队而言,智能体的行为始终是一个黑盒,并且难以约束。它的效率来自可以在一秒内连续执行数十次操作,而其中任何一步出错,影响都可能迅速放大。大多数时候我们并不关心 AI 具体做了什么,但一旦涉及数据库和敏感环境,频繁且没有边界的操作就会带来真实的不安全感。这也是目前多数企业仍未将 AI 完整接入生产环境的原因之一。

借助 orbitproxy 的 MCP 可观测性,你可以对团队所有 AI 智能体的行为进行全量观测:

  • 调用了哪个工具、使用了什么 MCP 方法;
  • 执行了什么 SQL,访问了哪些文件;
  • 完整的请求内容与响应内容、耗时与流量;
  • 访问密钥与来源指纹,用于区分是哪一个成员或智能体发起的调用。

对于高风险行为,可以通过风险级别筛选集中查看,并据此判断和处置。这样,团队中每位成员的 AI 智能体都被纳入统一管理,每个智能体做了什么,都有据可查、可以追溯。

deletesql

上图是一次真实的记录:Cursor 通过 MCP 调用数据库工具执行了一条 DELETE 语句。orbitproxy 完整保留了请求头和请求体中的 SQL,并在信号一栏将这次调用标记为「MCP 访问异常」,同时记录了访问来源指纹(macOS Cursor)。请求头中的访问密钥会自动脱敏,不会明文出现在日志里。

4. 统一追踪与管理团队所有 Webhook 端点

Webhook 是业务系统中最容易出问题、也最难排查的一类流量:

  • 对方主动推送,你无法控制时机。 回调发生在第三方系统内部,一旦你的服务当时不可用、处理出错或返回了非预期的结果,你往往只能从第三方后台看到一个「回调失败」。
  • 回调不支持自定义鉴权。 微信支付、支付宝这类回调,无法像普通 API 一样要求调用方携带你自定义的凭证。如果上游服务没有做严格的验签,回调就存在被伪造和篡改的风险。
  • 对账依赖原始报文。 订单状态不一致时,需要回溯第三方当时究竟发送了什么、你的服务当时又返回了什么。

orbitproxy 在网关层对这三类问题给出统一的解决方式:

完整收录每一次回调。 为接收 Webhook 的云端点开启访问日志,并选择「请求体 / 响应体」级别,第三方发来的每一次回调,包括请求头、请求体,以及你的服务返回的响应,都会被完整记录。支付金额、订单号、事件类型等字段可以直接在日志详情中查看,对账时不再需要翻服务端日志或向第三方索要报文。

webhook

拒绝的请求同样留痕。 配合 Webhook 验证策略,网关会使用平台证书校验回调的来源与报文完整性。伪造或被篡改的请求在网关终止,不会到达你的上游服务。这类请求在访问日志中会标明被哪一条策略拦截,以及拒绝原因,便于判断是配置问题还是确有伪造请求。

统一视图与多维筛选。 团队所有 Webhook 端点的日志集中在同一处。你可以按时间范围、状态、结果、错误码、来源 IP 等条件筛选。例如,只看某个时间段内返回非 2xx 的回调,快速定位处理失败的订单。

webhook-detail

HTTP 请求重放。 对于已经完整采集请求内容的 HTTPS 云端点,可以在访问日志中将某一次请求重放到上游服务。这在两类场景下尤其有用:一是开发调试时,不必再让第三方重新触发一次回调;二是线上因故障漏处理了某次回调,修复之后可以直接补发。重放产生的请求会在日志中带有「重放」标识,与真实的第三方请求区分开,且重放产生的请求不能被再次重放。重放属于套餐权益,是否可用取决于你当前订阅的套餐。

需要注意的是,重放会让上游服务再次收到同一份请求。对于支付、退款等有副作用的回调,请确保上游服务按业务单号做了幂等处理,再进行重放。

现在就试试吧！

我们很高兴orbitproxy控制中心中为大家带来可观测性能力，我们期待直接向产品团队收到您的反馈

还想了解其他内容？

可观测性

  • 可观测性:三个采集级别、访问来源指纹、访问趋势与访客分布的完整说明。
  • 访问日志策略:采集级别、日志 Body 上限、保留天数的配置参考。
  • MCP 可观测性:记录、监控和调试 AI 对 MCP 端点的每一次访问。

Webhook 与 MCP 安全

更多用法

准备把现有服务接进来？

控制台已经具备云端点、网关与策略配置能力。把本地、VPC 与边缘入口接上同一条可控链路，马上开始构建。