<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Alan DeKok wrote:
<blockquote cite="mid:494CBFFF.2040306@deployingradius.com" type="cite">
<pre wrap="">Anders Holm wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap=""><!---->
No. The counter tracks Access-Requests, not Status-Server packets.
</pre>
<blockquote type="cite">
<pre wrap="">I mean, if
the Access-Accept is incremented, we must have had a request to being with.
</pre>
</blockquote>
<pre wrap=""><!---->
No. The response to a Status-Server is an Access-Accept.
</pre>
</blockquote>
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?<br>
<br>
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.<br>
<br>
<blockquote cite="mid:494CBFFF.2040306@deployingradius.com" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap=""><!---->
It would be extremely difficult. *Who* asked for those statistics
last? Is the "last statistics" item tracked by client IP? Client port?
Anything else...?
</pre>
</blockquote>
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.<br>
<br>
<blockquote cite="mid:494CBFFF.2040306@deployingradius.com" type="cite">
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">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 ...
</pre>
</blockquote>
<pre wrap=""><!---->
If you need deltas, track them yourself in the client app. It's the
only way to get them right.
</pre>
</blockquote>
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 .. ;)<br>
<br>
//anders<br>
<br>
<br>
</body>
</html>