-
Notifications
You must be signed in to change notification settings - Fork 900
Lazily evaluate ExceptionEventData exception.* attributes #7172
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
base: main
Are you sure you want to change the base?
Conversation
|
||
abstract SpanLimits getSpanLimits(); | ||
|
||
public abstract Attributes getAdditionalAttributes(); |
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.
cc @HaloFour I believe this should be a (temporary) workaround to the changes in #6795. To restore the behavior you were relying on, you should be able to:
- Check if
eventData instanceOf LazyExceptionEventData
- If so, access the attributes via
LazyExceptionEventData#getAdditionalAttributes()
without rendering theexception.*
I'd like to followup with this PRs change with:
- Add SDK customization hook for defining your own exception rendering logic
- Introduce API for setting exception on logs
LogRecordBuilder#setException
- Improve the default exception rendering logic to be attribute limits aware, so that if attributes can't be longer than 1000 characters we don't waste resources rendering the stacktrace past this limit
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #7172 +/- ##
============================================
+ Coverage 89.92% 89.94% +0.01%
- Complexity 6721 6728 +7
============================================
Files 765 766 +1
Lines 20277 20305 +28
Branches 1985 1988 +3
============================================
+ Hits 18234 18263 +29
- Misses 1448 1449 +1
+ Partials 595 593 -2 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
sdk/trace/src/main/java/io/opentelemetry/sdk/trace/internal/data/LazyExceptionEventData.java
Outdated
Show resolved
Hide resolved
sdk/trace/src/main/java/io/opentelemetry/sdk/trace/internal/data/LazyExceptionEventData.java
Outdated
Show resolved
Hide resolved
…y-java into lazy-evaluate-exception
is there a connection or overlap between this PR and #7182? |
They solve separate problems but there will be merge conflicts I'll need to resolve regardless of which is merged first |
Sounds good I'll review this one second |
…y-java into lazy-evaluate-exception
Should be good to go now that #7182 is merged |
sdk/trace/src/main/java/io/opentelemetry/sdk/trace/internal/data/LazyExceptionEventData.java
Outdated
Show resolved
Hide resolved
// - exception.type | ||
// - exception.message | ||
// - exception.stacktrace | ||
return getAdditionalAttributes().size() + 3; |
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.
for users of this method does it matter that there could be overlap and so this calculation could overcount (e.g. a user overriding exception.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.
Oh great point. Need to think this through a little more
Currently, we compute
exception.*
span event attributes immediately whenrecordException
is called.With this PR, those attributes are computed lazily at the time of export. This should shift CPU / memory from hot path to export background threads.