Migrate to math/rand/v2

[mx-psi]

Component(s)

No response

Describe the issue you're reporting

Go 1.22 introduced math/rand/v2 which replaces the math/rand stdlib package. We should migrate to it!

Once we have migrated, we can forbid its usage via depguard.

Components using math/rand v1:

• connector/servicegraphconnector
• examples/demo
• exporter/awskinesisexporter
• exporter/awss3exporter
• exporter/azuredataexplorerexporter
• exporter/clickhouseexporter
• exporter/datasetexporter
• exporter/loadbalancingexporter
• exporter/mezmoexporter
• exporter/otelarrowexporter
• exporter/rabbitmqexporter
• internal/aws
• internal/coreinternal
• internal/exp
• internal/otelarrow
• pkg/batchperresourceattr
• pkg/sampling
• pkg/stanza
• processor/deltatocumulativeprocessor
• processor/groupbyattrsprocessor
• processor/probabilisticsamplerprocessor
• processor/tailsamplingprocessor
• receiver/awsfirehosereceiver
• testbed/testbed
• testbed/tests

(generated with rg math/rand -l -tgo | cut -d'/' -f1-2 | sort | uniq | sed 's/^/- [ ] /')

Counterpart to open-telemetry/opentelemetry-collector/issues/10885.

[Kei-Ta]

I can pick this up

[mx-psi]

@Kei-Ta This is being worked on in the linked PR #34685. Feel free to leave a review there :)

[github-actions]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

[jmacd]

We should migrate to it!

Please say why? It's not obvious.

[mx-psi]

@jmacd You can read https://go.dev/blog/randv2#problem and also the last section: https://go.dev/blog/randv2#principles. In summary: math/rand has some issues, and for all packages in the standard library with a v2, the v1 version will either have the same functionality or be, if possible, a wrapper over v2, so using v1 should always be worse than migrating to v2 for standard library packages.

[mx-psi]

Adding to this: our policy (as shown by our tooling) is to use the latest version available of all dependencies. This particular case is special because v1 will keep on being supported, but in general, to ensure we can quickly answer to new vulnerabilities in our dependencies web update everything to the latest version.