Status counters

[Anders Holm]

Alan DeKok wrote:
> Anders Holm wrote:
>   
>> Looking a tad at the counters and how they get incremented I see the
>> following:
>>
>> Sending Access-Accept of id 20 to 127.0.0.1 port 32772
>>         FreeRADIUS-Total-Access-Requests = 0
>>         FreeRADIUS-Total-Access-Accepts = 36
>>         FreeRADIUS-Total-Access-Rejects = 0
>>         FreeRADIUS-Total-Access-Challenges = 0
>>         FreeRADIUS-Total-Auth-Responses = 36
>>
>> This is on a test server, which currently is only getting requests for
>> status. Shouldn't the Access-Requests also be incremented?
>>     
>
>   No.  The counter tracks Access-Requests, not Status-Server packets.
>
>   
>> I mean, if
>> the Access-Accept is incremented, we must have had a request to being with.
>>     
>
>   No.  The response to a Status-Server is an Access-Accept.
>   
So, for Access-Requests we ignore Status-Server packets, but 
Status-Server packets do increment Access-Accept? Would there be a 
counter for Status-Requests, so I could correlate the figures so I can 
figure out what is what?

Would there be an idea to have separate counters just for the Status-* 
type counters? Might be one handy way to handle that, as that'd separate 
those type of stats from each other as well as giving higher resolution.

>   
>> Also, using these counters for monitoring, it would be nice to see
>> deltas from the previous Status request. Though, if I would go ahead and
>> clear the counters (haven't even checked if it is possible tbh) I might
>> have requests arriving between my last Status request packet and my
>> clearing the counter, meaning my metrics would be incorrect. Would it be
>> trivial to add some form of delta-since-last-status-request, or is it
>> preferred to keep that in an external script?
>>     
>
>   It would be extremely difficult.  *Who* asked for those statistics
> last?  Is the "last statistics" item tracked by client IP?  Client port?
>  Anything else...?
>
>   
Indeed. Conundrum to say the least. I'll look at various alternatives, 
but "marshalling" through a central location and letting the "marshal" 
keeping track of previous and current numbers and returning the delta is 
probably the safest way to handle that.

>> Just trying to figure out which would be the best route, and what others
>> think of the idea. Might be useful for others here, so ...
>>     
>
>   If you need deltas, track them yourself in the client app.  It's the
> only way to get them right.
>   
Mmm.. Even then there'd be potential race conditions, data loss etc. I'd 
be using this data to gather metrics, and then in turn have alarms based 
on those metrics (levelling and thresholds). Ensuring the base data is 
correct then is of importance. OR at least understanding what the base 
data is telling us is of importance I should say .. ;)

//anders


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20081220/1e27e23b/attachment.html>