.NET Core – Lowering The Log Level Of 3rd Party Components 

With the new .NET Core framework and libraries we have got an interface called Microsoft.Extensions.Logging.ILogger to be used for writing log messages. Various 3rd party and built-in components make very good use of it. To see how much is being logged just create a simple Web API using Entity Framework (EF) and the Kestrel server and in a few minutes you will get thousands of log messages.

In diesem Artikel:

.NET Core – Lowering The Log Level Of 3rd Party Components 
Pawel Gerr ist Architekt und Consultant bei Thinktecture. Er hat sich auf .NET Core Backends spezialisiert und kennt Entity Framework von vorne bis hinten.

The downside of such a well-known interface is that the log level chosen by the 3rd party developers may be unfitting for the software using it. For example, Entity Framework uses the log level Information for logging generated SQL queries. For the EF developers it is a good choice because the SQL query is an important information for them – but for our customers using EF this information is for debugging purposes only.

Luckily it is very easy to change the log level of a specific logging source (EF, Kestrel etc.). For that we need a simple proxy that implements the interface ILogger. The proxy is changing the log level to Debug in the methods Log and IsEnabled and calls the corresponding method of the real logger with new parameters.

				
					public class LoggerProxy : ILogger
{
	private readonly ILogger _logger;

	public LoggerProxy(ILogger logger)
	{
		if (logger == null)
			throw new ArgumentNullException(nameof(logger));

		_logger = logger;
	}

	public void Log(LogLevel logLevel, int eventId, object state, 
		Exception exception, Func<object, Exception, string> formatter)
	{
		if (logLevel > LogLevel.Debug)
			logLevel = LogLevel.Debug;

		_logger.Log(logLevel, eventId, state, exception, formatter);
	}

	public bool IsEnabled(LogLevel logLevel)
	{
		if (logLevel > LogLevel.Debug)
			logLevel = LogLevel.Debug;

		return _logger.IsEnabled(logLevel);
	}

	public IDisposable BeginScopeImpl(object state)
	{
		return _logger.BeginScopeImpl(state);
	}
}
				
			

To inject the LoggerProxy we have to create another proxy that implements the interface Microsoft.Extensions.Logging.ILoggerFactory. The method we are interested in is CreateLogger that gets the category name as a parameter. The category name may be the name of the class requesting the logger or the name of the assembly. In this method we make the real logger factory create a logger for us and if this logger is for Entity Framework we return our LoggerProxy wrapping the real logger.

				
					public class LoggerFactoryProxy : ILoggerFactory
{
	private readonly ILoggerFactory _loggerFactory;
	
	public LogLevel MinimumLevel
	{
		get { return _loggerFactory.MinimumLevel; }
		set { _loggerFactory.MinimumLevel = value; }
	}

	public LoggerFactoryProxy(ILoggerFactory loggerFactory)
	{
		if (loggerFactory == null)
			throw new ArgumentNullException(nameof(loggerFactory));

		_loggerFactory = loggerFactory;
    }

	public ILogger CreateLogger(string categoryName)
	{
		var logger = _loggerFactory.CreateLogger(categoryName);

		if (categoryName.StartsWith("Microsoft.Data.Entity.", StringComparison.OrdinalIgnoreCase))
			logger = new LoggerProxy(logger);

		return logger;
    }

	public void AddProvider(ILoggerProvider provider)
	{
		_loggerFactory.AddProvider(provider);
	}

	public void Dispose()
    {
		_loggerFactory.Dispose();
	}
}
				
			

Finally, we need to register the factory proxy with the dependency injection container.

				
					public void ConfigureServices(IServiceCollection services)
{
	var factory = new LoggerFactoryProxy(new LoggerFactory());
	services.AddInstance(factory);
}

				
			

For now on the log messages coming from Entity Framework will be logged with the log level Debug.

Kostenloser
Newsletter

Aktuelle Artikel, Screencasts, Webinare und Interviews unserer Experten für Sie

Verpassen Sie keine Inhalte zu Angular, .NET Core, Blazor, Azure und Kubernetes und melden Sie sich zu unserem kostenlosen monatlichen Dev-Newsletter an.

Diese Artikel könnten Sie interessieren
.NET
Incremental Roslyn Source Generators: High-Level API – ForAttributeWithMetadataName – Part 8

Incremental Roslyn Source Generators: High-Level API – ForAttributeWithMetadataName – Part 8

With the version 4.3.1 of Microsoft.CodeAnalysis.* Roslyn provides a new high-level API - the method "ForAttributeWithMetadataName". Although it is just 1 method, still, it addresses one of the biggest performance issue with Source Generators.
16.05.2023
.NET
Integrating AI Power into Your .NET Applications with the Semantic Kernel Toolkit – an Early View

Integrating AI Power into Your .NET Applications with the Semantic Kernel Toolkit – an Early View

With the rise of powerful AI models and services, questions come up on how to integrate those into our applications and make reasonable use of them. While other languages like Python already have popular and feature-rich libraries like LangChain, we are missing these in .NET and C#. But there is a new kid on the block that might change this situation. Welcome Semantic Kernel by Microsoft!
03.05.2023
.NET
.NET 7 Performance: Regular Expressions – Part 2

.NET 7 Performance: Regular Expressions – Part 2

There is this popular quote by Jamie Zawinski: Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems."

In this second article of our short performance series, we want to look at the latter one of those problems.
25.04.2023
.NET
.NET 7 Performance: Introduction and Runtime Optimizations – Part 1

.NET 7 Performance: Introduction and Runtime Optimizations – Part 1

.NET 7 is fast. Superfast. All the teams at Microsoft working on .NET are keen to improve the performance and do so every year with each new .NET release. Though this time the achievements are really impressive. In this series of short articles, we want to explore some of the most significant performance updates in .NET and look at how that may affect our own projects. This first article is taking a deep look under the hood of the compiler and the runtime to look for some remarkably interesting and significant updates.
28.03.2023
.NET
Incremental Roslyn Source Generators: Using Additional Files – Part 7

Incremental Roslyn Source Generators: Using Additional Files – Part 7

In the previous article the Source Generator itself needed a 3rd-party library Newtonsoft.Json in order to generate new source code. The JSON-strings were hard-coded inside the Source Generator for simplicity reasons. In this article we will see how to process not just .NET code, but also other files, like JSON or XML.
21.03.2023
.NET
Understanding and Controlling the Blazor WebAssembly Startup Process

Understanding and Controlling the Blazor WebAssembly Startup Process

There are a lot of things going on in the background, when a Blazor WebAssembly application is being started. In some cases you might want to take a bit more control over that process. One example might be the wish to display a loading screen for applications that take some time for initial preparation, or when users are on a slow internet connection. However, in order to control something, we need to understand what is happening first. This article takes you down the rabbit hole of how a Blazor WASM application starts up.
07.03.2023