Configuration for formatting Throwable stack traces

I’d like to see more options for how stack traces are formatted in the ECS logs to help in reducing the size of logs.

Some examples:

1. Maximum depth
2. Include/exclude stack frames based on a pattern
3. Shorten class names by abbreviating package names to fit within a specified length
4. Root cause first or last

Ideally a configuration option could override the formatting of the stack trace through an interface implementation provided by the application. That implementation could return a String[] or Stream<String> of the formatted stack frames which are then added to the ECS log either as a JSON string or an array of strings.

I’d be happy to work on a PR for this if there is interest in it being included.

[michaelmcfadyensky]

I found the easiest way to integrate this is to reuse the existing ThrowableHandlingConverter interface that comes with logback. This allows us to plug in any existing implementation of this interface with out having the re-implement it for this specific encoder. Though the downside is that this solution is specific to the logback encoder.

This commit solved the issue I highlighted in my comment above for the logback encoder. I know this may not be the solution you guys would want to go with but it would be good to get feedback on it.

[HaloFour]

@rdifrango

I also would like to see this feature and I wonder if there’s a way to tap into the existing capabilities of logback and log4j2 as they already support syntax that is roughly:

I’ve started this PR to allow specifying a pattern to be applied when rendering error.stack_trace that allows you to use one of the built-in converters or to use your own: https://github.com/elastic/ecs-logging-java/pull/177