Trace Support

[derekdowling]

Hello, alooooong time ago I opened #75. I've pulled out the Trace logic and have taken suggestions from the various comments. What I've come up with is a WithTrace() fluent call similar to WithField()/WithError().

If specified, the trace will be included, otherwise it will not be computed. I've looked a lot into figuring out caller/line numbers but because there are so many variations and entry points into the API as I mentioned in the other PR, it is extremely difficult to come up with an elegant way to handle that.

I'm hoping with the smaller, more isolated PR, we can get at least this Trace logic in which will work in a bind for those who want more context as to where errors are occurring and where they are being logged from.

[derekdowling]

Hrmm, strange CI output :/

[derekdowling]

Trace ends up looking like this:

/go/src/github.com/Sirupsen/logrus/entry.go:108 +0x1d5
github.com/Sirupsen/logrus.(*Entry).Warn(0xc8200dd320, 0xc82004be98, 0x1, 0x1)
    /go/src/github.com/Sirupsen/logrus/entry.go:159 +0xa0
github.com/Sirupsen/logrus.TestDoubleLoggingDoesntPrefixPreviousFields(0xc8200e62d0)
    /go/src/github.com/Sirupsen/logrus/logrus_test.go:260 +0xb7f
testing.tRunner(0xc8200e62d0, 0x571808)
    /usr/local/Cellar/go/1.5.1/libexec/src/testing/testing.go:456 +0x98
created by testing.RunTests
    /usr/local/Cellar/go/1.5.1/libexec/src/testing/testing.go:561 +0x86d

[derekdowling]

Can someone re-run this for me? Looks like a Github error.

[sirupsen]

Thanks a lot for following up @derekdowling

Do you personally have a use-case where you only want it on some calls? Why did you chose to implement it like this instead of as a middleware?

[derekdowling]

In general I think people want stack traces when they're debugging, enough so that it should be a core feature in the logger since if you're print debugging, one typically accompanies the other. I realize that the core goal of Logrus is to be an intelligent log formatter, but typically people also use that log formatter as part of the debugging process.

Furthermore, as I mentioned in the other PR. It's really hard to get a consistent caller field saying exactly when and where Logrus was called since there are so many entry points into the library. This is a good compromise that will allow those who want to know, where exactly a log statement is coming from. As part of the criteria, I've turned the functionality off by default to avoid an efficiency penalties that would otherwise occur.

[dcelasun]

Any news on this? Builtin stack trace support would be great.

[aybabtme]

Closing since CI is failing and there's no activity. Feel free to reopen.