How to use properly the logger in a mid-size project

[jairoareyes]

Hi. First of all thanks for your amazing work.

Currently, I'm working on a mid-size project. I want to start using this tool. However, I'm still thinking about the best way to use it. I would like to define if I should set up and create an instance of logger at main, and inject that instance (probably a shared_prt) in the constructors of my classes. Some of those classes have sub-classes, create other classes' objects, etc. I also have some threads that run constantly and others run on demand.

Another option is to use the method get_logger. But I am not sure if this library is a singleton, every time that I call get_logger returns the same original instance.

What are your recommendations for a mid-size already deployed project? Thanks in advance.

[odygrd]

Hey, yes library is using a singleton and the logger_name is the key. Once you create the Logger you will get the same logger with get_logger. You do not need to use shared_ptr the logging library owns the logger and the logger itself is thread safe.
Just note that get_logger takes a lock so it’s recommended to store the logger*

the recommended way is

https://github.com/odygrd/quill/tree/master/examples/recommended_usage

you create a wrapper library where you include Backend.h only in the .cpp file. There you handle starting the backend thread. Since the library is header only that will handle compiling all the heavy stuff and you won’t need to include the backend headers anywhere else.

after this it’s pretty much your own choice. You can either have an export static Logger* which you set on main and include everywhere else as in the example, or you can include Frontend.h and call get_logger eg. in the constructor of your classes and store it.

having more than one Logger offers greater control for parts of the application so i would personally create one per different component. This allows to change the log level and have one component on debug log and the other on info for example

I prefer the export static Logger* than storing it in each class as it takes additional space eg when you have a vector<Object> and also it’s less code than doing it for each class

in some cases tho it is worth doing it when additional control is needed, or example you have two instances of a class Foo, one instance that is used by component A and one instance used by component B. In that case i would pass logger_a when component A created Foo and logger_b for component B in Foo construction. That way i can see in the log via the logger name which component is actually using Foo and issuing the log and also will be able to have different log levels per component as mentioned above

once you set it up also please see how to log different types

https://quillcpp.readthedocs.io/en/latest/cheat_sheet.html

hope all of this makes sense! If you have any questions let me know

[jairoareyes]

Thanks for your answer. I'll implement it and check if new questions arise in the process.

I have additional questions: Is changing the log level in runtime possible? how is it evaluated at the log level? As far as I understand there is a log-scale. But I'd like to know more about how this is evaluated. Is there a conditional evaluation (if/switch-case)? How is it optimized for runtime? Thanks in advance.

[odygrd]

Changing the log_level is per Logger instance logger->set_log_level(LogLevel) and it is thread safe

It is evaluated with an if statement. If the branch is not taken, then any arguments to the LOG_ won’t be evaluated

quill/quill/include/quill/LogMacros.h

Line 276 in e177e33

if (likelyhood(logger->template should_log_statement<log_level>())) \

if you don’t want the branches you can disable the log level completely in compile time by defining QUILL_COMPILE_ACTIVE_LOG_LEVEL either as compilation flag or before including LogMarcos.h

quill/quill/include/quill/LogMacros.h

Line 36 in e177e33

#define QUILL_COMPILE_ACTIVE_LOG_LEVEL -1

[jairoareyes]

Hi again, thanks for your answers.

I have 2 more additional questions:

1. How can I mock a logger for unit testing? I set up a general instance, and get a logger instance in the constructor of every class I need it.
2. Can two different logger instances save logs in the same file? I wonder if this is thread-safe and if there is some overlapping-avoid mechanism.

Thanks.

[odygrd]

1. For unit testing if you don’t care about the logs you don’t need to start the backend thread as long as your class is not calling internally logger->flush(); so set up the Logger* when the test starts in the generic instance but never start the backend thread. The test will still push the logs to the queue but they will never be processed. As long as you push less than ~4Gb of logs in the same test binary it will never block.

If you don’t have other static objects using the Logger in their constructors in your application it’s safe to just do the below which also automatically inits it for testing

global_logger.h

extern Logger* root_logger;

global_logger.cpp

Logger* root_logger = Frontend::create_or_get_logger(
"root", Frontend::create_or_get_sinkquill::ConsoleSink("sink_1"),
"%(time) [%(thread_id)] %(short_source_location:<28) "
"LOG_%(log_level:<9) %(message)",
"%H:%M:%S.%Qns", quill::Timezone::LocalTime);

the above always inits the global logger during static initialisation time

2. Yes multiple different logger instances can save to the same file and it’s also thread safe to use the same logger instance from multiple threads. There is a single thread the backend worker thread that is gathering all the messages and writing them to the file