In particular, is it ok for instrumentation to populate span status ERROR description with exception.message or exception.type?
This is the current specification text:
When the status is set to Error by Instrumentation Libraries, the Description SHOULD be documented and predictable. The status code should only be set to Error according to the rules defined within the semantic conventions. For operations not covered by the semantic conventions, Instrumentation Libraries SHOULD publish their own conventions, including possible values of Description and what they mean.
Based on this, I would interpret both exception.message and exception.type as generally not ok in most cases (where the specific values depend on the application being instrumented and so cannot be listed out ahead of time by the instrumentation).
However, as @Oberon00 points out in #3198 (comment) and #3198 (comment), there are existing SDKs and Instrumentations which are populating the exception.message into the span status description, e.g.
In particular, is it ok for instrumentation to populate span status ERROR description with
exception.messageorexception.type?This is the current specification text:
Based on this, I would interpret both
exception.messageandexception.typeas generally not ok in most cases (where the specific values depend on the application being instrumented and so cannot be listed out ahead of time by the instrumentation).However, as @Oberon00 points out in #3198 (comment) and #3198 (comment), there are existing SDKs and Instrumentations which are populating the
exception.messageinto the span status description, e.g.