Request - Modification to Status Server to have Clients Stats in separate VSAs

[Peter Lambrechtsen]

On Wed, Aug 21, 2013 at 2:04 AM, Alan DeKok <aland at deployingradius.com> wrote:
> Peter Lambrechtsen wrote:
>> I'm currently playing around with the Status Server for stats
>> gathering and was hoping to have a minor change in the interface to
>> support extracting the Client information under different VSAs rather
>> than reusing the current "FreeRADIUS-Total-*" VSAs. It's not
>> particularly logical in my view to have the same VSA returned twice in
>> a Access-Accept, and then needing to determine if it's the client
>> related one or the global server related one by it's sequence in the
>> payload. It would make more sense in my mind to have the Client stats
>> as separate VSAs.
>
>   They should be separate VSAs.  I'm not sure what crack I was smoking
> when I cam up with the current VSAs, but oh well.
>
>   My inclination now is to leverage RFC 6929 and the extended
> attributes, and TLVs.  We could create VSAs which mirror the SNMP
> information in RFC 4668..4671.
>
>   Or, we could create our own TLVs in a sane format.  e.g. have a
> "parent" TLV for home server, client, and "this" server.  Inside of that
> parent, have the *same* list of child TLVs, in the same order, with the
> same meaning.
>
>   I'm inclined to leave 2.x the way it is.  It's imperfect, but it's
> workable.  The new 3.0 code is preferred for new functionality.

When looking through the master branch the suggestions I were making
were to master, so the way that 3.0 is planning do things. I think the
TLV approach is a valid one. One nice part of that is the ability to
list all servers/proxies/clients could be listed in a tree structure
way.

>
>   The nice thing about the 3.0 code is that if you're using the 3.0
> radclient, you don't really care that the counters are buried inside of
> TLVs.  They come out in "attr = value" form, just like anything else.

Nice, right now I have modified TinyRadius java client as that suits
my needs quite nicely after adding the Status Message and support for
Message-Authenticator as we have an exiting java monitoring tool that
monitors all our other services across ldap/sql/http and a whole
myriad of other systems for service and server availability and I have
easily extended it to use the Status call via TinyRadius and that's
working a treat. Currently wiring a bit more logic into it to handle
peaks & dips so when one of the BNG(s)/NAS goes AWOL or decides to
swap between primary/secondary FreeRadius instance which it doesn't
alert from in the BNG Syslog which is a bit of a bother or for some
reason gets a rapid increase in requests from a interface failure or
other random things that can occur in the network we can send an alert
to the relevant team to investigate. As that sort of stat analysis is
what we are looking to achieve without building a massively complex
solution that will be hard to maintain.

If it's ok I will look to extend the current dictionary to include
FreeRadius-Client-* using sequential numbers and those few minor
changes in stats.c. And at least push that as a possible patch for 3.x
and perhaps 2.x as it's pretty much the same code. Then when further
thoughts have been done about the best way to do it long term has been
decided then that can be supported too in 3.

Cheers

Peter