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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
