Reputation: 3832
Using NLog I know I can change the minLevel in the Nlog.config so I can exclude certain log messages. I think this is generally great when software is running in production. If a problem happens I can switch the minLevel and see more detail. This makes sense.
What I have problems with is during debugging the "Debug" level quite honestly seems a bit inadequate. This is mostly because "Debug" seems to be the catch all for everything a developer may care about and no one else.
For backend systems that do a lot I have seen this fill up a 25 MB log file in a few seconds. Sorting through this and trying to tie pieces together is a bit difficult.
Is it possible to have multiple levels of "Debug" so that I can limit the amount of information to actually make using the log file easier?
Upvotes: 0
Views: 107
Reputation: 36750
No sure if this solves your problem,
but it's common in NLog to use the following pattern:
LogManager.GetCurrentClassLogger()
or LogManager.GetLogger("loggernameForFlow1")
)logger.Trace(...)
, logger.Debug(...)
etcfilter the logs in the config by level, but also by logger name. Because LogManager.GetCurrentClassLogger()
creates a logger with the current class name with namespace, you could easily filter per class. e.g
filter on namespace:
<logger name="myNamespace.*" minLevel=... writeTo=... />
filter on 1 class
<logger name="myNamespace.MyClass.*" minLevel=... writeTo=... />
Upvotes: 1