跳转到内容

日志概述

OpenClaw 在两个位置记录日志:

  • 文件日志(JSON 行),由 Gateway(网关) 网关 写入。
  • 控制台输出,显示在终端和控制 UI 中。

本页面说明了日志的存储位置、读取方法,以及如何配置日志 级别和格式。

默认情况下,Gateway(网关) 网关 会在以下路径写入滚动日志文件:

/tmp/openclaw/openclaw-YYYY-MM-DD.log

日期使用网关主机的本地时区。

您可以在 ~/.openclaw/openclaw.json 中覆盖此设置:

{
"logging": {
"file": "/path/to/openclaw.log"
}
}

使用 CLI 通过 RPC 追踪网关日志文件:

Terminal window
openclaw logs --follow

输出模式:

  • TTY 会话:美观、彩色、结构化的日志行。
  • 非 TTY 会话:纯文本。
  • --json:行分隔的 JSON(每行一个日志事件)。
  • --plain:在 TTY 会话中强制使用纯文本。
  • --no-color:禁用 ANSI 颜色。

在 JSON 模式下,CLI 会发出带有 type 标记的对象:

  • meta:流元数据(文件、游标、大小)
  • log:已解析的日志条目
  • notice:截断/轮换提示
  • raw:未解析的日志行

如果 Gateway(网关) 网关 无法访问,CLI 会打印一条简短提示以运行:

Terminal window
openclaw doctor

控制 UI 的 日志 (Logs) 选项卡使用 logs.tail 追踪同一个文件。 有关如何打开它的信息,请参阅 /web/control-ui

要过滤通道活动(WhatsApp/Telegram/等),请使用:

Terminal window
openclaw channels logs --channel whatsapp

日志文件中的每一行都是一个 JSON 对象。CLI 和控制 UI 会解析这些 条目以呈现结构化输出(时间、级别、子系统、消息)。

控制台日志是 支持 TTY 的,并针对可读性进行了格式化:

  • 子系统前缀(例如 gateway/channels/whatsapp
  • 级别着色(信息/警告/错误)
  • 可选的紧凑或 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 格式(用于日志处理器)。

工具摘要可以在敏感令牌输出到控制台之前对其进行编辑:

  • logging.redactSensitive: off | tools(默认:tools
  • logging.redactPatterns: 用于覆盖默认集合的正则表达式字符串列表

编辑仅影响控制台输出,不会改变文件日志。

诊断是针对模型运行以及消息流遥测(webhooks、队列、会话状态)的结构化、机器可读事件。它们替代日志;它们的存在是为了为指标、跟踪和其他导出器提供数据。

诊断事件在进程内发出,但只有当诊断和导出器插件都启用时,导出器才会附加。

  • OpenTelemetry (OTel):用于跟踪、指标和日志的数据模型 + SDK。
  • OTLP:用于将 OTel 数据导出到收集器/后端的线路协议。
  • OpenClaw 目前通过 OTLP/HTTP (protobuf) 导出。
  • Metrics:计数器 + 直方图(令牌使用情况、消息流、队列)。
  • Traces:用于模型使用和 webhook/消息处理的 spans。
  • 日志 (Logs):当启用 diagnostics.otel.logs 时,通过 OTLP 导出。日志 量可能很大;请考虑 logging.level 和导出器过滤器。

模型使用情况:

  • model.usage:令牌、成本、持续时间、上下文、提供商/模型/渠道、会话 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:聚合计数器。

如果您希望插件或自定义接收器可以使用诊断事件,请使用此选项:

{
"diagnostics": {
"enabled": true
}
}

使用标志开启额外的、定向的调试日志,而无需提高 logging.level。 标志不区分大小写并支持通配符(例如 telegram.**)。

{
"diagnostics": {
"flags": ["telegram.http"]
}
}

环境覆盖(一次性):

OPENCLAW_DIAGNOSTICS=telegram.http,telegram.payload

注意事项:

  • 标志日志进入标准日志文件(与 logging.file 相同)。
  • 输出仍根据 logging.redactSensitive 进行编辑。
  • 完整指南:/diagnostics/flags

可以通过 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/protobufgrpc 会被忽略。
  • 指标包括令牌使用量、成本、上下文大小、运行时长以及消息流 计数器/直方图(webhooks、排队、会话状态、队列深度/等待)。
  • 可以通过 traces / metrics 切换跟踪/指标(默认:开启)。启用后, 跟踪包括模型使用跨度以及 webhook/消息处理跨度。
  • 当您的收集器需要身份验证时,请设置 headers
  • 支持的环境变量:OTEL_EXPORTER_OTLP_ENDPOINT, OTEL_SERVICE_NAME, OTEL_EXPORTER_OTLP_PROTOCOL

模型使用情况:

  • openclaw.tokens (计数器,属性:openclaw.tokenopenclaw.channelopenclaw.provideropenclaw.model
  • openclaw.cost.usd (计数器,属性:openclaw.channelopenclaw.provideropenclaw.model
  • openclaw.run.duration_ms (直方图,属性:openclaw.channelopenclaw.provideropenclaw.model
  • openclaw.context.tokens (直方图,属性:openclaw.contextopenclaw.channelopenclaw.provideropenclaw.model

消息流:

  • openclaw.webhook.received (计数器,属性:openclaw.channelopenclaw.webhook
  • openclaw.webhook.error (计数器,属性:openclaw.channelopenclaw.webhook
  • openclaw.webhook.duration_ms (直方图,属性:openclaw.channelopenclaw.webhook
  • openclaw.message.queued (counter, attrs: openclaw.channel, openclaw.source)
  • openclaw.message.processed (counter, attrs: openclaw.channel, openclaw.outcome)
  • openclaw.message.duration_ms (histogram, attrs: openclaw.channel, openclaw.outcome)

队列 + 会话:

  • openclaw.queue.lane.enqueue (counter, attrs: openclaw.lane)
  • openclaw.queue.lane.dequeue (counter, attrs: openclaw.lane)
  • openclaw.queue.depth (histogram, attrs: openclaw.laneopenclaw.channel=heartbeat)
  • openclaw.queue.wait_ms (histogram, attrs: openclaw.lane)
  • openclaw.session.state (counter, attrs: openclaw.state, openclaw.reason)
  • openclaw.session.stuck (counter, attrs: openclaw.state)
  • openclaw.session.stuck_age_ms (histogram, attrs: openclaw.state)
  • openclaw.run.attempt (counter, attrs: openclaw.attempt)
  • openclaw.model.usage
    • openclaw.channel, openclaw.provider, openclaw.model
    • openclaw.sessionKey, openclaw.sessionId
    • openclaw.tokens.* (input/output/cache_read/cache_write/total)
  • openclaw.webhook.processed
    • openclaw.channel, openclaw.webhook, openclaw.chatId
  • openclaw.webhook.error
    • openclaw.channel, openclaw.webhook, openclaw.chatId, openclaw.error
  • openclaw.message.processed
    • openclaw.channel, openclaw.outcome, openclaw.chatId, openclaw.messageId, openclaw.sessionKey, openclaw.sessionId, openclaw.reason
  • openclaw.session.stuck
    • openclaw.stateopenclaw.ageMsopenclaw.queueDepthopenclaw.sessionKeyopenclaw.sessionId
  • 链路采样:diagnostics.otel.sampleRate(0.0–1.0,仅限根 Span)。
  • 指标导出间隔:diagnostics.otel.flushIntervalMs(最少 1000ms)。
  • 可以通过 diagnostics.otel.endpointOTEL_EXPORTER_OTLP_ENDPOINT 设置 OTLP/HTTP 端点。
  • 如果端点已包含 /v1/traces/v1/metrics,则将按原样使用。
  • 如果端点已包含 /v1/logs,则日志将按原样使用。
  • diagnostics.otel.logs 为主日志记录器输出启用 OTLP 日志导出。
  • OTLP 日志使用写入 logging.file 的相同结构化记录。
  • 遵守 logging.level(文件日志级别)。控制台脱敏 适用于 OTLP 日志。
  • 大流量部署应优先选择 OTLP 收集器采样/过滤。
  • 无法连接 Gateway(网关) 网关? 首先运行 openclaw doctor
  • Logs empty? 检查 Gateway(网关) 是否正在运行并写入 logging.file 中的文件路径。
  • 需要更多详细信息?logging.level 设置为 debugtrace 并重试。