15.2 Log Format

Go To Top

Return to Logging and Observability

The team should use a consistent log format so that logs from scripts, Nodes, containers, and test tools can be inspected and compared. A consistent format also supports later automation, filtering, dashboards, and Evidence extraction.

Each log entry should include, where practical:

1. Timestamp.
2. Severity level.
3. Source component.
4. Node Identity, where applicable.
5. Runtime instance identifier, where applicable.
6. Message.
7. Event or operation name, where useful.
8. Correlation identifier, where useful.
9. Error code or exception class, where applicable.
10. Evidence or run identifier, where applicable.

A representative plain-text log entry format is:

2026-06-04T14:32:10Z INFO fx-validation-node lifecycle state=Running message="Node reached running state"

A representative structured log entry format is:

{
  "timestamp": "2026-06-04T14:32:10Z",
  "level": "INFO",
  "component": "fx-validation-node",
  "nodeRole": "ValidationNode",
  "event": "LifecycleStateChanged",
  "state": "Running",
  "message": "Node reached running state"
}

The team may use plain-text logs for simple Phase 0 scripts and structured logs for Nodes or acceptance Evidence. If the team uses more than one format, the relevant script, Node, or container documentation should identify the format and its purpose.

Severity levels should have consistent meanings:

1. DEBUG records detailed diagnostic information for development or troubleshooting.
2. INFO records non-significant events.
3. WARN records unexpected or degraded conditions that do not immediately stop execution.
4. ERROR records failures that prevent a requested operation or Node behavior from completing normally.
5. FATAL records unrecoverable failures that force process termination or make the Node unsafe to continue.