chore(client-reports): Add Client Report aggregator#1145
Open
szokeasaurusrex wants to merge 1 commit into
Open
chore(client-reports): Add Client Report aggregator#1145szokeasaurusrex wants to merge 1 commit into
szokeasaurusrex wants to merge 1 commit into
Conversation
66c55a9 to
2fc5269
Compare
2569c8a to
cfe64ee
Compare
2fc5269 to
6bd618a
Compare
cfe64ee to
a71a9bd
Compare
6bd618a to
1f9b20f
Compare
a71a9bd to
eeb5a2e
Compare
1f9b20f to
a1c5872
Compare
eeb5a2e to
9546535
Compare
a1c5872 to
41afa32
Compare
38019f7 to
be6bd6b
Compare
ad0ada5 to
c738dd0
Compare
be6bd6b to
a23c912
Compare
c738dd0 to
ece93f5
Compare
03b04a4 to
eb40b58
Compare
181f46f to
dbf16e8
Compare
51b3812 to
cebc324
Compare
cebc324 to
65568db
Compare
543b2cc to
1121016
Compare
65568db to
08adad0
Compare
08adad0 to
ce47300
Compare
1121016 to
7360117
Compare
cd4d502 to
2fd0c53
Compare
37c14e9 to
66d30cb
Compare
2fd0c53 to
3f24715
Compare
Create a client report aggregator in `sentry-core`. The aggregator lives on the `EnvelopeSender` next to the `Transport`. The `EnvelopeSender` itself is owned by a `Client`. The aggregator is entirely lock-free. Instead of the map shape suggested by the [SDK-wide client reports spec](https://develop.sentry.dev/sdk/telemetry/client-reports/#aggregation), the aggregator stores a counter for every discard reason/data category combination. There are currently [15 discard reasons](https://develop.sentry.dev/sdk/telemetry/client-reports/#discard-reasons-1) and [15 data categories](https://develop.sentry.dev/sdk/foundations/transport/rate-limiting/#definitions) allowed by the spec, some of which may be inapplicable to the Rust SDK. If we implement all of these in the SDK, the aggregator will consume approximately 1.8 KiB of fixed memory per instance (15 * 15 64-bit atomic counters). The alternative would be a HashMap keyed by `(category, reason)`. A HashMap would consume less memory while the aggregator is empty, but recording losses would require synchronization and could allocate memory. The fixed counter array is a reasonable tradeoff for now, and we can revisit the representation if this becomes a practical concern. Resolves [#1002](#1002) Resolves [RUST-154](https://linear.app/getsentry/issue/RUST-154/add-shared-client-report-aggregator-and-send-client-reports-option)
66d30cb to
d6a827e
Compare
3f24715 to
3438068
Compare
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Create a client report aggregator in
sentry-core.The aggregator lives on the
EnvelopeSendernext to theTransport. TheEnvelopeSenderitself is owned by aClient.The aggregator is entirely lock-free. Instead of the map shape suggested by the SDK-wide client reports spec, the aggregator stores a counter for every discard reason/data category combination. There are currently 15 discard reasons and 15 data categories allowed by the spec, some of which may be inapplicable to the Rust SDK. If we implement all of these in the SDK, the aggregator will consume approximately 1.8 KiB of fixed memory per instance (15 * 15 64-bit atomic counters).
The alternative would be a HashMap keyed by
(category, reason). A HashMap would consume less memory while the aggregator is empty, but recording losses would require synchronization and could allocate memory. The fixed counter array is a reasonable tradeoff for now, and we can revisit the representation if this becomes a practical concern.Resolves #1002
Resolves RUST-154