adamcavendish opened a new issue, #1040: URL: https://github.com/apache/rocketmq-clients/issues/1040
### Programming Language of the Client Rust ### Is Your Feature Request Related to a Problem? Yes. The RocketMQ client currently uses the slog crate for logging, which presents several limitations in both usability and flexibility. Specifically: 1. slog solution now only allows configuration as a terminal logger or writing logs to a JSON file. 2. File logging now is configured as a hardcoded absolute path within the library. Reducing portability and ease of use. 3. Configuration of logging behavior must happen inside the RocketMQ library itself, rather than being left to the application using the client. In contrast, the tracing crate provides a much cleaner and flexible setup that can be configured entirely by the main application binary. This enables better separation of concerns, dynamic filtering, and support for modern observability backends — all without requiring RocketMQ itself to manage logging configuration. ### Describe the Solution You'd Like I would like to migrate the RocketMQ client logging system from slog to the tracing ecosystem. tracing is designed specifically for performance-sensitive applications and supports: - Structured, event-based diagnostics - Spans for tracking the lifecycle of operations - Contextual data propagation - Integration with distributed tracing backends (e.g., OpenTelemetry, Jaeger) This migration will improve observability by enabling developers and operators to better trace message flows, debug failures, and monitor performance across RocketMQ clients and brokers. ### Describe Alternatives You've Considered 1. Continue using slog: This would avoid any breaking changes but limits future extensibility and observability. 2. Use both slog and tracing: While possible but adds complexity and overhead without significant benefit. 3. Introduce a new logging abstraction layer: This could allow switching implementations at runtime but would increase maintenance burden and delay adoption of tracing features. Given the maturity of the tracing ecosystem and its alignment with modern Rust practices and tooling, migrating directly to tracing appears to be the most forward-looking and maintainable option. ### Additional Context _No response_ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
