fix(ddtrace/tracer): ignore agent-provided TCP port when using a UDS w/ WithDogstatsdAddress

[darccio]

What does this PR do?

Fixes a corner case involving using a Unix Domain Socket path as address in WithDogstatsdAddress, as it was being ignored by the tracer as it tried to respect the TCP port informed by the agent. This leads to a situation where runtime and tracer health metrics are disabled.

Motivation

Ensure that runtime and tracer health metrics work in all the scenarios.

Reviewer's Checklist

• Changed code has unit tests for its functionality at or near 100% coverage.
• System-Tests covering this feature have been added and enabled with the va.b.c-dev version tag.
• There is a benchmark for any new code, or changes to existing code.
• If this interacts with the agent in a new way, a system test has been added.
• Add an appropriate team label so this PR gets put in the right place for the release notes.
• Non-trivial go.mod changes, e.g. adding new modules, are reviewed by @DataDog/dd-trace-go-guild.

Unsure? Have a question? Request a review!

[hannahkm]

lgtm, thank you for handling this!

[pr-commenter]

Benchmarks

Benchmark execution time: 2024-11-22 14:07:01

Comparing candidate commit 3e7b5f7 in PR branch dario.castane/incident-32698 with baseline commit 58e1e63 in branch main.

Found 1 performance improvements and 1 performance regressions! Performance is the same for 57 metrics, 0 unstable metrics.

scenario:BenchmarkHttpServeTrace-24

• 🟩 execution_time [-493.158ns; -392.042ns] or [-3.030%; -2.409%]

scenario:BenchmarkSetTagMetric-24

• 🟥 execution_time [+2.549ns; +4.151ns] or [+2.182%; +3.553%]

[mtoffl01]

I assume we expect localhost:8125 because that would be what's reported by the agent by default. But I imagine loadAgentFeatures isn't returning any data because we don't test with an agent here right?

Maybe we can test this by setting c.agent.StatsdPort directly to 8125, and confirm that this value is used over the user-defined one

[darccio]

@mtoffl01 I think that wouldn't test the code as it'll run in the wild. It's better to test with the zero value, as it means it's meaningful (falling back to 8125).

For instance, smoke-tests are red because they are running on the tip of main, and it behaves in a different way. By setting the value manually in c.agent.StatsdPort we could miss hidden behaviours like this. It was a head-scratcher but I'm glad it happened once I realized it was using main.