Correct me if I'm wrong but these options only show the stats regarding the whole node, not per host...
What I'm trying to get is a *per-host/remap rule *"real-time" bandwidth stats. The plugin does aggregate bytes stats well, but it doesn't do that in real-time. It seems that any solution to get this stats is going through the log analyzing, but that solution is not accurate at all. On Fri, Jul 19, 2013 at 4:48 PM, Mark Harrison <[email protected]> wrote: > I'm not sure if it would suffer from the same problem or not, but you can > try using the stats_over_http plugin or traffic_line -r and look at the > proxy.process.net.read_bytes > and write_bytes variables. > > > On Fri, Jul 19, 2013 at 8:52 AM, Ron Tsoref <[email protected]> wrote: > >> About half an year ago I looked for a solution to calculate the current >> bandwidth served at any given time. I thought of using the logs to get this >> information, but log lines are written only after a complete object was >> served. In the mailing list thread I opened back then, Conan posted a >> plugin he wrote that show the bytes served for each host via a HTTP >> interface and suggested me to take a look at it. >> >> The problem is that the bytes served for each host are increased only >> after a complete object is served, just like what I can do with the >> log-analyzing solution. >> >> This situation is causing spikes and bounces when analyzing the data from >> this plugin in small intervals. >> >> (The plugin is available in JIRA in >> TS-1596<https://issues.apache.org/jira/browse/TS-1596%E2%80%8E>and on >> Github <https://github.com/wkl/channel_stats>.) >> >> My question is whether there's any way to solve this so that counters >> would be updated regularly and not only when completing the file download. >> >> >> Also, on another note, is there any known issues in the "* >> read-while-write*" option? It seems not to work. I'm downloading a >> large file via a number of different requests and only after the first >> request is completed, the others are served too. >> >> Thanks, >> Ron >> > > > > -- > Mark Harrison > Lead Site Reliability Engineer > OmniTI >
