Report discarded log bytes

[adinauer]

📜 Description

Report discarded log size in bytes as part of client reports.

💡 Motivation and Context

Since log count is not shown to customers in UI, we want to report log size too.

💚 How did you test it?

📝 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]

	Fails
🚫	Please consider adding a changelog entry for the next release.

Instructions and example for changelog

Please add an entry to CHANGELOG.md to the "Unreleased" section. Make sure the entry includes this PR's number.

Example:

## Unreleased

### Features

- Report discarded log bytes ([#4871](https://github.com/getsentry/sentry-java/pull/4871))

If none of the above apply, you can opt out of this check by adding #skip-changelog to the PR description or adding a skip-changelog label.

Generated by 🚫 dangerJS against b703d2e

[github-actions]

Performance metrics 🚀

	Plain	With Sentry	Diff
Startup time	368.63 ms	443.27 ms	74.63 ms
Size	1.58 MiB	2.12 MiB	552.02 KiB

Baseline results on branch: main

Startup times

Revision	Plain	With Sentry	Diff
2124a46	319.19 ms	415.04 ms	95.85 ms
b3d8889	420.46 ms	453.71 ms	33.26 ms
d217708	409.83 ms	474.72 ms	64.89 ms
3d205d0	352.15 ms	432.53 ms	80.38 ms
fcec2f2	357.47 ms	447.32 ms	89.85 ms
889ecea	367.58 ms	437.52 ms	69.94 ms
1df7eb6	397.04 ms	429.64 ms	32.60 ms
ce0a49e	532.00 ms	609.96 ms	77.96 ms
ee747ae	357.79 ms	421.84 ms	64.05 ms
b750b96	408.98 ms	480.32 ms	71.34 ms

App size

Revision	Plain	With Sentry	Diff
2124a46	1.58 MiB	2.12 MiB	551.51 KiB
b3d8889	1.58 MiB	2.10 MiB	535.07 KiB
d217708	1.58 MiB	2.10 MiB	532.97 KiB
3d205d0	1.58 MiB	2.10 MiB	532.97 KiB
fcec2f2	1.58 MiB	2.12 MiB	551.50 KiB
889ecea	1.58 MiB	2.11 MiB	539.75 KiB
1df7eb6	1.58 MiB	2.10 MiB	532.97 KiB
ce0a49e	1.58 MiB	2.10 MiB	532.94 KiB
ee747ae	1.58 MiB	2.10 MiB	530.95 KiB
b750b96	1.58 MiB	2.10 MiB	533.19 KiB

Previous results on branch: feat/report-discarded-log-bytes

Startup times

Revision	Plain	With Sentry	Diff
28b566b	316.37 ms	364.56 ms	48.19 ms
fff4795	309.94 ms	370.50 ms	60.56 ms

App size

Revision	Plain	With Sentry	Diff
28b566b	1.58 MiB	2.12 MiB	551.58 KiB
fff4795	1.58 MiB	2.12 MiB	551.81 KiB

[stefanosiano]

Looks good for the most part, but reading the doc i understood we shouldn't count json characters in the byte size, which we are doing here
Perhaps a simple method in the log object that counts each key and value bytes is a good alternative?

[adinauer]

We're currently discussing, whether this simplified count as if it were serialized is OK or if we want to replicate what relay is doing.

[alexander-alderman-webb]

Looks good!

To record: no scientific byte count needed, as users are not billed on logs that are dropped in the SDK. So while the logic differs slightly from relay, counting the bytes in the serialized JSON emitted by the SDK seems like the most pragmatic choice and good enough for this use case.

[alexander-alderman-webb]

The function never returns -1, let's update the docstring

[alexander-alderman-webb]

not blocking: when dropping elsewhere we do not record a lost bytes when there's a serialization failure, whereas here we record a lost log_bytes event with 0 bytes.

I think this is okay as is, since we shouldn't encounter serialization failures anyway; we're also not strict about accurate byte reporting.