Vladimir Smirnov

I might be wrong, but as far as I remember, problem of `poll` syscall under linux that it takes `O(N)` of amount of sockets your application have opened. While `epoll()`...

Drop counter is increased, but even in debug mode there is nothing in the log about what happened. E.x. if all the backend is down and relay gave up it...

https://github.com/grobian/carbon-c-relay/blob/master/server.c#L570 It tries to avoid it, but it's dropping them in some cases.

It increases droped counter, so on graphs it's visible as drops. If it's not actually dropping them, then it shouldn't touch the counter.

Yup. My point is that you should log that.

The best option is to have one logline per backend that stalls metrics. E.x. "backend blah: 100500 metrics stalled metrics dropped after 4 tries". Otherwise identifying the issue can take...

Another use case for that - some user actually sending metrics that they really don't want to send (e.x. metric with name HASH_0xblahblah_). It'll be really nice to blackhole them...

Yeah, but as you know people who send crap usually enormous amount of it, so simple logging won't help much (will use all disk possible), so that's more about sampling...

Yes, sampling should be sufficient.

To overcome issues with older libevent (thread-safeness) you might want to create a configuration system and in case if libevent