Add an option to override stacktrace collection logic

[zllak]

Stacktrace collection

While trying to implement an encoder that is compatible with GCP Stackdriver logging and also for GCP Stackdriver Error Reporting, I suspected that it's not working properly because the generated stacktrace is not compatible with what Error Reporting is expected.

The documentation says (https://cloud.google.com/error-reporting/docs/formatting-error-messages): Go: Must be the return value of runtime.Stack()

The code in go sources (cloud.google.com/go/errors/errors.go) shows that cloud.google.com/go/errors.(*Client).logInternal indeed calls runtime.Stack.

Unfortunately, the stack is grabbed by trackStacktrace in stracktrace.go, and there is apparently no other way around to provide the stracktrace.

Unless I'm missing something, we cannot provide the way the stacktrace is grabbed by zap

[akshayjshah]

There's no way to customize this now, but I don't mind adding an option for this. We could make a zap.Option that takes a func() string and overrides the current stacktrace-snapping functionality.

However, this wouldn't affect the output of the zap.Stack field if it's used explicitly - the user would have to use some alternate field for stackdriver compatibility.

[djui]

(I don't want to hijack this issue but would rather like to add a similar question and ask for a recommendation) Besides adding an option for the stacktrace-snapping functionality, is it currently already possible to modify the stack trace output? Would it work by implementing a zapcore.Encoder?

We would like to trim off some stacks that are not adding much to the signal and are rather noise.

I know trimming stacks is a inherently difficult task, but I would at least like to go give our heuristic a try.

[evanj]

FWIW: It is possible to wrap the existing JSON encoder to hack stack traces. I've done this to format stacks so they get picked up by Google Cloud's Stackdriver Error Report (where it needs to look like a "real" panic). It would be much nicer to have a customization hook similar to EncoderConfig.EncodeTime, but this is possible today. See: https://github.com/evanj/gcplogs/blob/master/gcpzap/encoder.go#L48

[FlorianLoch]

Any progress/change of mind regarding adding support for the mentioned zap.Option allowing a custom function to provide the stack trace? That would be very handy to have ;)

[sywhang]

@FlorianLoch nope, the issue is still a valid ask and we welcome PRs!