Nlog: Asp.net core 2.1 issues with aspnetbufferingwrapper

[dyardyGIT]

Any issues with this wrapper and .net core? Thanks

https://stackoverflow.com/questions/51343865/nlog-with-asp-net-core-2-and-aspnetbufferingwrapper-error-not-found

[snakefoot]

It was made for ASP.NET (See also necessary editing of web.config )

https://github.com/NLog/NLog/wiki/AspNetBufferingWrapper-target

Think no one made the effort to convert it to Asp.Net.Core (or provide details for how to configure it for Asp.Net.Core)

[snakefoot]

Maybe create a ScopedTargetWrapper that reacted to BeginScope / EndScope (NDLC-scope).

Where the ScopedTargetWrapper would buffer all LogEventInfos that was created within a request-context-scope. Would require some special event to notify that the request-context-scope had completed Could just be an additional LogEventInfo outside the NDLC-scope that has LogEvent-Property configured with the same request-context-scope-id (flush-event that also could include timing metrics, only include logevents above minloglevel)

The BeginScope/EndScope could then just be setup using "middleware" (also used for request-error-logging). The "flush" logevent can then set minloglevel-property to debug-level on exception/error, and configure minloglevel-property to info-level on successful request.

[dyardyGIT]

I am a little surprised that this scenario (establishing a log for 1 http request) is not more documented/implemented with a number of log libraries. It seems like a common thing to want to log all activities(success/fail) performed within a service call.

If this is not possible with NLog what are Developers doing. Maybe I am thinking about this wrong.

Ty

[snakefoot]

@dyardyGIT You are always welcome to contribute with implementations of your good ideas.

I'm using file-grep-tools that extracts the details based on a user-token-id / request-id. So having one huge daily log-file that mixes all requests, but the user-token-id / request-id is part of each log-message.,

For me the overhead of buffering pending log-messages while waiting for the request to complete is unwanted (Becomes GC1 instead of GC0). It generates garbage-allocation that triggers unwanted stalls on garbage-collection.

[dyardyGIT]

I found this relevant article about using traceidentifier which may be next best approach https://tpodolak.com/blog/2017/02/18/asp-net-core-tracking-flow-requests-nlog/

[304NotModified]

Thanks for reporting this. This is a documentation issue as it's hasn't been ported. Closing this in favor of https://github.com/NLog/NLog.Web/issues/304