This is essentially the opposite of #25, but the way Sysdig handles StatsD is to listen for outgoing packets in the kernel, rather than capture them. This is a relatively common use case for containerized applications (i.e. Docker & Kubernetes). By doing it this way, there's no need to instrument a StatsD listener in the container or deal with networking.
More info here:
https://sysdig.com/blog/how-to-collect-statsd-metrics-in-containers/
From looking into it, quipo/statsd use net.Conn, which will log a failure when emitting to no one in particular:
https://github.com/quipo/statsd/blob/master/client.go#L190
[BufferedStatsdClient] 2017/03/28 21:44:41 write udp 127.0.0.1:57858->127.0.0.1:8125: write: connection refused
Using a net.PacketConn and WriteTo() does not produce an error in the same conditions. I was considering a pull request for a sysdig client, but the scope is pretty large for an essentially parallel code path. I was wondering about just replacing the existing net.conn with a net.PacketConn?
This is essentially the opposite of #25, but the way Sysdig handles StatsD is to listen for outgoing packets in the kernel, rather than capture them. This is a relatively common use case for containerized applications (i.e. Docker & Kubernetes). By doing it this way, there's no need to instrument a StatsD listener in the container or deal with networking.
More info here:
https://sysdig.com/blog/how-to-collect-statsd-metrics-in-containers/
From looking into it, quipo/statsd use net.Conn, which will log a failure when emitting to no one in particular:
https://github.com/quipo/statsd/blob/master/client.go#L190
[BufferedStatsdClient] 2017/03/28 21:44:41 write udp 127.0.0.1:57858->127.0.0.1:8125: write: connection refusedUsing a net.PacketConn and WriteTo() does not produce an error in the same conditions. I was considering a pull request for a sysdig client, but the scope is pretty large for an essentially parallel code path. I was wondering about just replacing the existing net.conn with a net.PacketConn?