Include performance info in separate fields

[maihacke]

I changed our PerformanceLogFilter to show how #39 can be solved.

Currently the information is logged twice, once in the original form separated by ; and now additionally in separate fields. I kept the original format for backwards compatibility. If this is not required it is changed quite easily.

The new implementation will created logs like this:

{"timestamp":"2020-02-10T14:36:54.299+00:00","message":"http://localhost:8081/services/rest/binary/v1/binaryobject/;21;200;;","logger_name":"com.devonfw.module.logging.common.impl.PerformanceLogFilter","thread_name":"http-nio-8081-exec-7","level":"INFO","url":"http://localhost:8081/services/rest/binary/v1/binaryobject/","duration":21,"statuscode":200,"errorClass":"","errorMessage":"","appname":"rootArtifactId_IS_UNDEFINED"}

(prettyfied)

{ 
   "timestamp":"2020-02-10T14:36:54.299+00:00",
   "message":"http://localhost:8081/services/rest/binary/v1/binaryobject/;21;200;;",
   "logger_name":"com.devonfw.module.logging.common.impl.PerformanceLogFilter",
   "thread_name":"http-nio-8081-exec-7",
   "level":"INFO",
   "url":"http://localhost:8081/services/rest/binary/v1/binaryobject/",
   "duration":21,
   "statuscode":200,
   "errorClass":"",
   "errorMessage":"",
   "appname":"rootArtifactId_IS_UNDEFINED"
}

[hohwille]

@maihacke Awesome that you found a solution for this. 👍 So if you write the message in a particular syntax/format then it is understood by the encoder when writing the JSON so he emits according custom fields. By using StructuredArguments you are using the official API to write the required format. That is a great improvement.
You were saying that you still write the old message in your comment but I can see that in the code.
I do not mind that but just wanted to understand if that is a mistake...

[hohwille]

BTW: we seem to mix different styles for our property names:

• lowercase
• camlCase
• lower_underscore_case

Can we align this? Also we should think about a balance of very short but still explanatory property names. One can question if JSON is a reasonable format for logs as it is massively causing redundancies since every log entry has the same structure but always includes the names of each property. This is kind of nuts. We should try to keep the property names short.

[hohwille]

• I think url is perfect, we can not be shorter and still descriptive (except for chaning to path and omitting http(s)://host:port/context-path prefix to shorten log, but I would not really suggest this, maybe in some environment there are different URLs to access the same logical path).
• duration is fine but maybe ms or millis would be even more precise as duration could also be in nanoseconds or seconds.
• For statuscode maybe status (or even sc)?
• For errorClass and errorMessage I only see abbreviations as other options so e.g. errMsg but in relation to message that is already given, it does not make much more sense...

[maihacke]

• I think url is perfect, we can not be shorter and still descriptive (except for chaning to path and omitting http(s)://host:port/context-path prefix to shorten log, but I would not really suggest this, maybe in some environment there are different URLs to access the same logical path).
• duration is fine but maybe ms or millis would be even more precise as duration could also be in nanoseconds or seconds.
• For statuscode maybe status (or even sc)?
• For errorClass and errorMessage I only see abbreviations as other options so e.g. errMsg but in relation to message that is already given, it does not make much more sense...

Good hint, I changed the names accordingly