-
Notifications
You must be signed in to change notification settings - Fork 920
Adds option to SpanLimits to exclude exception.stacktrace attribute #7133
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
Draft
HaloFour
wants to merge
2
commits into
open-telemetry:main
Choose a base branch
from
HaloFour:jbs/exclude-exception-stacktrace
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Draft
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,2 +1,7 @@ | ||
| Comparing source compatibility of opentelemetry-sdk-trace-1.48.0-SNAPSHOT.jar against opentelemetry-sdk-trace-1.47.0.jar | ||
| No changes. | ||
| *** MODIFIED CLASS: PUBLIC ABSTRACT io.opentelemetry.sdk.trace.SpanLimits (not serializable) | ||
| === CLASS FILE FORMAT VERSION: 52.0 <- 52.0 | ||
| +++ NEW METHOD: PUBLIC(+) boolean isExcludeExceptionStackTrace() | ||
| *** MODIFIED CLASS: PUBLIC FINAL io.opentelemetry.sdk.trace.SpanLimitsBuilder (not serializable) | ||
| === CLASS FILE FORMAT VERSION: 52.0 <- 52.0 | ||
| +++ NEW METHOD: PUBLIC(+) io.opentelemetry.sdk.trace.SpanLimitsBuilder setExcludeExceptionStackTrace(boolean) | ||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
it may be worth considering the future direction proposed in open-telemetry/opentelemetry-specification#4333 before adding public API surface
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.
Thank you for that link. I will review and consider how it impacts this PR.
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.
There's a lot going on in that discussion. It sounds like even if the recommendation is that instrumentation emit exceptions as log events that there should still be some form of configuration to bridge that back to span events.
While it seems like a lot of things are up in the air have there been any discussions as to how that OTEP might impact the Java SDK and instrumentation?
Either way I think there's value in having some degree of control over how exceptions are interpreted and rendered into telemetry signals, including spans, so I would like to continue the conversation as to how that could be exposed in the SDK.
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.
I agree. With logs / events right now, instrumentation is responsible for this. See how the logback instrumentation has the same SDK exception span event rendering logic embedded in it. When its an instrumentation concern, that means that every instrumentation has to handle it separately. In theory that means that there's a lot of control over the rendering, but in practice, there's really only control if the instrumentation libraries expose configuration options to control the rendering. So it becomes a decentralized problem instead of a problem centrally handled / configured in the SDK. Ouch.
@trask I wonder if we should add a method to
LogRecordBuilderwhich allows users to attach an exception directly to the log record. Then, we could have a log SDK configuration option for configuring rendering which is consistent / symmetric with rendering configuration in the trace SDK.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.
That's interesting to me that the OTel Log instrumentation for JUL, log4j and logback simply emit the entire stacktrace rather than using the formatting facilities that are provided. It definitely feels like this might be something that the OTel SDK should provide and that instrumentation should be abstracted away from those concerns to keep the behavior consistent and user-configurable. I'd be happy to help work on such a project.
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.
@jack-berg since you're hopefully not trying to follow all of the logging discussions, here's the latest thought for attaching a terminal exception directly to a span: open-telemetry/opentelemetry-specification#4429 (comment)
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.
👍 this also seems to align with @HaloFour's thought. Of course, all of this will have to be configurable given the fact that folks may be depending on the current stable behavior.
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.
the general strategy we're proposing in the spec:
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.
Could that be an abstraction provided by the instrumentation API itself so that individual instrumentations don't need to be aware of how exceptions end up getting emitted?
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.
👍 if you're specifically referring to
io.opentelemetry.instrumentation:opentelemetry-instrumentation-api