Skip to content

Conversation

@jack-berg
Copy link
Member

@jack-berg jack-berg commented Apr 10, 2025

Resolves #5187.

Make exception.* resolution configurable. With #7182, exception.* attributes are now resolved and attached to both span events and log records. This is an edge cases where the SDK specification has a dependency on the semantic conventions. It seems appropriate to make this a configurable extension point, so that users can customize things like the exception.stacktrace resolution, and whether they even want exception attributes included at all.

Broken out from #7182. Leaving as a draft because this makes the most sense after merging #7182.

@codecov
Copy link

codecov bot commented Apr 10, 2025

Codecov Report

Attention: Patch coverage is 83.33333% with 12 lines in your changes missing coverage. Please review.

Project coverage is 89.75%. Comparing base (90e030f) to head (09b99a5).
Report is 14 commits behind head on main.

Files with missing lines Patch % Lines
...ntelemetry/sdk/internal/ExtendedAttributesMap.java 20.00% 3 Missing and 1 partial ⚠️
...a/io/opentelemetry/sdk/internal/AttributesMap.java 50.00% 1 Missing and 1 partial ⚠️
...dk/internal/DefaultExceptionAttributeResolver.java 86.66% 0 Missing and 2 partials ⚠️
...metry/sdk/logs/internal/SdkLoggerProviderUtil.java 75.00% 2 Missing ⚠️
...etry/sdk/trace/internal/SdkTracerProviderUtil.java 75.00% 2 Missing ⚠️
Additional details and impacted files
@@             Coverage Diff              @@
##               main    #7266      +/-   ##
============================================
- Coverage     89.83%   89.75%   -0.08%     
- Complexity     6895     6977      +82     
============================================
  Files           786      797      +11     
  Lines         20793    21165     +372     
  Branches       2026     2056      +30     
============================================
+ Hits          18679    18997     +318     
- Misses         1469     1505      +36     
- Partials        645      663      +18     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@jack-berg jack-berg marked this pull request as ready for review April 11, 2025 20:13
@jack-berg jack-berg requested a review from a team as a code owner April 11, 2025 20:13
@trask
Copy link
Member

trask commented Apr 18, 2025

cc @HaloFour

@jack-berg
Copy link
Member Author

Alright I've refactored this to reflect the recommendation from this convo to consolidate into a single method. Please take another look when you can @trask! Would love to get this merged to unblock #7281, which I think will make a nice positive perf impact for many users.

Comment on lines -61 to +63
public Object put(AttributeKey<?> key, Object value) {
public Object put(AttributeKey<?> key, @Nullable Object value) {
if (value == null) {
return null;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does this change have any effect on existing behaviors that we should be aware of?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No it shouldn't.

I wasn't quite remembering why I added this in the first place, so I retraced my steps and determined:

  • ExceptionAttributeResolver.AttributeSetter#setAttribute accepts a @Nullable T value. We want this because we recently updated Span, LogRecord setAttribute methods to accept @Nullable values.
  • AttributeMap#putIfCapacity acts as the implementation for this method
  • AttributeMap#putIfCapacity delegates to AttributeMap#put (I want both methods to reduce accidental mistakes of bypassing the validation, as discussed in the javadoc of this class)

@jack-berg jack-berg merged commit b11316b into open-telemetry:main Jun 5, 2025
28 checks passed
@philsttr
Copy link

Hey Folks, as a followup to this PR, is there work planned to make the log4j / logback appenders use the ExtendedLogRecordBuilder.setException(..) method that uses the new ExceptionAttributeResolver introduced in this PR rather than setting the exception.* attributes directly ?

@trask
Copy link
Member

trask commented Aug 21, 2025

hi @philsttr, can you open an issue in the java instrumentation repo where those appenders live? thanks!

@philsttr
Copy link

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Exception stack trace to string conversion customization

5 participants