Open zeitlinger opened 4 months ago
Thanks @zeitlinger .
Would you by any chance have an example for the produced JSON payload?
To map the Logback json exception to the OpenTelemetry exception.*
, we would need to map the following otel attributes:
exception.message
: The exception message. E.g. Division by zero
; Can't convert 'int' object to str implicitly
exception.stacktrace
: A stacktrace as a string in the natural representation for the language runtime. The representation is to be determined and documented by each language SIG.exception.type
: The type of the exception (its fully-qualified class name, if applicable). The dynamic type of the exception should be preferred over the static type in languages that support it. E.g. java.net.ConnectException
I didn't see in your code the json fields for exception.message
and exception.type
, did I miss something?
https://opentelemetry.io/docs/specs/semconv/attributes-registry/exception/
I had in mind that the "raw stack trace" could reuse the throwable
JSON field and just replace the stepArray
subfield by a stackTrace
field.
Something like:
CURRENT
...
"throwable": {
"className": "java.lang.RuntimeException",
"message": "Fraud detected",
"stepArray": [
{
"className": "com.mycompany.antifraud.FraudDetectionController",
"methodName": "checkOrder",
"fileName": "FraudDetectionController.java",
"lineNumber": 121
},
...
{
"className": "java.lang.Thread",
"methodName": "run",
"fileName": "Thread.java",
"lineNumber": 1583
}
]
}
SUGGESTION
...
"throwable": {
"className": "java.lang.RuntimeException",
"message": "Fraud detected",
"stackTrace": "java.lang.RuntimeException: Fraud Detection Processing Exception\\n at com.mycompany.antifraud.FraudDetectionController.checkOrder(FraudDetectionController.java:117)\\n at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)\\n ...\\n at java.base/java.lang.Thread.run(Thread.java:1583)"
}
@cyrille-leclerc please check again
It looks perfect to me, the config param withPlainStackTrace
and the JSON element stackTrace
are intuitive to me.
@ceki I'm wondering if I found a bug here: https://github.com/qos-ch/logback/blob/bfe33c6cf03fc5fcf06cb2ba9954f71ade7fa836/logback-classic/src/main/java/ch/qos/logback/classic/encoder/JsonEncoder.java#L199
If withThrowable
is false
, then the the json object ends in ,}
- which is not valid.
@ceki can you review the PR?
add option to encode Throwable in a raw format for easy ingestion into logging backends
Existing throwable encoding (
withThrowable
, enabled by default)new
withPlainStackTrace
format: