Enhancement for Compact JSON

[jcampaner]

The current implementation seems to yield a pretty printed output of the ECS JSON. Would it be possible to optionally configure the layout to output compact JSON?

Perhaps it would be valuable to add analogous features with the same capability and intent as those related to the "compact", "eventEol" and "endOfLine" etc settings which are available on the OEM JSONLayout.

See https://logging.apache.org/log4j/2.x/manual/layouts.html where pretty print vs compact format is discussed.

[felixbarny]

I a bit confused. There is no option for pretty printing in this library. By default, its one line per event aka nd-json.

[jcampaner]

As an example, when you have stackTraceAsArray=true and a stack trace is included in the output, multiple newline characters are included in a single event (i.e. one after each stack trace element). I was thinking that these newlines are included to make the JSON human readable.

[felixbarny]

If you don’t like the new lines just leave the setting at the default value false. Am I missing something?

[jcampaner]

I would only offer that the newlines are superfluous and perhaps mildly inefficient if the JSON is not read by a human consumer. And, also, perhaps it is confusing for consumers that the layout produces nd-json under some selected configuration options, but not under others.

As you pointed out, the expectation of the consumer by default may be one line per event. And therefore may be surprised that this is no longer the case when you configure stackTraceAsArray=true.

[felixbarny]

And, also, perhaps it is confusing for consumers that the layout produces nd-json under some selected configuration options, but not under others.

Maybe this is just a naming issue. The only reason there is a stackTraceAsArray=true is to enhance human readability. It's not really pretty printing as that usually means that the JSON is formatted so that each property is in a new line.

There is no use case where you would set stackTraceAsArray=true but have it all in one line. In fact, if you set this option, you'll have to reverse the effect with a script processor:

https://github.com/elastic/ecs-logging-java/blob/master/README.md#when-stacktraceasarray-is-enabled

        function process(event) {
            event.Put("error.stack_trace", event.Get("error.stack_trace").join("\n"));
        }

[jcampaner]

The use case would be one where the consumer software would like to persist and subsequently retrieve/custom format/present/analyze the stack in its original form (with each stack trace element as a distinctly identifiable piece of data). Yes, absolutely, you can do this as well by joining/splitting a potentially very large string on the newline character. The same end result can be achieved in the status quo implementation. However, It would be preferable to avoid a split operation on very large strings if possible. To simplify consumer adoption effort in many instances (albeit by a modest amount), giving the consumer the option to take either approach might be considered.