1

We want to use a common logging library for ASP.Net Core web applications, Azure Functions and Web Services. NLog seems like a good option since it has multiple targets e.g. Application Insights and Azure Table Storage. Ideally, I'd like to do something like call CommonTrace(message) and have that function

(1) track other information such as (a) Environment - DEV, TEST, PROD; (b) the local time, (c) System.Runtime.CompilerServices.CallerLineNumber (d) calling application etc.

(2) Call NLog to write out the message and other information. Note the other information may be prepended to the message or persisted in some other way.

But as I learn more about NLog and ASP.NET Core, it seems that if one naively creates a basic wrapper class to add additional information, one could lose out on a lot of features e.g. accessing the callsite and header information that NLog and Microsoft.Extensions.Logging provides.

So, is it possible to subclass NLog entirely and then use that wrapper as one would normally use NLog with ASP.Net Core. Or is there a better way to add common information from multiple applications when using NLog?

ekad
  • 14,436
  • 26
  • 44
  • 46
Adrian Warbeck
  • 103
  • 2
  • 6

1 Answers1

2

NLog has the ability to capture lots of context properties, without them being injected directly with the log-operation.

They are captured automatically by the Layouts configured for the NLog-target. Some NLog targets allows one to add any number of properties.

This can be seen with the NLog Application Insight Target (ver. 2.6.4), that now has the ability to add one (or more) "ContextProperty"-elements. These will automatically be included as meta-data with each log-operation:

https://github.com/Microsoft/ApplicationInsights-dotnet-logging/pull/183

If the NLog target doesn't have support for ContextProperty, then one can also turn to the NLog JsonLayout that allows one add metadata as additional Json-Attributes:

https://github.com/NLog/NLog/wiki/JsonLayout

If your favorite custom NLog target supports structured logging properties, then it should be a small change to add support for ContextProperty-elements (Easy way is to inherit from NLog TargetWithContext and just use GetAllProperties-method):

https://github.com/AlanBarber/NLog.Targets.Splunk

Rolf Kristensen
  • 17,785
  • 1
  • 51
  • 70
  • Thanks for your response. It seems that Azure Table Storage Extension (NLog.Extensions.AzureTableStorage) does not have several of the logging context capabilities (GDC, MDC, NDC) features - but Application Insights extension does. Nevertheless, the code is now injecting NLog directly to the ASP.Net Core web application rather than using a wrapper since a wrapper could hide several features (https://stackoverflow.com/questions/3825276/whats-the-point-of-a-logging-facade AND https://ardalis.com/configure-nlog-with-structuremap) – Adrian Warbeck May 27 '18 at 20:37
  • @AdrianWarbeck If you use the `JsonLayout` with `NLog.Extensions.AzureTableStorage` then you get access to MDC / MDLC. And can also output the entire NDC/NDLC-scope as a Json-attribute.. – Rolf Kristensen May 27 '18 at 20:44