1. OpenClaw 智能体跑在阿里云上为什么日志总像一团黑箱OpenClaw 智能体在阿里云 ECS 上跑起来之后最让人头疼的不是它不工作而是它工作得太安静。你问它一句话它背后可能触发了三次模型调用、两次技能执行、一次外部 API 请求但你在终端里只看到最后一行结果。中间发生了什么、哪一步慢了、哪次调用烧了多少钱全靠猜。这就是可观测性缺失的典型症状。OpenClaw 作为一个能自主编排工具链的智能体框架它的执行路径是动态的同一个用户请求可能因为上下文不同而走完全不同的技能组合。没有日志服务 SLS 的支撑你面对的就是一个黑箱——出错了不知道哪一步断的变慢了不知道哪个环节卡的账单涨了不知道哪个模型吃的。阿里云日志服务 SLS 在这里扮演的角色就是给 OpenClaw 装一套透视系统。它能把智能体运行过程中散落在 stdout、文件、容器日志里的结构化事件统一采集、索引、查询和告警。你不需要自己搭 ELK也不需要写复杂的采集脚本Logtail 代理加上几段配置就能跑通。这篇文章面向的是已经在阿里云上部署了 OpenClaw、或者正准备部署的开发者。我会从日志字段设计开始一步步给出可复制的 SLS 采集配置、OpenClaw 侧的结构化日志输出改造、查询分析语句、告警规则骨架以及验证整条监控链路是否生效的具体操作。全程不涉及任何网络访问工具所有操作都在阿里云控制台和 ECS 内部完成。2. 前置准备TaoToken 接入与 SLS 资源开通OpenClaw 本身不绑定特定模型供应商它通过 OpenAI 兼容接口调用后端模型。如果你希望智能体的模型调用链路稳定、密钥管理集中可以用 TaoToken 作为统一接入层。它的 API 地址是https://taotoken.net/api兼容 OpenAI SDK 的base_url参数OpenClaw 的模型配置里直接填这个地址即可。在开始配置 SLS 之前你需要先拿到 TaoToken 的 API Key。访问https://taotoken.net/api-keys创建一个密钥复制保存。这个 Key 后面会写进 OpenClaw 的环境变量同时也会作为日志脱敏的重点对象——任何情况下都不应该让完整 Key 出现在 SLS 的原始日志里。SLS 侧需要准备三样东西一个 Project、一个 Logstore、一台已经安装 Logtail 的 ECS 实例。Project 是 SLS 的顶层资源隔离单元建议按环境划分比如openclaw-prod、openclaw-staging。Logstore 是日志的存储和查询单元OpenClaw 的日志建议单独建一个 Logstore不要和系统日志混在一起方便后续做字段索引和告警。创建 Project 和 Logstore 的入口在阿里云日志服务控制台。Project 创建时选择和你 ECS 相同的地域减少跨地域传输延迟。Logstore 创建时注意两个参数Shard 数量按写入量估算初期 2 个足够数据保存时间按合规要求设置调试阶段 7 天即可生产环境建议 30 天以上。Logtail 的安装命令在 Logstore 的「数据接入」向导里可以一键复制。如果你用命令行安装大致形式如下# 在 ECS 上执行替换 region、project、logstore 为实际值 wget https://logtail-release-region.oss-region-internal.aliyuncs.com/linux64/logtail.sh chmod x logtail.sh ./logtail.sh install region安装完成后Logtail 会以系统服务形式运行配置文件目录在/usr/local/ilogtail/。你可以用systemctl status ilogtail确认服务状态。这一步不需要开放任何公网入站端口Logtail 是主动向外连接 SLS 服务端的。3. 可复制配置OpenClaw 结构化日志输出与 SLS 采集3.1 OpenClaw 侧日志格式改造SLS 的查询分析能力建立在结构化字段之上。如果 OpenClaw 输出的是纯文本日志SLS 只能做全文检索无法按字段聚合和告警。所以第一步是让 OpenClaw 输出 JSON 行日志。OpenClaw 的日志输出通常可以通过环境变量或配置文件控制。以常见的 Python 实现为例你可以用structlog或标准库logging配合jsonformatter。核心是保证每条日志是一个独立的 JSON 对象一行一条包含以下关键字段{ timestamp: 2025-01-15T10:23:45.123Z, level: INFO, log_type: model_invoke, trace_id: trace_1736936625123_a8f3c, session_id: sess_9b2e1, model: qwen3.5-plus, input_tokens: 1024, output_tokens: 256, duration_ms: 2340, cost: 0.0087, status: success }对于技能执行日志log_type设为skill_run额外带上skill名称、duration_ms、status。对于异常日志log_type设为error带上error_type和error_message。在 OpenClaw 的模型调用封装层里每次请求前后记录时间戳请求返回后计算duration_ms从响应体的usage字段提取 token 数。如果你用的是 TaoToken 的 API响应格式和 OpenAI 一致usage.prompt_tokens和usage.completion_tokens可以直接映射到input_tokens和output_tokens。3.2 SLS Logtail 采集配置在 SLS 控制台进入 Logstore 的「数据接入」→「Logtail 配置」选择「JSON 模式」。配置内容如下{ inputs: [ { type: file, detail: { LogPath: /var/log/openclaw, FilePattern: *.log, LogType: json, TopicFormat: default, Preserve: true, PreserveDepth: 1 } } ], processors: [ { type: processor_json, detail: { SourceKey: content, NoKeyError: true, ExpandConnector: true } }, { type: processor_mask, detail: { Fields: [api_key, authorization, token], MaskWith: *** } } ] }这段配置做了三件事从/var/log/openclaw目录采集所有.log文件把每行 JSON 展开成 SLS 的独立字段对api_key、authorization、token三个字段做脱敏替换。脱敏处理器必须放在 JSON 展开之后否则字段还没被解析出来脱敏不会生效。配置保存后Logtail 会在 30 秒内自动加载新配置。你可以在 ECS 上执行tail -f /usr/local/ilogtail/ilogtail.LOG观察采集日志确认没有报错。3.3 字段索引配置采集配置生效后还需要在 Logstore 的「查询分析」→「索引」里为关键字段建立索引。建议开启的字段包括log_type、trace_id、session_id、model、skill、status、duration_ms、cost、input_tokens、output_tokens。其中log_type、model、skill、status设为「键值索引」其余数值字段设为「数值索引」。索引配置是查询分析的前提。没有索引select语句里的where log_type model_invoke会退化成全量扫描查询慢且消耗扫描量。4. 验证监控链路从写入到查询的完整闭环4.1 确认日志写入在 ECS 上手动触发一次 OpenClaw 的模型调用比如执行一个简单的对话请求。然后回到 SLS 控制台的 Logstore 查询页面输入以下查询语句* | select count(*) as total, log_type group by log_type如果配置正确你应该能看到model_invoke、skill_run等类型的计数。如果查询结果为空先检查 Logtail 是否在运行、日志文件路径是否正确、JSON 格式是否合法。4.2 模型调用趋势查询确认数据写入后用下面这条查询验证模型调用的 token 消耗和延迟分布* | select date_trunc(minute, __time__) as time, count(*) as invokes, sum(cast(json_extract_scalar(body, $.input_tokens) as bigint)) as input_tokens, sum(cast(json_extract_scalar(body, $.output_tokens) as bigint)) as output_tokens, approx_percentile(cast(json_extract_scalar(body, $.duration_ms) as bigint), 0.95) as p95_latency where log_type model_invoke group by time order by time注意这里用了json_extract_scalar从body字段提取。如果你的 Logtail 配置里 JSON 已经展开成独立字段可以直接用字段名不需要json_extract_scalar。两种方式取决于你的采集配置。4.3 技能执行耗时分布* | select json_extract_scalar(body, $.skill) as skill, approx_percentile(cast(json_extract_scalar(body, $.duration_ms) as bigint), 0.5) as p50, approx_percentile(cast(json_extract_scalar(body, $.duration_ms) as bigint), 0.95) as p95, count(*) as runs where log_type skill_run group by skill order by p95 desc这条查询能帮你快速定位哪个技能是延迟大户。如果某个技能的 p95 超过 10 秒就需要检查它的内部实现是否有阻塞操作。4.4 异常率监控* | select date_trunc(minute, __time__) as time, count(*) as total, sum(case when log_type error then 1 else 0 end) as errors, 100.0 * sum(case when log_type error then 1 else 0 end) / count(*) as error_rate group by time order by time这条查询输出每分钟的异常率。正常情况下 error_rate 应该低于 1%。如果持续高于 5%说明 OpenClaw 的某个环节存在系统性问题。4.5 告警规则骨架在 SLS 的「告警」页面创建告警规则查询语句用上面的异常率查询触发条件设为error_rate 5检查频率 1 分钟连续触发 3 次后发送通知。通知渠道可以选钉钉机器人、短信或邮件。告警规则的 YAML 骨架大致如下alert: name: openclaw_error_rate_high query: | * | select count(*) as total, sum(case when log_type error then 1 else 0 end) as errors, 100.0 * sum(case when log_type error then 1 else 0 end) / count(*) as error_rate condition: error_rate 5 window: 5m frequency: 1m notify: - type: dingtalk webhook: https://oapi.dingtalk.com/robot/send?access_token***高延迟告警和成本突增告警可以用类似的骨架把查询语句换成对应的 p95 延迟查询和小时成本聚合查询。5. 本篇常见错排查5.1 Logtail 采集不到日志最常见的原因是日志文件路径不匹配。Logtail 的LogPath是目录FilePattern是文件名通配符。如果你写的是/var/log/openclaw/*.log作为 LogPathLogtail 会把它当成目录处理导致采集失败。正确做法是LogPath填/var/log/openclawFilePattern填*.log。另一个原因是文件权限。Logtail 以ilogtail用户运行如果日志文件的属主是 root 且权限是 600Logtail 读不到。用chmod 644或把 ilogtail 加入文件所属组。5.2 JSON 解析失败如果日志里混有非 JSON 行比如 OpenClaw 启动时的 banner 输出processor_json会报NoKeyError。在采集配置里加上NoKeyError: true可以跳过解析失败的行但更好的做法是在 OpenClaw 侧把非结构化输出重定向到单独的文件只让 JSON 日志进入采集目录。5.3 查询结果为空但日志已写入先确认索引是否已开启。SLS 的查询分析依赖索引没有索引的字段在select里不可用。在 Logstore 的「索引」页面检查log_type等字段是否已配置。索引配置生效有 1 分钟左右的延迟。5.4 脱敏不生效脱敏处理器必须放在 JSON 展开之后。如果你的采集配置里processor_json和processor_mask的顺序反了脱敏会作用在原始文本上而原始文本里字段名是嵌套的匹配不到。调整顺序即可。5.5 告警不触发检查告警规则的查询时间窗口和检查频率。如果窗口是 5 分钟、频率是 1 分钟但你的日志量很小5 分钟内可能只有几条日志error_rate的计算基数太小波动大。可以适当放宽窗口到 15 分钟或者改用绝对数量作为触发条件。6. 长期运行与 Coding Plan 的配合OpenClaw 的监控链路跑通之后你会发现日志数据本身也能反哺智能体的优化。比如通过分析model_invoke日志里不同模型的调用占比和成本分布你可以调整 OpenClaw 的模型路由策略简单任务走轻量模型复杂推理走高性能模型。这种分层调用策略在 SLS 的查询结果里一目了然。如果你需要长期运行 OpenClaw 并持续迭代它的技能和模型配置TaoToken 的 Coding Plan 提供了适合开发阶段的额度方案。访问https://taotoken.net/coding-plan可以查看当前的套餐详情。配合 SLS 的监控数据你能清楚地看到每一份额度花在了哪个技能、哪个模型上而不是凭感觉调整。模型对话调试可以直接在https://taotoken.net/model-chat里进行方便你对比不同模型在相同 prompt 下的输出差异再决定 OpenClaw 的路由规则。接入文档在https://taotoken.net/doc里面有 OpenAI SDK 兼容层的完整参数说明。整套监控链路的核心思路是让 OpenClaw 的每一次模型调用、每一次技能执行都留下结构化痕迹SLS 负责采集、索引、查询和告警。你不需要一开始就追求大而全的仪表板先把model_invoke和error两类日志采起来跑通查询和告警再逐步补充技能耗时和成本分析。监控体系是长出来的不是一次设计出来的。