Concept for Pluggable Log Backend Configuration

[Taqman-probe]

📌 Resources

Branch: feature/change-to-tracing
https://github.com/Taqman-probe/aralez/tree/feature/change-to-tracing

🎯 Issues

The system is likely to attract significant attention, and the requirements—including logging—are expected to continue growing indefinitely.
Examples of anticipated logging requirements:

• Rotation periods and file sizes
• Number of files to retain and compression logic
• Duplication to standard output
• JSON-formatted output
• OpenTelemetry support
• etc...

💡 Proposal

1. **Unify all configuration settings other than log_file into a single log_config

   • Allow users to implement complex requirements themselves

2. A pluggable mechanism similar to Caddy’s module system

   • Allow Rustacean users to develop their own implementations
   • Enable via features flags
   • Keep the core logic in a maintainable state
   • Allow user-provided implementations to be added in parallel

🔧 What's New in This Commit

• Changed from log4rs to tracing for scalability
• Defined in the default_interface::LoggerModule trait
• custom_logger module (template for user implementations)
• Can be toggled via a feature flag

📔The Future of “Aralez,” Built Together with the Community

Based on the feature/change-to-tracing branch I recently committed, I’d like to offer some proposals from a broader perspective regarding the future scalability of logging and other features.

We anticipate that requirements for logging will continue to grow. Rotation periods and sizes, compression logic, duplication to standard output, JSON conversion, and OpenTelemetry support...

In fact, if you look at the official plugin (Module) list for Caddy —known for its high extensibility as a reverse proxy—, there are currently 31 modules related to logging alone. This fact illustrates just how diverse user requirements for logging are, and the reality that it is impossible to incorporate all of them as core features. If we were to simply keep adding all these configuration values to the configuration file, it is obvious that the configuration options would eventually become bloated and the application would break down.

Here's a suggestion.

Just as Caddy has gained remarkable flexibility through its module system, I believe this project also needs a “swappable mechanism.”
A world where Rustacean users can implement their own backends to suit their specific requirements and easily switch between them using features flags.
I believe this is the optimal solution for safely testing a wide range of user requirements while maintaining the core logic.

As a first step, I defined the default_interface::LoggerModule trait and implemented the foundation to enable the custom_logger module -which serves as a template for user implementations- to be toggled via a features flag.

To use a metaphor that inspired me: this architecture feels exactly like an Armenian illuminated manuscript.
The core text remains sacred and unalterable, while different creators can run rich, beautiful, and experimental expressions in the margins, eventually binding them into one single, feature-rich masterpiece.

To evolve this aralez into an even more robust piece of software that combines a solid core with flexible customization options, we’d like to hear your thoughts on this move toward a plugin-based approach.

[sadoyan]

Interesting thoughts. Let's think about implementing it .

[Taqman-probe]

Thank you for the positive feedback! I'm really excited to move forward with this.

Since you're open to exploring this, what are your initial thoughts on the scope? For instance, do you think we should focus strictly on the logging system first as a pilot, or should we design the module system with other future extensions (like auth or storage) in mind?

First, I wrote a log output logic based on file size rotation.
https://github.com/Taqman-probe/aralez/blob/main/custom_logger/src/lib.rs