ref(core): Use serializeAttributes for metric attribute serialization

[Lms24]

pre-work for #18160

Use the same attibute serialization logic we already use in logs.

Bundle size impact:

• size decreases for users with logs and metrics
• size increases for metrics-only users. I think this is because previously the separate serialization logic could be inlined, while now it has to inline the slightly larger logic. Since it's not used in any non-treeshakeable default behavior (yet), this results in higher bundle size. Given we'll use this in our span serialization logic in v11, it will become part of the minimum SDK anyway (without metrics), so it should be fine to do this now.
• Because we include metrics (but not logs) in all our CDN bundles by accident, this now also increases CDN bundle size 😬. We're tracking removal of this for most bundles in v11 (Create separate cdn bundles for metrics #18583)

I think the largest positive long-term aspect of this refactor is that we'll re-use this logic more and more going forward (scope attributes on metrics, spansv2, and other telemetry items in the future), so I'd like to have it unified.

[github-actions]

size-limit report 📦

⚠️ Warning: Base artifact is not the latest one, because the latest workflow run is not done yet. This may lead to incorrect results. Try to re-run all tests to get up to date results.

Path	Size	% Change	Change
@sentry/browser	24.84 kB	-	-
@sentry/browser - with treeshaking flags	23.34 kB	-	-
@sentry/browser (incl. Tracing)	41.59 kB	-	-
@sentry/browser (incl. Tracing, Profiling)	46.18 kB	-	-
@sentry/browser (incl. Tracing, Replay)	80.16 kB	-	-
@sentry/browser (incl. Tracing, Replay) - with treeshaking flags	69.9 kB	-	-
@sentry/browser (incl. Tracing, Replay with Canvas)	84.84 kB	-	-
@sentry/browser (incl. Tracing, Replay, Feedback)	97.1 kB	-	-
@sentry/browser (incl. Feedback)	41.57 kB	-	-
@sentry/browser (incl. sendFeedback)	29.53 kB	-	-
@sentry/browser (incl. FeedbackAsync)	34.53 kB	-	-
@sentry/browser (incl. Metrics)	25.93 kB	+0.29%	+74 B 🔺
@sentry/browser (incl. Logs)	26.08 kB	+0.07%	+16 B 🔺
@sentry/browser (incl. Metrics & Logs)	26.73 kB	-0.33%	-86 B 🔽
@sentry/react	26.58 kB	-	-
@sentry/react (incl. Tracing)	43.82 kB	-	-
@sentry/vue	29.3 kB	-	-
@sentry/vue (incl. Tracing)	43.4 kB	-	-
@sentry/svelte	24.86 kB	-	-
CDN Bundle	27.37 kB	+0.42%	+113 B 🔺
CDN Bundle (incl. Tracing)	42.35 kB	+0.27%	+111 B 🔺
CDN Bundle (incl. Tracing, Replay)	79.06 kB	+0.15%	+113 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback)	84.51 kB	+0.12%	+97 B 🔺
CDN Bundle - uncompressed	80.31 kB	+0.37%	+290 B 🔺
CDN Bundle (incl. Tracing) - uncompressed	125.69 kB	+0.24%	+290 B 🔺
CDN Bundle (incl. Tracing, Replay) - uncompressed	242.23 kB	+0.12%	+290 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback) - uncompressed	255.02 kB	+0.12%	+290 B 🔺
@sentry/nextjs (client)	46.18 kB	-	-
@sentry/sveltekit (client)	41.96 kB	-	-
@sentry/node-core	51.71 kB	-	-
@sentry/node	161.95 kB	-	-
@sentry/node - without tracing	93.14 kB	-	-
@sentry/aws-serverless	108.65 kB	+0.01%	+1 B 🔺

View base workflow run

[github-actions]

node-overhead report 🧳

Note: This is a synthetic benchmark with a minimal express app and does not necessarily reflect the real-world performance impact in an application.
⚠️ Warning: Base artifact is not the latest one, because the latest workflow run is not done yet. This may lead to incorrect results. Try to re-run all tests to get up to date results.

Scenario	Requests/s	% of Baseline	Prev. Requests/s	Change %
GET Baseline	8,977	-	9,086	-1%
GET With Sentry	1,768	20%	1,678	+5%
GET With Sentry (error only)	6,198	69%	6,051	+2%
POST Baseline	1,191	-	1,206	-1%
POST With Sentry	580	49%	587	-1%
POST With Sentry (error only)	1,037	87%	1,062	-2%
MYSQL Baseline	3,280	-	3,317	-1%
MYSQL With Sentry	437	13%	449	-3%
MYSQL With Sentry (error only)	2,670	81%	2,691	-1%

View base workflow run

[Lms24]

huh looks like I broke undefined/null behaviour in comparison to the previous implementation. Will double check when I'm back

Update: Fixed

[Lms24]

So this is a fun one: metrics and logs attribute setting logic already diverged prior to this PR: undefined values were

• stringified to '' in logs
• ignored (not sent) in metrics

I therefore had to make the fallback behavior a tri-state flag. true ignores non-conforming values, 'skip-undefined also ignores undefined in addition, false completely ignores non-conforming values.