Summary
Add a --diagnostics CLI option that writes timestamped diagnostic logs to a file, enabling users to capture shell activity for troubleshooting, performance analysis, and auditing.
Motivation
Currently, CosmosDBShell has limited observability:
- --verbose only controls exception detail level (full stack trace vs. message-only)
- Output redirection (> / >>) captures command output but not execution metadata
- There is no way to trace command execution timing, connection events, or internal errors
Users debugging query performance (RU charges, latency), troubleshooting connectivity, or auditing command history have no built-in mechanism to capture this information.
Proposed Behavior
cosmosdbshell --diagnostics # log to default path in config directory
cosmosdbshell --diagnostics mylog.log # log to a custom file path
When enabled, write a structured log file containing:
- Session metadata — timestamp, machine name, OS, runtime version
- Command execution — every command with timestamp
- Command results — OK/FAIL status with elapsed time (milliseconds)
- Errors — exception type and message for failed commands
- Connection events — endpoint URL and connection mode
Sample Output
# CosmosDB Shell Diagnostic Log
# Started: 2026-06-10T14:30:00.0000000-07:00
# Machine: DEVBOX
# OS: Microsoft Windows NT 10.0.22631.0
# Runtime: 9.0.0
--------------------------------------------------------------------------------
[14:30:01.234] [CONNECT ] https://myaccount.documents.azure.com:443/ (mode=Direct)
[14:30:02.456] [CMD ] dir
[14:30:02.789] [RESULT ] [OK] 333.2ms | dir
[14:30:05.100] [CMD ] cat nonexistent
[14:30:05.102] [ERROR ] cat nonexistent -> ShellException: Item not found
[14:30:05.102] [RESULT ] [FAIL] 2.1ms | cat nonexistent
Summary
Add a --diagnostics CLI option that writes timestamped diagnostic logs to a file, enabling users to capture shell activity for troubleshooting, performance analysis, and auditing.
Motivation
Currently, CosmosDBShell has limited observability:
Users debugging query performance (RU charges, latency), troubleshooting connectivity, or auditing command history have no built-in mechanism to capture this information.
Proposed Behavior
When enabled, write a structured log file containing:
Sample Output