(RADIATOR) StatsLog (was: logging auth/acct/respose time/dropped packets statistics periodically)

[Tariq Rashid]

StatsLog is exactly what I wanted! 

Small niggle:
	* the results are cumulative, that is... if i set a logdump period of
	  say 10 minutes, ,... and send 17 radius requests in the first 10 minutes, but
	  none in the second 10 minutes... the second dump log will show 17 requests, not
	  zero.
	  The only way I could find to reset the counters was to restart or re-HUP
	  the server. Is there a better way? I don't really want to restart radiator
	  every 10 (or less) minutes!

There is a more general problem of detecting and monitoring peaks in the request rate, and also peaks in the responce time (due to whatver backend reason). The problem is that these statistics are averaged over time. So a huge spike at time=3minutes is washed out over 10minute statistics. Similarly for the responce rate. Obviously the answer is not to reduce the stats dump period... 

has anyone else addrressed this issue? It could be tied in with a wider network monitoring / alert system such as nagios?

tariq



-----Original Message-----
From: Hugh Irvine [mailto:hugh at open.com.au]
Sent: 22 April 2004 02:02
To: Tariq Rashid
Cc: radiator at open.com.au
Subject: Re: (RADIATOR) logging auth/acct/respose time/dropped packets
statistics periodically



Hello Tariq -

The StatsLog clauses have already been mentioned (thanks Cameron).

You can also run radiusd with -trace -1 to get a per-second transaction 
rate, and you could also connect to the Monitor port (see section 6.62 
in the manual).

regards

Hugh


On 22 Apr 2004, at 02:28, Tariq Rashid wrote:

>
> is there a good way to get radiator to dump its server-status 
> statistics periodically.
>
> i can set up a cron job to periodically send a status-request packet 
> and the result will also go into the logfile. can they be sent to a 
> different file for easier analysis?
>
> more importantly, is there a way to reset the counters of these 
> statistics. a kill -HUP does this but seems a bit drastic.
>
> i've looked through the online archive and the radiator reference but 
> with no answers.
>
> I'm very interested in PEAK request rates (averaged over a small as 
> time period as possible, smaller than 5 minuts say, 1 minute would be 
> good, less is better if it doesn't add undue load to the server)
>
> tariq
>
> --
> Archive at http://www.open.com.au/archives/radiator/
> Announcements on radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' with
> 'unsubscribe radiator' in the body of the message.
>
>

NB: have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.

--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.