dogstatsd sending metrics over http when udp supported

[haileeyyy]

dd-trace-js/packages/dd-trace/src/dogstatsd.js

Lines 174 to 182 in a346dd5

	if (config.url) {
	clientConfig.metricsProxyUrl = config.url
	} else if (config.port) {
	clientConfig.metricsProxyUrl = new URL(format({
	protocol: 'http:',
	hostname: config.hostname || 'localhost',
	port: config.port
	}))
	}

We're seeing unexpected traces for dns requests to the datadog agent ip, which we believe is due to runtime metrics and dogstatsd.

our client is using the default configuration, and we're relying on the DD_AGENT_HOST env var which is set using the kubernetes downwards api.

- name: DD_AGENT_HOST
  valueFrom:
    fieldRef:
      fieldPath: status.hostIP

---

with the code I've referenced above, I believe the else if (config.port) { line to be incorrect, because in our case, we have both a config.port value AND a config.dogstatsd.hostname and config.dogstatsd.port, but I don't think we want a metricsProxyUrl set?

I think the correct conditional would be: else if (config.port && !config.dogstatsd) {, but I'm not sure if there is a particular reason that this exists.

either way, because we're using the default config from dd-trace (i.e. the config is computed), I don't think it's actually possible for us to use udp instead of http for dogstatsd.

[hamiltop]

We've seen memory leaks since upgrading and think it may be related.

Running express/apollo-server, we occasionally see a process get into a state where it gets repeated socket timeouts and memory slowly climbs until it exceeds allocated memory and is OOM killed.

We haven't been able to provide a controlled reproduction, so it's not completely clear, but our hypothesis is that by switching to the http instead of udp we are exhausting some resource (e.g. dns) which then causes buffered data to pile up in memory. Many assumptions there, but getting this fixed would either solve or eliminate many of those assumptions.