brokerapi.New Dictates Logging library about brokerapi HOT 7 CLOSED

Yup, that's exactly what I had in mind when I mentioned standard library. Should have been more explicit.

I can't think of any other library that even asks for a logger (I looked through the ~4 that I had on the top of my mind to check). Everything I'm familiar with elevates errors and lets the consumer log or not.

from brokerapi.

I also would like to echo @cholick's thoughts on being forced into a logger decision. I also wanted to use logrus because it's much more feature-rich than lager. lager is pretty anemic and it's session/contextual management isn't great. My use case isn't about structured logging as much as I need much better context and session management that is human-friendly for both development and deployment.

These are popular logging options which all implement log.Logger:

• github.com/sirupsen/logrus
• github.com/golang/glog
• go.uber.org/zap
• github.com/davecgh/go-spew
• github.com/ssgreg/journald

I think the ideal implementation should only require log.Logger from the stdlib and then whichever logging library consumers leverage is up to them. It's not great being forced into a library decision.

from brokerapi.

We have created an issue in Pivotal Tracker to manage this. Unfortunately, the Pivotal Tracker project is private so you may be unable to view the contents of the story.

The labels on this github issue will be updated when the story is started.

from brokerapi.

Thanks for raising this @cholick.

We chose lager as it provides structured logging, which we have heard operators find useful. I understand having logs in a mixed format isn't ideal.

I have added some details to the story to explore how we could accept a generic logger, allowing the user to provide a logger of their choosing.

from brokerapi.

As lager.Logger is an interface and, although log.Logger doesn't implement it, it is possible for consumers of brokerapi to wrap log.Logger or another logger to implement lager.Logger interface. This would allow you to control the structure of the log. Would this help?

Also, do you have any examples of other libraries that handle the "bring your own logger" scenario?

from brokerapi.

This isn't a huge deal either; if you feel that it's more hassle than it's worth, feel free to close. Motivation for filing issue was that I was paring an implementing a broker, we just got a bit frustrated that we couldn't use a more feature rich structured library like logrus that would let us trivially switch output non-structured, pretty-print logs as we were doing development.

from brokerapi.

I am going to close this for now. I feel that this problem is likely inherent to the fact that the package acts as a framework rather than a library.

If anyone has ideas / other Go frameworks that do this well, I am open to re-opening this issue.

from brokerapi.