title: Nservicebus disable default logger in web.config
body: <p>I'm using the DefaultFactory LogManager for Nservicebus v5. I'm happy with this but was hoping to be able to disable via the web.config. </p>
  
  <p>I use web.config settings, as found in the help docs</p>
  
  <pre><code>&lt;configSections&gt;
      &lt;section name="Logging" type="NServiceBus.Config.Logging, NServiceBus.Core" /&gt;
  &lt;/configSections&gt;
  &lt;Logging Threshold="Debug" /&gt;
  </code></pre>
  
  <p>I'd prefer not to set the threshold as fatal. I was hoping for a "None" or Disabled="true"</p>
  
  <p>Also can the directory path be set web.config?</p>
  
  <p><strong>Update: Why would we want to ignore errors?</strong></p>
  
  <p>The short is we don't really have write permission on the servers. </p>
  
  <p>The long is this isn't 100% true. 
  Our systems is moving towards microservices, the problem with this is that decentralized logging is a tracing/visualization nightmare. 
  So we moved flow tracing, exceptions, and limited tracing to a centralized system.</p>
  
  <p>Programming Entry points (aka message Handlers, web api endpoints, etc) are nearly always wrapped in a try catch log throw on each handler, this covers all our programming errors. This isn't anything really that different to normal.
  The centralized logging location sets of all the nice red flashing real time alarms one could wish for.</p>
  
  <p>Which leaves only configuration type error left like missing queues, bad assembly bindings, faulty config files, or more runtime style stuff like IoC wiring (outside of the handler code). 
  With the centralized logging and monitoring of the error quests, it is fairly easy to detect when the service is broken and if it is then we turn on logging, restart, try the faulty issue, and fix. 
  Guaranteed delivery will take care of everything else once it is up again :D Gone are the days of 150mb log files spread across 10 different servers.</p>
  
  <p>The simplicity of DefaultFactory was nice, as was not needing another nuget package and associated configuration. </p>
  
  <p>Is this the correct way forward. Many would argue no. 
  Could we have done it better? yes we could implement the common logger interface and pass it into NServiceBus but we arn't quiet there just yet and the win isn't critical atm. </p>
  
  <p>A side note: One really really nice thing about the way we log is that in our backoffice tool we have been able to simply show the flow for each "order", similar to using a correlation id in greylog. </p>