Status counters

[Anders Holm]

Alan DeKok wrote:
> Anders Holm wrote:
>   
>> So, for Access-Requests we ignore Status-Server packets, but
>> Status-Server packets do increment Access-Accept?
>>     
>
>   Perhaps you didn't see my message or read the names of the counters.
> One counter counts Access-Requests, and another one counts Access-Accepts.
>   
>   There is no "ignore" of Status-Server packets.
>
>   The reason for incrementing Access-Accepts has been explained.
>   
Heh. I sure did. Though, I'm thinking slightly differently I suppose.. 
"How can something be accepted which has not been requested?". And I 
understand why the Accepts increment. I just don't understand why the 
Requests aren't, as that how I'd look at a query to get the Status, a 
Request which specifically is an Access-Request to get Status-Server 
data returned. At least, that is my view.

Considering I'm using exactly what the example from the Wiki tells me, 
there is an Authentication, so logically, I'm asking for Access.

"# echo "Message-Authenticator = 0x00, FreeRADIUS-Statistics-Type = 1" | \"

So, Access-Accepts I got no problem with. That stacks up. Requests and 
Rejects is what I'm curious about. If my shared secret is wrong for 
example, doesn't that get counted as an Access-Reject, or doesn't it get 
counted at all?
>> Would there be a
>> counter for Status-Requests, so I could correlate the figures so I can
>> figure out what is what?
>>     
>
>   Sure.  Send a patch.
>   
Sure.
>> 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.
>>     
>
>  There is only one Status-Server packet.  I don't know what you mean by
> "Status-*".
>   

If one separates the Requests versus Accepts and Rejects, I'd see 3 .. 
If one follows the set examples for other counters anyway.

>>>   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.
>>     
>
>   Huh?  You have one client app querying the server and keeping track of
> deltas.  Other client apps query it.  And data loss can be prevented by
> keeping track of counters on disk, too
>   
Sure. In your own scenario you're considering several clients. On disk 
isn't good enough either. Losing a disk also means losing data. There's 
a lot of different variables to consider, as I'm building a highly 
available and not to mention reliable platform. Can be achieved with 
either multiple clients checking Status, or a hot-cold setup, or.. or.. or..

There's multiple choices, with varying degrees of reliability and 
completely different sets of failure scenarios.

>> 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 .. ;)
>>     
>
>   Sure.  Track it, store it, no problem.
>   
I have a feeling that's the better approach of them all .. Store the 
Status values in a replicated database, and have the monitoring clients 
have some decent smarts. Needs some pondering I think.

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