Review logging for 'noise'

[iancooper]

Darker may be a little noisy when logging. Brighter can be, but we tend to review and @holytshirt and I fight about what should be logged at a lower or higher level until we get some sort of consensus.

The trade-off is between diagnostically useful, and noise.

We should log something as WARN because it could become or trigger a fault
We should log something as ERROR because it is a fault, although we may take action in response.
We should log something as FATAL because something bad happened and we intend to fail fast. We rarely do this, because we don't control lifetime. Generally we ought to raise error and assume the host application decides our fault was fatal

We should INFO carefully. We used it a lot in the past for tracing but it made us noisy. We should be using it to help developers trace execution, indicating beginning and end of pipelines etc. . This level should help help folks see flow, but without the additional debug information If we have detail we should probably be DEBUG.

[colinangusmackay]

If I may add my tuppenny worth.

I feel that a library should mostly log at the DEBUG level. I don't expect to have to deal with the internal workings on a daily basis and our production services set the bar at INFO and above. For the most part, outwith development itself, I'm rarely (if ever) interested in the internal workings of a library such as Brighter or Darker, so INFO is too noisy in production, even if its just to say "I'm executing this command/query". If I do want that I have a decorator to log that kind of thing.

[holytshirt]

Thanks hopefully get a chance to look at this soon

[iancooper]

@holytshirt Feel free to pick up the ticket. No one is assigned