refactor(dataviewer): migrate 24 print() calls to structured logging with uvicorn integration #131

Work Stream WS-19: Backend Logging Migration

Description

Replace 24 print() calls across backend modules with logging.getLogger(__name__) and configure structured logging with uvicorn integration. Ensure all modules use appropriate log levels (DEBUG, INFO, WARNING, ERROR) based on the nature of the output.

Issues addressed

1. A-09 (MEDIUM): 24 print() calls used for diagnostic output — not capturable by log aggregation, no severity levels, no timestamps
2. A-11 (LOW): No structured logging configuration — when logging is used, it lacks consistent format and uvicorn integration

Findings Addressed

Acceptance Criteria

• Zero print() statements in src/dataviewer/backend/ production code (test code excluded)
• Every backend module uses logger = logging.getLogger(__name__) at module level
• Log calls use appropriate severity levels:
  • DEBUG for detailed diagnostic information
  • INFO for normal operational messages (startup, request handling, config loading)
  • WARNING for recoverable issues or degraded operation
  • ERROR for failures that need attention
• Logging configuration integrates with uvicorn's log format and handlers (no duplicate output)
• Log format includes: timestamp, level, logger name, and message at minimum
• Ruff rule T201 (print found) enabled for src/dataviewer/backend/ and passing

Implementation Notes

• Module-level logger pattern:

  import logging
  
  logger = logging.getLogger(__name__)

• Mapping print() to logging:
  • print(f"Loading config...") → logger.info("Loading config from %s", path)
  • print(f"Error: {e}") → logger.error("Failed to process: %s", e)
  • print(f"DEBUG: {value}") → logger.debug("Value: %s", value)
• Uvicorn integration: configure in the FastAPI app startup or via logging.config.dictConfig() that matches uvicorn's formatters
• Use %s style formatting in log calls (not f-strings) to allow lazy evaluation
• Enable Ruff rule T201 in pyproject.toml for the dataviewer backend path

Related Issues

• Tracking issue: feat(dataviewer): build & lint remediation — tracking issue #115
• Upstream dependencies: feat(dataviewer): add security middleware stack to FastAPI backend #118 (WS-05), WS-06 (needs dedicated issue), refactor(dataviewer): harden detection service with model path allowlist and bounded cache #119 (WS-07), refactor(dataviewer): fix async I/O, add retry policy, and unify storage adapter interfaces #120 (WS-08), refactor(dataviewer): centralize config, add dependency injection, and fix async patterns in backend services #125 (WS-13)
• Complements: refactor(dataviewer): audit and remediate 53 broad exception handlers across backend services #130 (WS-18) — exception handling audit introduces audit logging, this work stream establishes the logging foundation

Migrated from Azure-Samples/azure-nvidia-robotics-reference-architecture#400