Is Asp.Net Custom Logging Still Behind a Queue?

user_16241 0
Viewed 278

I have been reading up on adding your own custom logger to ASP.NET Core 3.

In reading about Microsoft's logging system, I have read that there is a queue in there to allow the log call to return quickly. (It basically records the call in the queue (and returns to the caller), then the queue passes out the messages to be persisted.)

My question is, if I add in a custom ILoggerProvider and custom ILogger, is that queue still happening when I call logger.LogDebug()?

Or is that something that I need to implement myself now that I am making a custom logger?

asp.net-core-3.1 asp.net-core logging c#
1 Answers

My question is, if I add in a custom ILoggerProvider and custom ILogger, is that queue still happening when I call logger.LogDebug()?

Or is that something that I need to implement myself now that I am making a custom logger?

If we'd like to implement custom logger and write log to some data store(s), such as SQL Db etc, which might cause performance issue if we directly write each log message to data store. To improve performance, as you mentioned, in some logging system, it writes the logs to a fast store initially, then run a background task to do the asynchronous work of writing log messages from fast store to target data store.

As the example scenario mentioned in "No asynchronous logger methods" of this doc:

For example, when logging to SQL Server, don't do so directly in a Log method, since the Log methods are synchronous. Instead, synchronously add log messages to an in-memory queue and have a background worker pull the messages out of the queue to do the asynchronous work of pushing data to SQL Server.

To create similar custom logger by implementing interface ILogger, we can integrate and use message queue as a fast store to write logs initially with custom code logic in Log method based on actual requirement.

user_67516340
Related