Skip to content

Logging Subsystem

The Logging Subsystem defines the cross-cutting contracts and shared behavior for SmrtHub logging across all runtimes (C# and Python).

This document is intentionally contract-focused. End-to-end, multi-component narratives belong in the Logging Capability (Flow) doc.

Overview & responsibilities

  • Provide a single, enterprise-grade logging posture for all SmrtHub components.
  • Enforce consistent log file layout, naming, and retention across components.
  • Ensure safe-by-default behavior (PII scrubbing/redaction) and stable, searchable structured output.
  • Provide traceability primitives (correlation IDs and W3C trace context) so cross-component work can be followed.
  • Support diagnostics workflows (including HTML export and support bundle ingestion).

Contract(s) and invariants

  • All production components must log through the canonical logging stack:
  • C#: SmrtApps/src/Smrt.Logging
  • Python: python_core.utils.logger
  • All components must write logs to canonical Operational Data locations and file naming conventions.
  • PII/sensitive data scrubbing must remain enabled by default.
  • Structured logs must remain newline-delimited JSON (one JSON object per line).

Canonical path and naming rules live in the Operational Data Policy: - SmrtHub-Operational-Data-Policy-v1.0.README.md

Integration points

  • Component authors initialize logging early at startup (before other subsystems) and use it for all diagnostics.
  • Support tooling (Support Bundle, unified HTML export) relies on canonical log locations and schemas.

Configuration, paths, and operational data

  • Log roots and naming are governed by the Operational Data Policy.
  • Component-specific logging options are governed by the Logging implementation guide.

Observability & diagnostics

  • Prefer structured logs for analysis and automated diagnostics.
  • Prefer HTML export only as a convenience view; raw logs remain the source of truth.

Security/privacy notes

  • Logs must not contain secrets.
  • PII scrubbing/redaction is required by default.

Testing & validation expectations

  • Logging changes require updating/validating tests in Smrt.Logging.Tests and any Python logger tests.
  • Changes that affect schema, file layout, or support bundle ingestion must be validated end-to-end.