Summary

With diagnostics.otel.logs: true, OpenClaw exports log records over OTLP, but every LogRecord.body is the literal string "log" instead of the formatted message, and trace_id/span_id are empty on every record. The actual message is written to stdout/logToFile but never reaches the OTLP body — only metadata attributes (openclaw.subsystem, openclaw.log.level, code.function, code.lineno) survive.

Net effect: logs in any OTLP backend are both content-free (you can't read or search what happened) and uncorrelatable (no trace_id to join them to the trace/turn). This is distinct from #77391 (that's span attribute content / captureContent); this is about the OTLP logs signal.

Version note

Confirmed present through stable 2026.6.5 and pre-release 2026.6.10-alpha.1 — no merged PR appears to address it. (#70961 "attach trace context to otel logs" is already in-tree but doesn't populate trace_id here, because these logs are emitted outside an active span context — see #50291. #91256 addresses span content capture, not log-record bodies.)

Environment

• OpenClaw 2026.5.28 (Docker); behavior reconfirmed against 2026.6.5 / 2026.6.10-alpha.1
• Exporter: OTLP http/protobuf → an OpenTelemetry Collector (otlp receiver, batch processor only, no transform/attributes processor) → an OTLP-compatible logs backend. The collector applies no log transformation, so the placeholder originates in OpenClaw.
• Relevant config:

  "diagnostics": { "enabled": true, "otel": {
    "enabled": true, "protocol": "http/protobuf", "serviceName": "<service-name>",
    "traces": true, "metrics": true, "logs": true,
    "sampleRate": 1.0, "flushIntervalMs": 10000 }}

Reproduction

openclaw config set diagnostics.otel.enabled true
openclaw config set diagnostics.otel.logs true
openclaw gateway restart --wait 30s
# trigger any error-level log (e.g. a run that hits a model fallback failure)

Then query the OTLP logs backend (or inspect the collector's raw log capture).

Observed

A representative exported LogRecord (an ERROR-severity diagnostic log):

{
  "body": "log",
  "severityText": "ERROR",
  "traceId": "",
  "spanId": "",
  "attributes": {
    "openclaw.subsystem": "diagnostic",
    "openclaw.log.level": "ERROR",
    "openclaw.logger.parents": "openclaw",
    "code.function": "logToFile",
    "code.lineno": 179
  }
}

The corresponding stdout line carries the full, actionable content that is missing from the OTLP body — e.g. a diagnostic line of the form:

[diagnostic] <event>: ... outcome=error duration=<ms>ms error="<ErrorType>: <full reason>"

A backend query of body CONTAINS "<any word from the real message>" returns 0 rows — confirming the message text never reaches the OTLP record. The code.function: "logToFile" attribute suggests the OTLP log bridge captures the call site but emits a static "log" body rather than the rendered message.

Expected

• LogRecord.body should be the rendered log message (size-capped, optionally redacted) — the same content that goes to stdout/logToFile.
• When a log is emitted within an active span context, trace_id/span_id should be populated so logs correlate to their trace/turn.

Impact

• OTLP log backends show only severity + subsystem + code location — the why of a failure is gone.
• With empty trace_id, logs can't be joined to traces or to a turn, so observability tooling can't attach log context to a finding.
• Combined with diagnostics.otel.captureContent.* is non-functional — runtime broadcast emits sanitized paramsSummary only #77391 (no span content) and Plugin Hooks: Missing trace context for observability (messageId, runId in all hooks, parentSpanId) #50291 (no trace context / parentSpanId), a consumer reading only the telemetry backend cannot reconstruct what an agent did or why it failed — even though the detail exists locally.

Related

• diagnostics.otel.captureContent.* is non-functional — runtime broadcast emits sanitized paramsSummary only #77391 — captureContent.* non-functional (span attribute content)
• Plugin Hooks: Missing trace context for observability (messageId, runId in all hooks, parentSpanId) #50291 — Plugin Hooks missing trace context (parentSpanId/runId)