You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Scenario:
I tried extending the pipeline with System.Web.HttpContext.Current (NET FX) information on event creation in something like log4net input.
This is currently a problem, because filters execute without context information (I assume this is because of TPL DataFlow setup), so the initial context is lost.
Moreover, System.Web.HttpContext is NET FX specific, so instead of having a netstandard-based log4net input, and an NET FX-specific input filter that would execute on the same thread with all context information as log4net appender.
I know with log4net, one can hook into global.asax's events, and add ThreadContext information, but I think it is bad design - it scatters data enrichment all over the code (HttpContext is just one type of information).
I suppose one could hack their own inputs, based on existing ones, but that goes against composability.
I see great opportunity in input enrichers, because you could also add domain-specific information more easily for ingest by output receivers like AI, without having a dedicated log4net input, that differs per application. Adding domain-specific information to events speeds up investigations by A LOT :)
The text was updated successfully, but these errors were encountered:
Scenario:
I tried extending the pipeline with System.Web.HttpContext.Current (NET FX) information on event creation in something like log4net input.
This is currently a problem, because filters execute without context information (I assume this is because of TPL DataFlow setup), so the initial context is lost.
Moreover, System.Web.HttpContext is NET FX specific, so instead of having a netstandard-based log4net input, and an NET FX-specific input filter that would execute on the same thread with all context information as log4net appender.
I know with log4net, one can hook into global.asax's events, and add ThreadContext information, but I think it is bad design - it scatters data enrichment all over the code (HttpContext is just one type of information).
I suppose one could hack their own inputs, based on existing ones, but that goes against composability.
I see great opportunity in input enrichers, because you could also add domain-specific information more easily for ingest by output receivers like AI, without having a dedicated log4net input, that differs per application. Adding domain-specific information to events speeds up investigations by A LOT :)
The text was updated successfully, but these errors were encountered: