Attach MDC properties to logs as attributes

[lcian]

📜 Description

• Attach all properties from MDC to logs as attributes.
  • Another possibility would be to consider the options.contextTags property to filter which properties to attach.
  • As we don't incur costs for storing more properties as attributes (unlike for storing event tags), I think it makes sense to forward all of the properties when it comes to logs. Users can still rely on beforeSendLog and server-side scrubbing.
• Refactor the duplicate logic to apply MDC to events and logs into a LoggerPropertiesUtil class.
• There is a pending internal discussion on whether we should aggregate these attributes under a common prefix across SDKs/integrations (e.g. property.<key> or mdc.<key>) or not. https://sentry.slack.com/archives/C081M1KEQ0L/p1759827935482129

💡 Motivation and Context

Close #4783
Close JAVA-197

💚 How did you test it?

Unit tests.

📝 Checklist

• I added GH Issue ID & Linear ID
• I added tests to verify the changes.
• No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
• I updated the docs if needed.
• I updated the wizard if needed.
• Review from the native team if needed.
• No breaking change or entry added to the changelog.
• No breaking change for hybrid SDKs or communicated to hybrid SDKs.

🔮 Next steps

[github-actions]

Performance metrics 🚀

	Plain	With Sentry	Diff
Startup time	351.51 ms	447.96 ms	96.45 ms
Size	1.58 MiB	2.11 MiB	538.89 KiB

Baseline results on branch: main

Startup times

Revision	Plain	With Sentry	Diff
d217708	409.83 ms	474.72 ms	64.89 ms
604a261	380.65 ms	451.27 ms	70.62 ms
b3d8889	420.46 ms	453.71 ms	33.26 ms
c8125f3	383.82 ms	441.66 ms	57.84 ms
ee747ae	396.82 ms	441.67 ms	44.86 ms
3d205d0	352.15 ms	432.53 ms	80.38 ms
ce0a49e	532.00 ms	609.96 ms	77.96 ms
17a0955	372.53 ms	446.70 ms	74.17 ms
b3d8889	371.69 ms	432.96 ms	61.26 ms
d217708	411.22 ms	430.86 ms	19.63 ms

App size

Revision	Plain	With Sentry	Diff
d217708	1.58 MiB	2.10 MiB	532.97 KiB
604a261	1.58 MiB	2.10 MiB	533.42 KiB
b3d8889	1.58 MiB	2.10 MiB	535.07 KiB
c8125f3	1.58 MiB	2.10 MiB	532.32 KiB
ee747ae	1.58 MiB	2.10 MiB	530.95 KiB
3d205d0	1.58 MiB	2.10 MiB	532.97 KiB
ce0a49e	1.58 MiB	2.10 MiB	532.94 KiB
17a0955	1.58 MiB	2.10 MiB	533.20 KiB
b3d8889	1.58 MiB	2.10 MiB	535.06 KiB
d217708	1.58 MiB	2.10 MiB	532.97 KiB

Previous results on branch: lcian/feat/mdc-logs

Startup times

Revision	Plain	With Sentry	Diff
0751889	371.21 ms	442.88 ms	71.67 ms
b0d6d12	381.21 ms	410.46 ms	29.25 ms
60b38dd	371.02 ms	439.54 ms	68.52 ms

App size

Revision	Plain	With Sentry	Diff
0751889	1.58 MiB	2.11 MiB	538.88 KiB
b0d6d12	1.58 MiB	2.11 MiB	538.89 KiB
60b38dd	1.58 MiB	2.11 MiB	538.89 KiB

[linear]

JAVA-197 MDC tag information not added to logs.

[adinauer]

I would prefer if we also use options.contextTags for log attributes since that way it's consistent with what we do for events. Also starting to send it without opt-in would be something for a major version.

As a first step, I'd just add all MDC values according to options.contextTags.
We could then add support for regex to contextTags and in the next major default contextTags to a regex that simply matches everything.

[lcian]

I would prefer if we also use options.contextTags for log attributes since that way it's consistent with what we do for events. Also starting to send it without opt-in would be something for a major version.

As a first step, I'd just add all MDC values according to options.contextTags. We could then add support for regex to contextTags and in the next major default contextTags to a regex that simply matches everything.

Yeah that makes sense, changed it.

[markushi]

Looking good, I've left two comments

[markushi]

Opposed to applyPropertiesToEvent this does not modify properties, any specific reason why?

[lcian]

For events, we set the properties in targetKeys as tags on the event, and remove those from the map.
Then, for the properties that are left (i.e. didn't match any of the targetKeys), we still add them, but as a custom MDC context.
I might as well move that logic inside this util, as that will make this clearer.

I guess the background reason for why we do things this way is that we have a cost for storing tags on events as they're indexed, so we wanted to minimize the number of tags that we add.

[lcian]

Note that with the change this will be reported as MDC instead of Context Data. It's not indexed anyways so this shouldn't matter.