Mrtg has some preetty slick methods for dealing with counter overflow.
Basically, it diagnoses a catastrophic decrease in a counter that is
supposed to only increase.  It then adjusts the delta to get the right
result.  The final results are pretty nice.


On 9/13/07 9:15 AM, "Robert Segall" <roseg@apsis.ch> wrote:

> On Wed, 2007-09-12 at 16:04 +0200, Michal Taborsky - Internet Mall
> wrote:
>> Sorry, I don't have any suggestion, I just want to show support :) Let's
>> formulate it as a feature request:
>>
>> Pound will have an internal counter(s) for each backend, this counter
>> would be incremented on each request. There would ideally be two
>> counters, one for successful requests, one for failed.
>>
>> Also, there would be a poundctl functionality to print these counters,
>> something like:
>>
>> Timestamp,Listener,Service,Backend,Success,Failure
>>
>> ie.
>> ...
>> 1189587846,1,2,3,5136844684,5
>> 1189587846,1,2,4,5136849871,2
>>
>> And, of course, a switch to reset these counter.
>>
>> This printout would be easily parseable from Zabbix, MRTG or whatever.
>>
>> Robert, what do you think? I suppose that should't be too difficult.
>
> Surprisingly enough, it is difficult: on machines with small word size
> you can easily run into integer overflow problems. Even with 32 bit
> integers you'll get an overflow after about one month, assuming 400
> requests per second.
>
> The mechanism currently implemented in Pound to support dynamic
> rescaling keeps a history of sorts, but the values are periodically
> rescaled. See the code in svc.c, in upd_be().
>
> This means we can have a kind of average response time (which is printed
> by poundctl), but not the total number of requests.