Skip to content

[BUG]: Using an unresolvable DNS name as DD_AGENT_HOST blocks tracer initialization because of StatsD #3725

@adrien-f

Description

@adrien-f

Tracer Version(s)

2.0.1

Go Version(s)

go version go1.24.2 darwin/arm64

Bug Report

Greetings!

I have a use-case where I'm setting the DD_AGENT_HOST to the Kubernetes cluster service name datadog-agent.kube-system.svc.cluster.local for a Go instrumented application. That application starts before the Datadog Agent gets installed in the cluster, as such, the Kubernetes service is not yet created and thus, this service name does not resolve:

dial tcp: lookup datadog-agent.kube-system.svc.cluster.local on 172.20.0.10:53: no such host

This cause the tracer init to fail at https://github.com/DataDog/dd-trace-go/blob/main/ddtrace/tracer/tracer.go#L323C1-L327C3:

	statsd, err := newStatsdClient(c)
	if err != nil {
		log.Error("Runtime and health metrics disabled: %v", err)
		return nil, fmt.Errorf("could not initialize statsd client: %v", err)
	}

In this case err is not nil because DNS resolution failed inside newUDPWriter https://github.com/DataDog/datadog-go/blob/master/statsd/udp.go#L14 because it attempts to resolve the address with net.ResolveUDPAddr.

Now, I have some workarounds I can do such as making sure the ClusterIP is static and use it directly to avoid DNS resolution or setting the DD_DOGSTATSD_HOST to 127.0.0.1 to bypass it for example.

But as an improvement, maybe the tracer could have an option to not fail on error from statsdclient since the returned type is a NoOpClientDirect and as such, it can progress its initialization to send traces when the agent is up and running.

Thank you,

Reproduction Code

No response

Error Logs

No response

Go Env Output

No response

Metadata

Metadata

Assignees

Labels

bugunintended behavior that has to be fixed

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions