如何使用 OTel + Elastic 获取 OpenClaw 的可观测性

如何使用 OTel + Elastic 获取 OpenClaw 的可观测性

把一个开源智能体接上遥测，不是为了"看日志"。是为了让它从"能跑"，变成可优化、可上生产、可过合规的系统。

一、为什么智能体特别需要可观测性

传统应用的行为是确定的：同样的输入，走同样的代码路径，产生同样的结果。出了问题，看堆栈就行。

智能体不是。OpenClaw 这样的引擎，每一次任务都是一条临时决定的路径——模型自己决定调哪个工具、调几次、要不要再想一轮、什么时候停。它可能一步到位，也可能在某个工具上反复打转烧掉一大笔 token。你不盯着它，它就是个黑盒：你不知道钱花在哪、慢在哪、有没有卡死、行为正不正常。

OpenClaw 内置的 diagnostics-otel 插件，通过 OTLP 把这条黑盒路径变成结构化的遥测流；而 Elastic，是把这条遥测流变成可治理能力的那一层。本文不纠结配置命令（那几行翻文档就有），重点讲：数据进来之后，Elastic 能让你做什么。

如上图，整条链路分四层：OpenClaw 产出结构化事件 → Elastic 接入层做归一化与治理 → Elastic 的可观测性能力把它变成洞察 → 最终落到运营、生产、合规三类成果。下面顺着这条链往下讲。

二、OpenClaw 给了你哪些"可观测的抓手"

很多人接上 OTel 后第一反应是去找"对话原文"，找不到就失望。这是看错了重点。 OpenClaw 在事件总线层面默认剥离了输入输出文本（出于 PII 合规与内存安全——这其实是个优点，第五节再说）。但它吐出来的，是一套层次分明的行为事件模型，而行为，恰恰是运营最该关心的东西。

OpenClaw 分层事件模型

它的结构大致是：一次 run（完整任务）里，先有 message.processed（收到消息）和 context.assembled（组装上下文），然后进入一个多步推理循环——每一步是一次 model.call（模型推理）加若干次 tool.execution（工具执行），token 由 model.usage 单独计量；整个过程还有 liveness.warning 在旁边盯着会话有没有卡死。

每一层都回答一个具体问题：

• run —— 一次任务跑了多少步？深不深？（用 trace.id 把一次运行的所有步骤串起来）
• context.assembled —— 上下文有多臃肿？这是成本的源头。
• model.call —— 模型推理慢不慢？走的哪个模型？
• tool.execution —— 哪个工具慢、哪个工具报错？（每个工具一条独立 span，这是 OpenClaw 做得很到位的地方）
• model.usage —— token 花在哪个模型上？这是账单的真正来源。
• liveness.warning —— 哪个会话卡死或在死循环？这是个可以直接告警的信号。

两个工程上要记住的点：一是 trace.id 在 OpenClaw 里串联的是一次多步运行，是你做"会话级"分析的关联键；二是 token 和延时被拆在了不同 span上（model.usage 管 token、model.call 管延时），这是它异步计量架构的体现——算成本和算延迟要分开做。

三、Elastic 把这些数据变成能力

数据有了，价值取决于平台。Elastic 的可观测性栈，正好把上面这些抓手一个个接住：

分布式追踪 + APM 服务视图

OpenClaw 是 OTel 原生输出，进 Elastic APM 后，openclaw-gateway 直接成为一个 Service。你能看到服务地图、调用链路、延时分布（P50/P95/P99）、错误率——而且因为 trace.id 串联了一次多步运行，你能在一条 trace 的瀑布图里，看到"一次任务里模型调用和工具执行是怎么交替、谁占了大头"。这是排查"这次任务为什么慢/为什么贵"最直接的视图。

APM 服务视图

一次 run 的 trace 瀑布图

ES|QL：把任意问题变成一行查询

Elastic 的管道式查询语言 ES|QL 让你不用预先建模，就能对遥测做即席切片：按模型聚合 token、按工具排序耗时、按运行深度筛异常任务……想到什么问题，写一行就能问。它是探索阶段最趁手的工具，探索成熟的查询再沉淀成面板。

Dashboards：把洞察沉淀成常驻面板

一次性查询解决临时问题，常驻 Dashboard 解决"每天都要看"的问题。我已经把智能体的核心分析沉淀成了一个服务无关的面板——它按字段而非服务名过滤，加一个 service.name 控件就能在不同 agent 之间切换，OpenClaw 也复用同一套。

Agent 使用分析 Dashboard

机器学习异常检测：让系统自己发现"不对劲"

人盯面板有上限。Elastic 的 ML 异常检测能对 token 消耗率、模型延时、运行深度这些指标自动建立基线，一旦偏离正常范围就标出来——比如某个模型的延时突然抬升、或某次运行的步数远超平时。你不用预设阈值，它替你发现"今天和往常不一样"。

告警 + SLO：从"看见"到"被通知"

可观测性的终点不是看，是不用一直看。Elastic 的告警规则让你把关键信号变成主动通知：liveness.warning 一出现就告警、token 消耗率突增就告警、某工具错误率抬头就告警。更进一步，可以给智能体定 SLO（比如任务成功率、P95 响应时延），让"健康"有一个可度量、可承诺的标准。

AI Assistant：用自然语言问

Elastic 的 AI Agent 让你直接用中文问"过去一小时哪个工具最慢""哪次运行步数异常"，它把问题翻译成查询并给出结论——把排障的门槛从"会写查询"降到"会提问"。

四、用这些能力，把 OpenClaw 用得更好

能力是手段，下面是它直接带来的三类价值。先说运营优化——让 OpenClaw 跑得更省、更快、更稳：

• 更省：通过 model.usage 看清 token 主要花在哪个模型、哪类任务。智能体的账单几乎总是被"输入侧"主导——每一步都把不断增长的上下文重新喂一遍。看清这一点，优化的着力点就从"抠提示词字数"转到了"控制上下文累积"（裁剪历史、摘要、分段、给运行设步数上限）。
• 更快：把"模型慢"和"工具慢"分开看。用户抱怨响应慢，多半不是模型推理慢，而是某个工具（比如一次外部检索、一次记忆搜索）拖了后腿。tool.execution 的独立 span 让你一眼定位那个瓶颈工具，针对性优化或加缓存。
• 更稳：用"运行深度"分布判断行为健康度。一次任务正常是几步，如果出现远超均值的深链，配合 liveness.warning，基本就能锁定那些在反复试错、原地打转的失控运行。

做模型选型时，延时、吞吐、token 成本三个维度横向一摆，"谁快、谁省、谁稳"就清楚了——决策从拍脑袋变成看数据。

五、让 OpenClaw 达到生产与合规要求

把一个 demo 跑起来很容易，把它放进生产、过得了合规才是难点。Elastic 在这两件事上提供的，恰恰是 OpenClaw 自己给不了的。

生产就绪：四个闭环

1. 单一观测面：Trace、指标、日志在 Elastic 里统一，不用在多个工具间来回跳。
2. 告警闭环：关键信号（卡死、错误率、成本突增）主动推到 on-call，而不是等用户投诉。
3. 根因可溯：出问题时，沿 trace.id 把一次运行的完整步骤摊开，定位是哪一步、哪个工具、哪个模型出的问题。
4. 容量与趋势：长期趋势支撑容量规划与成本预测——这个 agent 的用量在涨还是在降、要不要扩容、预算够不够。

有了这四个闭环，OpenClaw 才从"能跑的脚本"变成"可运维的服务"。

合规治理：把"看不到内容"变成优势

OpenClaw 默认不外发对话内容——很多人当成缺陷，但从合规视角，这是默认即安全（privacy by default）：个人隐私信息根本不经过遥测管道，从源头消除了泄露风险。你得到的是"行为可见、内容不外泄"——既能审计智能体做了什么（调了哪些工具、跑了哪些任务、消耗多少资源），又不会把敏感对话暴露在监控系统里。

Elastic 在这个基础上还能再叠几层合规能力：

• 接入层脱敏与转换：即便将来你通过自定义插件引入了内容字段，也可以在 Ingest Pipeline 里做字段级脱敏、掩码、丢弃，让数据在落盘前就符合策略。
• 字段级访问控制：基于角色控制谁能看哪些字段——运维看指标、审计看行为、敏感内容按需授权。
• 审计留存：用生命周期管理（ILM）+ 可搜索快照，把遥测数据低成本长期留存，满足审计追溯的保留期要求，又不会让热数据成本失控。
• 数据驻留：部署在合规要求的区域，满足数据不出境等监管约束。

也就是说：OpenClaw 负责"默认不采内容"，Elastic 负责"采到的一切都可治理、可控权限、可长期审计"——两边合起来，才构成一个能过合规的智能体平台。

结语

OpenClaw 让智能体跑起来；OTel 把它的行为变成数据；而 Elastic，是把这些数据变成决策与治理能力的那一层。

接上这条链路，你得到的不只是几张好看的图表，而是三件实打实的事：把它用得更好（更省、更快、更稳）、让它上得了生产（告警闭环、根因可溯）、让它过得了合规（行为可见、内容不外泄、权限可控、审计可留）。

至于配置——那是最简单的部分。难的是想清楚：你到底想用这些数据，把你的智能体管成什么样。