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