How do you deal with frameworks you are using are logging on their own? I think it is a little odd that I always turn them off, and what intention e.g. Microsoft have when both logging and throwing an Exception?
If I do not turn it off, the IT Operations that maintain the solution, would get false positives when a retry solves a transient error.
Actually I also often turn off NSB logging, knowing that IT operations is monitoring the error-queue. Is this good practice as well?
@Stig_Christensen I would not turn of logging of warnings, errors and fatals of NServiceBus.* as they can contain information about startup/configuration and runtime issues.
The logs provide details that can help diagnose problems. Often the exception isn’t sufficient to resolve problems. So I agree, ops should primarily act on the error queue and not on the log file.
The fact that some libraries will write ERROR log entries isn’t problematic. Especially as these days we also have distributed tracing. Tracing combined with logging gives lots of contextual insight on failures. The fact that some collected log entries are ERROR’s of FATAL’s doesn’t really matter but are very useful for diagnosing.
Let’s assume that due to recoverability messages never go to the error queue but the logs are full of warnings due to timeouts. Suppressing these would not be wise as these indicate for example slow database queries due to incorrect indexes or slow remote API’s.
If there are very chatty components you can always suppress these for a specific log level.
Thanks for your reponse.
I agree very much, but what do I tell the IT Operations to monitor?
You should know that my process is running both a Web API and a MessageHandler. I want IT Operations to monitor the error queue and all errors from the Web API. That is why I turn off Entity Framework and NSB in the Event Log, used by IT Operations for monitoring the service. The Web API will then properly log the error on any exception thrown by e.g. Entity Framework
IT Operations should not create a Incident Ticket on every transient DB error, solved by a later retry. 