Willy, Thank you for your comments.
I agree that the logging you already have in haproxy is more flexible and detailed, and I acknowledge that the benefit of exporting sFlow-HTTP records is not immediately obvious. The value that sFlow brings is that the measurements are standard, and are designed to integrate seamlessly with sFlow feeds from switches, routers, servers and applications to provide a comprehensive end to end picture of the performance of large scale multi-tier systems. So the purpose is not so much to troubleshoot haproxy in isolation, but to analyze the performance of the whole system that haproxy is part of. Perhaps the best illustration of this is the 1-in-N sampling feature. If you configure sampling.http to be, say, 1-in-400 then you might only see a handful of sFlow records per second from an haproxy instance, but that is enough to tell you a great deal about what is going on -- in real time. And the data will not bury you even if you have a bank of load-balancers, hundreds of web-servers, a huge memcache-cluster and a fast network interconnect all contributing their own sFlow feeds to the same analyzer. Dave Mangot of Tagged.com describes how sFlow can help in large-scale environments in this Velocity talk: http://blog.sflow.com/2013/04/velocity-conference-talk.html Is this helpful? A link from the home page would be great of course, but that's up to you :) Regards, Neil On May 17, 2013, at 1:34 AM, Willy Tarreau wrote: > Hello Neil, > > On Tue, Apr 30, 2013 at 01:50:30PM -0700, Neil Mckee wrote: >> Hello All, >> >> I had a go at adding standard sFlow instrumentation to haproxy: >> https://github.com/sflow/haproxy >> >> This implements the exact same binary-logging-over-UDP export that you get >> from mod-sflow for apache, nginx-sflow-module, tomcat-sflow-valve, and more. >> It supports random 1-in-N sampling for scalability, and it is designed to >> be integrated with host performance counters from hsflowd, along with sFlow >> traffic monitoring from most network switches. (The goal being holistic >> end-to-end visibility). >> >> Anyone want to try it out? > (...) > > First, thank you for this work. I'm realizing that it can be frustrating > to see no response to your post, but we probably need more time to get > some testers. Let me knwo if you want me to add a link from the main > page to you work. > > I must say I have zero experience with sflow, so please don't take my > ignorance as a criticism of your work ! While I understand why it can > be useful at the network level, it's still hard for me to understand > the benefit at upper layers, since more precise details can be deduced > from the logs probably at a lower cost since the work just has to be > done once. > > Maybe you could enlighten me on this (and probably others as well, as > it's likely that I'm not the only one who doesn't see an obvious benefit > from doing this). > > Best regards, > Willy >
