Andras/BoundlessFlowCampus2K

Fork 0

Wiki documentation on choice of logger #871

New issue

Closed

opened 2026-05-11 09:00:09 +00:00 by a22erigr · 5 comments

a22erigr commented

2026-05-11 09:00:09 +00:00

Collaborator

Description

ILogger is a high-performance, structured logging API to help monitor application behavior and diagnose issues. Its basic logging providers are already built-in to ASP.NET Core
Barbecue of this ILogger is going to be used

Originally posted by @a22erigr in #856 (comment)

What should be done

We should document our choice

## Description _ILogger is a high-performance, structured logging API to help monitor application behavior and diagnose issues. Its basic **logging providers are already built-in to ASP.NET Core**_ Barbecue of this ILogger is going to be used _Originally posted by @a22erigr in https://git.webug.se/Andras/BoundlessFlowCampus2K/issues/856#issuecomment-9393_ ## What should be done + We should document our choice

a22erigr added the

project documentation

unassigned

labels

2026-05-11 09:00:21 +00:00

c24elipe was assigned by a22erigr

2026-05-11 13:32:32 +00:00

c24elipe commented

2026-05-11 13:52:46 +00:00

Collaborator

Evaluation of Logging Frameworks

Introduction

Larger and even medium projects (like this one) need logging to format timelines of events and provide general overviews of the system. But for the moment, this is done by a scattering random Console.WriteLine statemnts in the code. This does get the job done, but it is far from being even close to optimal. A selection where monitoring behaviours, diagnosing issues, and just general filtering of messages are possible is needed. A logging system would do all described and more.

Requirements

Log Levels: I most be possible to use the standard login levels (Information, Warning, Error, Debug, etc.) so that if an error happens, it can be caught as such by its login level.
Traceability: The logs should be easy to follow to the class and or service that created them.
Environment Compatibility: The logging system must work well with dotnet and Docker to be added to our stack.
Low Overhead: A giant solution isn't needed. It should be easy to use, with minimal setup and resource usage.

Options found

ILogger

ILogger is a high-performance, structured logging API to help monitor application behavior and diagnose issues. Its basic logging providers are already built-in to ASP.NET Core
ILogger is better for debugging since it adds structure and control to logging
Advantages over Console.WriteLine. ILogger can:

Structure logs
Support information, Warning, Error, Debug, etc.
Easy to filter
Logs can show which service/class created them
Consistent formatting
Designed for production apps
connect to files, databases, and dashboards.

Pros:

already included
easy to use
supports log levels
works well with Docker
Can integrate with other logging libraries later

Serilog

It is modern. Net logging library designed for structured logging and built with powerful structured event data.

Pros:

structured logs
beautiful console logs
file logging
excellent Docker support

Cons:

More setup
An extra dependency.

Conclusion

# Evaluation of Logging Frameworks ## Introduction Larger and even medium projects (like this one) need logging to format timelines of events and provide general overviews of the system. But for the moment, this is done by a scattering random **Console.WriteLine** statemnts in the code. This does get the job done, but it is far from being even close to optimal. A selection where monitoring behaviours, diagnosing issues, and just general filtering of messages are possible is needed. A logging system would do all described and more. ### Requirements * **Log Levels:** I most be possible to use the standard login levels (Information, Warning, Error, Debug, etc.) so that if an error happens, it can be caught as such by its login level. * **Traceability**: The logs should be easy to follow to the class and or service that created them. * **Environment Compatibility**: The logging system must work well with dotnet and Docker to be added to our stack. * **Low Overhead**: A giant solution isn't needed. It should be easy to use, with minimal setup and resource usage. ### Options found #### ILogger **_ILogger_** is a high-performance, structured logging API to help monitor application behavior and diagnose issues. Its basic logging providers are already built-in to ASP.NET Core **_ILogger_** is better for debugging since it adds structure and control to logging Advantages over Console.WriteLine. ILogger can: - Structure logs - Support information, Warning, Error, Debug, etc. - Easy to filter - Logs can show which service/class created them - Consistent formatting - Designed for production apps - connect to files, databases, and dashboards. ##### **Pros**: - already included - easy to use - supports log levels - works well with Docker - Can integrate with other logging libraries later #### Serilog It is modern. Net logging library designed for structured logging and built with powerful structured event data. ##### Pros: - structured logs - beautiful console logs - file logging - excellent Docker support ##### Cons: - More setup - An extra dependency. ## Conclusion _ILogger is a high-performance, structured logging API to help monitor application behavior and diagnose issues. Its basic **logging providers are already built-in to ASP.NET Core**_ The ILogger is going to be used

c24elipe added the

needs review

label

2026-05-11 13:57:41 +00:00

c22abdal was assigned by a22erigr

2026-05-12 11:03:24 +00:00

a22erigr added the

Under-review

label

2026-05-12 11:03:27 +00:00

c22abdal commented

2026-05-12 11:13:28 +00:00

Collaborator

It looks good and well structured, the choice of logging is very clear and to the point.
The reason to abandon the old Console.WriteLine is valid.

The comparison between ILogger and Serilog is clear and understandable.
The conclusion matches the project requirements well.

Questions I have:
Should this be on a wiki page?
What is this barbecue thing?

It looks good and well structured, the choice of logging is very clear and to the point. The reason to abandon the old `Console.WriteLine` is valid. The comparison between ILogger and Serilog is clear and understandable. The conclusion matches the project requirements well. Questions I have: Should this be on a wiki page? What is this barbecue thing?

c22abdal added

reviewed

and removed

needs review

labels

2026-05-12 11:13:38 +00:00

a22erigr commented

2026-05-12 11:34:57 +00:00

Author

Collaborator

@c24elipe will copy the text and place it in the wiki