Skip to content

refactor: make tracing logs consistently structured and searchable #3476

Description

@chet

NICo already emits most service logs as logfmt, but roughly 1,500 tracing events still bury machine IDs, errors, attempts, paths, and other operational context inside message. Moving that context into named fields makes those logs consistently filterable and aggregatable without changing when or at what level an event is emitted.

What this involves

  • Sweep repo-owned Rust trace!, debug!, info!, warn!, and error! events and move dynamic operational values into stable named fields wherever the field's meaning follows cleanly from context.
  • Keep each event's static wording, level, target, parent, and existing fields intact; preserve Display, Debug, and special formatting such as alternate error chains.
  • Use established keys such as machine_id, error, attempt_number, and path instead of mechanically retaining vague local names.
  • Convert the handful of tracing::log macro imports to native tracing where needed for structured fields; direct log APIs remain out of scope.
  • Leave intentional rendered payloads, line-forwarding/helper macros, generated or external code, and values with no truthful stable event message alone, and record those exceptions in the PR.
  • Strengthen the existing STYLE_GUIDE.md logging section from a preference into the standard, including field shorthand, %/?, canonical error fields, and intentional-output exceptions.
  • Re-audit remaining interpolation and run the full lint gate plus relevant tests. This does not change log levels, introduce metrics, or migrate events to carbide_instrument::Event.

Part of #3169.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

Fields

No fields configured for Task.

Projects

Status
In Progress

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions