日志
OpenClaw 的日志输出在两个地方:
- 文件日志(JSON 行格式),由 Gateway 写入。
- 控制台输出,显示在终端和控制面板中。
本页介绍日志存放位置、如何查看,以及如何配置日志级别和格式。
日志存放位置
默认情况下,Gateway 会在以下路径写入滚动日志文件:
/tmp/openclaw/openclaw-YYYY-MM-DD.log
日期使用 Gateway 主机的本地时区。
你可以在 ~/.openclaw/openclaw.json 中覆盖此路径:
{
"logging": {
"file": "/path/to/openclaw.log"
}
}
如何查看日志
CLI:实时跟踪(推荐)
使用 CLI 通过 RPC 实时跟踪 Gateway 日志文件:
openclaw logs --follow
输出模式:
- TTY 会话:格式化的、带颜色的结构化日志行。
- 非 TTY 会话:纯文本。
--json:逐行 JSON(每行一个日志事件)。--plain:在 TTY 会话中强制使用纯文本。--no-color:禁用 ANSI 颜色。
在 JSON 模式下,CLI 输出带 type 标签的对象:
meta:流元数据(文件、游标、大小)log:解析后的日志条目notice:截断/轮转提示raw:未解析的日志行
如果 Gateway 不可达,CLI 会给出提示,建议运行:
openclaw doctor
控制面板(Web)
控制面板的 Logs 标签页通过 logs.tail 接口跟踪同一个文件。
打开方式详见 /web/control-ui。
仅渠道日志
要过滤特定渠道的活动(WhatsApp/Telegram 等),使用:
openclaw channels logs --channel whatsapp
日志格式
文件日志(JSONL)
日志文件中每行都是一个 JSON 对象。CLI 和控制面板会解析这些条目,渲染结构化的输出(时间、级别、子系统、消息)。
控制台输出
控制台日志感知 TTY 环境,格式针对可读性优化:
- 子系统前缀(如
gateway/channels/whatsapp) - 按级别着色(info/warn/error)
- 可选紧凑模式或 JSON 模式
控制台格式通过 logging.consoleStyle 控制。
配置日志
所有日志配置都在 ~/.openclaw/openclaw.json 的 logging 下。
{
"logging": {
"level": "info",
"file": "/tmp/openclaw/openclaw-YYYY-MM-DD.log",
"consoleLevel": "info",
"consoleStyle": "pretty",
"redactSensitive": "tools",
"redactPatterns": ["sk-.*"]
}
}
日志级别
logging.level:文件日志(JSONL)的级别。logging.consoleLevel:控制台的详细程度。
你可以通过 OPENCLAW_LOG_LEVEL 环境变量覆盖这两个级别(如 OPENCLAW_LOG_LEVEL=debug)。环境变量优先于配置文件,这样你可以在单次运行时提高详细程度,不用改 openclaw.json。你也可以传入全局 CLI 选项 --log-level <level>(例如 openclaw --log-level debug gateway run),它会覆盖该命令的环境变量设置。
--verbose 只影响控制台输出,不改变文件日志级别。
控制台样式
logging.consoleStyle:
pretty:人类友好的格式,带颜色和时间戳。compact:更紧凑的输出(适合长会话)。json:每行 JSON(供日志处理器消费)。
脱敏
工具摘要可以在输出到控制台前脱敏敏感 token:
logging.redactSensitive:off|tools(默认tools)logging.redactPatterns:正则字符串列表,覆盖默认规则集
脱敏仅影响控制台输出,不会修改文件日志。
诊断 + OpenTelemetry
诊断是结构化的、机器可读的事件,覆盖模型运行和消息流遥测(webhook、队列、会话状态)。它们不替代日志,而是用来喂给指标、追踪和其他导出器。
诊断事件在进程内发出,但导出器只在诊断功能和导出器插件都启用时才会挂载。
OpenTelemetry 与 OTLP
- OpenTelemetry(OTel):追踪、指标和日志的数据模型 + SDK。
- OTLP:用于将 OTel 数据导出到收集器/后端的传输协议。
- OpenClaw 目前通过 OTLP/HTTP(protobuf) 导出。
导出的信号
- 指标:计数器 + 直方图(token 用量、消息流、队列)。
- 追踪:模型使用 + webhook/消息处理的 span。
- 日志:启用
diagnostics.otel.logs后通过 OTLP 导出。日志量可能很大,注意logging.level和导出器过滤设置。
诊断事件目录
模型使用:
model.usage:token 数、费用、耗时、上下文、提供商/模型/渠道、会话 ID。
消息流:
webhook.received:按渠道的 webhook 入站。webhook.processed:webhook 已处理 + 耗时。webhook.error:webhook 处理器错误。message.queued:消息入队等待处理。message.processed:结果 + 耗时 + 可选错误。
队列 + 会话:
queue.lane.enqueue:命令队列通道入队 + 深度。queue.lane.dequeue:命令队列通道出队 + 等待时间。session.state:会话状态变更 + 原因。session.stuck:会话卡住警告 + 已等待时间。run.attempt:运行重试/尝试元数据。diagnostic.heartbeat:聚合计数器(webhook/队列/会话)。
启用诊断(不带导出器)
如果你只想让诊断事件对插件或自定义 sink 可用:
{
"diagnostics": {
"enabled": true
}
}
诊断标志(定向日志)
使用标志可以开启额外的定向调试日志,而不用提高 logging.level。标志不区分大小写,支持通配符(如 telegram.* 或 *)。
{
"diagnostics": {
"flags": ["telegram.http"]
}
}
环境变量覆盖(一次性):
OPENCLAW_DIAGNOSTICS=telegram.http,telegram.payload
注意事项:
- 标志产生的日志写入标准日志文件(即
logging.file指定的路径)。 - 输出仍然按
logging.redactSensitive进行脱敏。 - 完整指南:/diagnostics/flags。
导出到 OpenTelemetry
诊断数据可以通过 diagnostics-otel 插件(OTLP/HTTP)导出。兼容任何接受 OTLP/HTTP 的 OpenTelemetry 收集器/后端。
{
"plugins": {
"allow": ["diagnostics-otel"],
"entries": {
"diagnostics-otel": {
"enabled": true
}
}
},
"diagnostics": {
"enabled": true,
"otel": {
"enabled": true,
"endpoint": "http://otel-collector:4318",
"protocol": "http/protobuf",
"serviceName": "openclaw-gateway",
"traces": true,
"metrics": true,
"logs": true,
"sampleRate": 0.2,
"flushIntervalMs": 60000
}
}
}
注意事项:
- 也可以用
openclaw plugins enable diagnostics-otel启用插件。 protocol目前仅支持http/protobuf。grpc会被忽略。- 指标包含 token 使用、费用、上下文大小、运行耗时,以及消息流的计数器/直方图(webhook、队列、会话状态、队列深度/等待时间)。
- 追踪/指标可通过
traces/metrics开关(默认开启)。追踪在启用时包含模型使用 span 和 webhook/消息处理 span。 - 收集器需要认证时,设置
headers。 - 支持的环境变量:
OTEL_EXPORTER_OTLP_ENDPOINT、OTEL_SERVICE_NAME、OTEL_EXPORTER_OTLP_PROTOCOL。
导出的指标(名称 + 类型)
模型使用:
openclaw.tokens(counter,属性:openclaw.token、openclaw.channel、openclaw.provider、openclaw.model)openclaw.cost.usd(counter,属性:openclaw.channel、openclaw.provider、openclaw.model)openclaw.run.duration_ms(histogram,属性:openclaw.channel、openclaw.provider、openclaw.model)openclaw.context.tokens(histogram,属性:openclaw.context、openclaw.channel、openclaw.provider、openclaw.model)
消息流:
openclaw.webhook.received(counter,属性:openclaw.channel、openclaw.webhook)openclaw.webhook.error(counter,属性:openclaw.channel、openclaw.webhook)openclaw.webhook.duration_ms(histogram,属性:openclaw.channel、openclaw.webhook)openclaw.message.queued(counter,属性:openclaw.channel、openclaw.source)openclaw.message.processed(counter,属性:openclaw.channel、openclaw.outcome)openclaw.message.duration_ms(histogram,属性:openclaw.channel、openclaw.outcome)
队列 + 会话:
openclaw.queue.lane.enqueue(counter,属性:openclaw.lane)openclaw.queue.lane.dequeue(counter,属性:openclaw.lane)openclaw.queue.depth(histogram,属性:openclaw.lane或openclaw.channel=heartbeat)openclaw.queue.wait_ms(histogram,属性:openclaw.lane)openclaw.session.state(counter,属性:openclaw.state、openclaw.reason)openclaw.session.stuck(counter,属性:openclaw.state)openclaw.session.stuck_age_ms(histogram,属性:openclaw.state)openclaw.run.attempt(counter,属性:openclaw.attempt)
导出的 Span(名称 + 关键属性)
openclaw.model.usageopenclaw.channel、openclaw.provider、openclaw.modelopenclaw.sessionKey、openclaw.sessionIdopenclaw.tokens.*(input/output/cache_read/cache_write/total)
openclaw.webhook.processedopenclaw.channel、openclaw.webhook、openclaw.chatId
openclaw.webhook.erroropenclaw.channel、openclaw.webhook、openclaw.chatId、openclaw.error
openclaw.message.processedopenclaw.channel、openclaw.outcome、openclaw.chatId、openclaw.messageId、openclaw.sessionKey、openclaw.sessionId、openclaw.reason
openclaw.session.stuckopenclaw.state、openclaw.ageMs、openclaw.queueDepth、openclaw.sessionKey、openclaw.sessionId
采样与刷新
- 追踪采样:
diagnostics.otel.sampleRate(0.0–1.0,仅根 span)。 - 指标导出间隔:
diagnostics.otel.flushIntervalMs(最小 1000ms)。
协议说明
- OTLP/HTTP 端点可通过
diagnostics.otel.endpoint或OTEL_EXPORTER_OTLP_ENDPOINT设置。 - 如果端点已包含
/v1/traces或/v1/metrics,则原样使用。 - 如果端点已包含
/v1/logs,日志导出也原样使用。 diagnostics.otel.logs用于启用主日志输出的 OTLP 日志导出。
日志导出行为
- OTLP 日志使用与写入
logging.file相同的结构化记录。 - 遵循
logging.level(文件日志级别)。控制台脱敏不适用于 OTLP 日志。 - 高流量实例应优先使用 OTLP 收集器侧的采样/过滤。
故障排查提示
- Gateway 不可达? 先运行
openclaw doctor。 - 日志为空? 检查 Gateway 是否正在运行,并且确认
logging.file指定的路径确实在写入。 - 需要更多细节? 将
logging.level设为debug或trace,然后重试。