<!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:494D2D5F.3090502@deployingradius.com" type="cite">
<pre wrap="">Anders Holm wrote:
</pre>
<blockquote type="cite">
<pre wrap="">So, for Access-Requests we ignore Status-Server packets, but
Status-Server packets do increment Access-Accept?
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
<blockquote cite="mid:494D2D5F.3090502@deployingradius.com" type="cite">
<pre wrap="">
There is no "ignore" of Status-Server packets.
The reason for incrementing Access-Accepts has been explained.
</pre>
</blockquote>
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.<br>
<br>
Considering I'm using exactly what the example from the Wiki tells me,
there is an Authentication, so logically, I'm asking for Access.<br>
<br>
"# echo "Message-Authenticator = 0x00, FreeRADIUS-Statistics-Type = 1"
| \"<br>
<br>
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?<br>
<blockquote cite="mid:494D2D5F.3090502@deployingradius.com" type="cite">
<blockquote type="cite">
<pre wrap="">Would there be a
counter for Status-Requests, so I could correlate the figures so I can
figure out what is what?
</pre>
</blockquote>
<pre wrap=""><!---->
Sure. Send a patch.
</pre>
</blockquote>
Sure.<br>
<blockquote cite="mid:494D2D5F.3090502@deployingradius.com" type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
There is only one Status-Server packet. I don't know what you mean by
"Status-*".
</pre>
</blockquote>
<br>
If one separates the Requests versus Accepts and Rejects, I'd see 3 ..
If one follows the set examples for other counters anyway.<br>
<br>
<blockquote cite="mid:494D2D5F.3090502@deployingradius.com" type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""> If you need deltas, track them yourself in the client app. It's the
only way to get them right.
</pre>
</blockquote>
<pre wrap="">Mmm.. Even then there'd be potential race conditions, data loss etc.
</pre>
</blockquote>
<pre wrap=""><!---->
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
</pre>
</blockquote>
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..<br>
<br>
There's multiple choices, with varying degrees of reliability and
completely different sets of failure scenarios.<br>
<br>
<blockquote cite="mid:494D2D5F.3090502@deployingradius.com" type="cite">
<blockquote type="cite">
<pre wrap="">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 .. ;)
</pre>
</blockquote>
<pre wrap=""><!---->
Sure. Track it, store it, no problem.
</pre>
</blockquote>
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.<br>
<br>
//anders<br>
</body>
</html>