Azure

Study NLog Superior Utilization

Logging is a necessary a part of the appliance, particularly within the case if you wish to monitor site visitors speaking with an exterior consumer that’s having some issues connecting to your web site.

For instance a really obscure error is occurring with regard to third-party software program you might be utilizing, and the software program supplier is asking you for a log.

So, the answer is easy, add a logging element like NLog and log to a file by configuring the nlog.config file. However many instances, it is not so simple as that.

What in case your utility is a multi-tenant deployment, and what if you cannot modify nlog.config or appsettings.json after the deployment is finished, and you could quickly allow the Debug logging or any short-term logging for that matter?

If we simply add an NLog to the multi-tenant utility with 5 purchasers, then all 5 purchasers will begin writing logs in the identical location, be it a file or a database. And what if the deployed code is just not doable to change (like a read-only zipped model)?

There’s a answer for the entire above. NLog libraries present all the required options to resolve the entire above issues.

The very best half is that NLog means that you can use a brand new occasion of NLog per every request and means that you can modify it only for this scope (per request).

Let’s deal with the problems one after the other.

To begin, we’re going to use a middleware to set the NLog in a generic method.

In it, we’ll set all of the dynamic properties particular to the tenant. In my case, they’re

a DB connection string; logger filters for particular libraries (like Microsoft,ThirdPartyLib,Nlog.API, and every part(*))

Within the Nlog.config file, we set the logger like the next code (please word mdlc:Nlog_mainDebug). That is the one option to modify the logger dynamically – through the use of ‘filters’ tag.

For loggers

<logger identify="Nlog.API*" minlevel="Debug" writeTo="dbTarget" ><!--only works if Nlog_mainDebug is Sure-->
        <filters defaultAction="Log">
            <when situation="'${mdlc:Nlog_mainDebug}' != 'Sure'" motion="Ignore" /><!--comparisson is case-sensetive-->
        </filters>
</logger>

For the database goal we set a connectionString with a dynamic variable (please word mdlc:NLog_DbCon).

<goal xsi:sort="Database"
identify="dbTarget"
connectionString="${mdlc:NLog_DbCon}"
commandText="INSERT INTO NLogs(CreatedOn,Message,Degree,Exception,StackTrace,Logger,Url)
            VALUES (@datetime,@msg,@degree,@exception,@hint,@logger,@url)"
            >
        <parameter identify="@datetime" structure="${date}" />
        <parameter identify="@msg" structure="${message}" />
        <parameter identify="@degree" structure="${degree}" />
        <parameter identify="@exception" structure="${exception}" />
        <parameter identify="@hint" structure="${stacktrace}" />
        <parameter identify="@logger" structure="${logger}" />
        <parameter identify="@url" structure="${aspnet-request-url}" />
</goal>

Within the middleware, the properties are set to particular values (TenantMiddleware.cs).

NLog.ScopeContext.PushProperty("Nlog_Microsoft",Constants_NLogMicrosoft);
NLog.ScopeContext.PushProperty("Nlog_ThirdPartyLib", Constants_NLogThirdPartyLib);
NLog.ScopeContext.PushProperty("Nlog_mainDebug", Constants_NLogMainDebug);
NLog.ScopeContext.PushProperty("Nlog_mainWarning", Constants_NLogMainWarning);
NLog.ScopeContext.PushProperty("Nlog_EverythingElseWarn", Constants_NLogEverythingElseWarn);
NLog.ScopeContext.PushProperty("NLog_DbCon", connectionString);

On this pattern, the connection string is static, however it may be retrieved based mostly on the present area + subdomain dynamically. Relying on the subdomain, the connection string might fluctuate.

The identical is true for the logger enabling. The supply of the values might be dynamic (like a database).

Testing

Attempt Cool, Incredible, and WeatherForecast APIs.

In consequence, it’s best to see the database rows.

APIs

There are doable a number of situations. And this is a number of.

Scenarios

The supply code is connected, and extra particulars may be discovered within the Nlog Multi-tenant Technique.txt file contained in the mission. Cheers!

Know extra about our firm at Skrots. Know extra about our companies at Skrots Providers, Additionally checkout all different blogs at Weblog at Skrots

Show More

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top button