docs(develop): Loosen metrics SDK spec for modules

[szokeasaurusrex]

The "metrics module" section in the "metrics" develop spec is too restrictive.

In Rust, for example, we can implement a more ergonomic API by using macros instead of methods. Due to language restrictions, it is not possible to define macros in a module, only in the top-level of the crate, so we use metric_count!, metric_guage! and metric_distribution! instead. This API aligns with what we already do for logs in the Rust SDK.

Therefore, I propose loosening the requirements. The only "MUST"-level requirement in my proposal would be to expose this functionality; the precise API is lowered to "SHOULD"-level requirements to allow SDKs to deviate where this would be beneficial.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
develop-docs	Ready	Preview, Comment	Apr 20, 2026 9:42am

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
sentry-docs	Ignored	Preview	Apr 20, 2026 9:42am

[cleptric]

We still should expose metrics_gauge etc. functions, you can add additional macros as you see fit. Only exposing macros on a hot path won't scale fwiw, so these functions are still mandatory.
I'm also confused with what you stated about logs in Rust, are our docs wrong? https://docs.sentry.io/platforms/rust/logs/#best-practices

[szokeasaurusrex]

@cleptric Sounds good, I will also add the functions to the Rust SDK.

Regarding the following:

I'm also confused with what you stated about logs in Rust, are our docs wrong?

Yes, the docs are very wrong. None of the examples in that section compile, and I have opened #17393 to delete the section for now. More context on that PR.

[coolguyzone]

Suggested change

	### Metrics Capturing Functionality
	### Metrics Capture Functionality

[coolguyzone]

Suggested change

	Metrics-capturing functionality **SHOULD** be exposed as functions (or another suitable language construct) in a `metrics` module or namespace. If exposing the functionality in a module or namespace is infeasible in a particular SDK's language, the function names **SHOULD** be prefixed with the word `metric`.
	Metrics capture functionality **SHOULD** be exposed as functions (or another suitable language construct) in a `metrics` module or namespace. If exposing the functionality in a module or namespace is infeasible in a particular SDK's language, the function names **SHOULD** be prefixed with the word `metric`.