You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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?
The text was updated successfully, but these errors were encountered: