-
Notifications
You must be signed in to change notification settings - Fork 211
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Define generic error.message
#1992
base: main
Are you sure you want to change the base?
Conversation
I'm supportive of this. I've added it to both the general semconv meeting and log SIG meeting agendas just in case we don't get feedback here on the PR. |
Created #1994 for the feature flag implementation of this just to keep things separate |
Co-authored-by: Trask Stalnaker <trask.stalnaker@gmail.com>
stability: development | ||
examples: ["Unexpected input type: string", "The user has exceeded their storage quota"] | ||
brief: A message providing more detail about an error in human-readable form. | ||
note: | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should probably also recommend NOT using this in metrics due to cardinality.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does the text below cover your concern?
error.message
is recommended for events but not metrics or spans due to its unbounded cardinality and overlap with span status.
It is NOT RECOMMENDED to duplicate the value of `error.type` in `error.message`. | ||
It is also NOT RECOMMENDED to duplicate the value of `exception.message` in `error.message`. | ||
|
||
`error.message` is recommended for events but not metrics or spans due to its unbounded cardinality and overlap with span status. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
`error.message` is recommended for events but not metrics or spans due to its unbounded cardinality and overlap with span status. | |
`error.message` is NOT RECOMMENDED for metrics or spans due to its unbounded cardinality and overlap with span status. |
component: error | ||
|
||
# A brief description of the change. Surround your text with quotes ("") if it needs to start with a backtick (`). | ||
note: Add `error.message` property for human-readable error message. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
note: Add `error.message` property for human-readable error message. | |
note: Add `error.message` property for human-readable error message on events. |
Context: #1990 (comment)
This defines a generic
error.message
attribute for human-readable error messages to provide additional context and details about an error which occurred. It is meant to be used in conjunction witherror.type
which is low-cardinality.