Skip to content

Conversation

phacops
Copy link
Contributor

@phacops phacops commented Aug 8, 2025

No description provided.

@phacops phacops requested a review from a team as a code owner August 8, 2025 00:42
@phacops phacops self-assigned this Aug 8, 2025
@phacops phacops requested a review from Dav1dde August 8, 2025 00:43
Comment on lines 181 to 183
log.attributes
.get_or_insert_with(Default::default)
.insert_if_missing("sentry.payload_size_bytes", || size_in_bytes);
Copy link
Member

Choose a reason for hiding this comment

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

Should do this in processing/logs/store.rs, then it works correctly even with external Relays, where this will not (someone or an external Relay sets the attribute, then it never gets changed).

Copy link
Member

@Dav1dde Dav1dde Aug 8, 2025

Choose a reason for hiding this comment

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

I think you can add the size from the header (convert gets WithHeader) to the FieldAttributes struct and add the attribute right next to where we add sentry.severity_text.

FieldAttributes will no longer just be "field attributes" but that's w/e.

Comment on lines 1275 to 1280
trace_item.attributes.insert(
"sentry.payload_size_bytes".into(),
AnyValue {
value: Some(Value::IntValue(span.payload_size_bytes as i64)),
},
);
Copy link
Member

@Dav1dde Dav1dde Aug 8, 2025

Choose a reason for hiding this comment

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

Why do we need it for Spans?

The size of a Span is (currently) not billing relevant. The size used here will completely differ from the one for logs, which makes them not comparable and we will have to change that in the future again (not sure if that is an issue) with more SpanV2 support.

Copy link
Contributor Author

@phacops phacops Aug 8, 2025

Choose a reason for hiding this comment

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

It is indeed not billing relevant yet but we're looking at an indication of the size of the span when we receive it since we'll start applying limits to them soon.

I thought this was the best approximation right now, and we can replace it for a more accurate one later when we have it.

Copy link
Member

@Dav1dde Dav1dde Aug 11, 2025

Choose a reason for hiding this comment

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

Do you need them in Kafka? We can also emit this as a metric in Relay (and I think we already have that because we track the Kafka message sizes).

I thought this was the best approximation right now

It is probably the best we have right now, but I'd expect it to be off by more than 50%, that's what we saw for logs.

@phacops phacops requested a review from Dav1dde August 8, 2025 20:23
Comment on lines 49 to 56
let payload_size_bytes = log
.header
.as_ref()
.unwrap_or(&OurLogHeader {
..Default::default()
})
.byte_size
.unwrap_or_default();
Copy link
Member

Choose a reason for hiding this comment

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

log.header.as_ref().and_then(|h: &OurLogHeader| h.byte_size).unwrap_or_default()

Seems a bit nicer, maybe you can also drop the type annotation in the and_then.

@phacops phacops requested a review from Dav1dde August 11, 2025 17:19
@phacops phacops enabled auto-merge August 11, 2025 19:08
@phacops phacops added this pull request to the merge queue Aug 11, 2025
Merged via the queue into master with commit 30879db Aug 11, 2025
29 checks passed
@phacops phacops deleted the pierre/eap-add-payload-size-attribute branch August 11, 2025 19:29
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.

2 participants