I take it the implicit answer is that you’d log arbitrary keys in a reusable package. Let’s agree to disagree here.
And I’m not sold even at the application-level to map all possible logging situations to some fields, without a message. I think in the end you’ll end up having either too many keys or you’ll force-fit some situations in ambiguous existing keys, both unenviable alternatives to a message. I do believe a message is useful even in structured logging.
Sorry I wasn’t more explicit. Please read Proposal: Remove log.DefaultLogger · Issue #42 · go-kit/kit · GitHub for my detailed opinions on that topic. In that thread from last year I agree with your suggestion that libraries that do make the choice to log things should allow the application to inject a minimal logging implementation. Whether that is via a function or an interface isn’t that important because either can be easily adapted to the other if needed. But I agree with @NateFinch that widely reusable packages should not log anything. I think a case can be made for closed source libraries to do some logging, but I avoid it in general.
As for structured vs. Printf-style, I agree to disagree. I recognize this is a stylistic choice and there are different opinions about it. I also think it depends on the use case for logging, which is fine. I think that accepting these differences strengthens the argument that logging is an application concern and that is the basis upon which I believe that libraries should not do logging. Applications define the use case, libraries get reused across use cases.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.