UDP cluster support for statsd addresses

[htuch]

From @jylin in #1019:

Would it make sense to try to make the "statsd_tcp_cluster_name" then support UDP too (i.e. a "statsd_udp_cluster_name")?

(in reference to avoiding hardcoding IP addresses in config files for statsd)

This seems reasonable from a config/API perspective, but will involve a bit of work to make work. Currently the cluster implementations such as LogicalDnsCluster are assuming TCP connections.

This is also related to #492 - if there was general support for UDP proxying we would be able to leverage that to do have UDP addressable clusters for statsd.

[mattklein123]

I think we should do this, and it wouldn't be that hard. Basically we can initially introduce a udpConnForCluster function inside the cluster manager. We will need this for UDP proxy eventually anyway.

[rshriram]

Confused. Don't we already have a udp support for statsd? We use that in istio

[mattklein123]

@cmluciano this is an interesting one to look at as one of the initial use cases. If we can create a UDP statsd cluster, we should be able to largely unify the UDP and TCP statsd code in Envoy. cc @alyssawilk

[cmluciano]

/assign

[albertoal]

Is there an update on this issue? We just adopted envoy proxy and are unable to send UDP metrics via envoy.dog_statsd stats_sink as it only supports an IP address on the socket_address.address and our DogStatsD listener runs as a service on Kubernetes with a kube DNS name such as my-svc.my-namespace.svc.cluster.local. We tried to use a cluster instead but these only support TCP as per this issue.

We ended up using an initContainer to populate the config with the IP of the node exposing a hostPort but this is far from ideal. It will be great to get native support here.

[cmluciano]

@albertoal There were a few pieces that I needed to implement before I could get the statsd support working. Some of these pieces are also being fleshed out in #6912 . As soon as that lands, I should be able to easily rebase some of the changes that I have duplicated in my branch and get that PR up for official review.

[albertoal]

That's great - thanks @cmluciano for the update!

[blakesmith]

Any updates on this? I see that #492 has landed, but I'm still seeing tcp_cluster_name in stats.proto. For now, the only way I can sink statsd stats is via a hardcoded IP address, which isn't ideal given that we use a fixed DNS CNAME for statsd IP resolution.

I'm happy to help where I can, if this requires more work!