Details
-
Improvement
-
Status: Open
-
Major
-
Resolution: Unresolved
-
2.13.0
-
None
-
None
Description
In our project, we're attempting to use Log4J2 for structured logging. Our production logs are sent to an ElasticSearch where developers can subsequently search the logs using Kibana.
One of the key value propositions to using structured logging for us is that a developer can change the log statement to write new JSON content such that the ES will automatically index it and it will automatically be made available to Kibana - the ops team doesn't need to get involved, and doesn't need to modify any FileBeat or other components to change the parsing logic and create new JSON fields on the ES side.
To realize this value, we need to have an API that allows the user to easily determine what to log. Right now, Log4j2 only supports ObjectMessages with the JSONLayout if you want the message to be an actual JSON object when written out. This means that every message to be logged must be a concrete Java bean object to be passed to ObjectMessage. I have to create a lot of Java classes just to represent these objects which is overly verbose.
A nicer solution would be to have special handling if the object wrapped by ObjectMessage is a javax.json.JsonObject, or if the message is a MapMessage. In both cases, I expected that the "message" of the JSON object produced by the JsonLayout would be a JSON object (since I have objectMessageAsJsonObject set to true).
For example, I would expect the following to produce a JSON object as the "message" produced by the JsonLayout:
LOG.debug(() -> new MapMessage<>().with("iaId", iaId).with("item", item));
I would also expect the following to produce a JSON object as the "message":
LOG.info(() -> new ObjectMessage(Json.createObjectBuilder()
.add("iaId", iaId)
.add("item", item)));