Re: Tracking packet/s in the server
I assume that these values are exposed to eg the status server so we can see them with current monitoring probes, eg monit ? ...and likewise send out an snmptrap via triggers.conf? alan
Alan Buxey wrote:
I assume that these values are exposed to eg the status server so we can see them with current monitoring probes, eg monit ?
Not yet. I suppose that could be done.
...and likewise send out an snmptrap via triggers.conf?
Yes, that too. The issue there is WHEN do you send traps? - when the queue of delayed packets gets more than half full? - when the PPS IN-OUT > ... ? - how to rate limit the traps so that you don't get spammed by them? What criteria should be used? Alan DeKok.
Hi,
The issue there is WHEN do you send traps?
- when the queue of delayed packets gets more than half full? - when the PPS IN-OUT > ... ? - how to rate limit the traps so that you don't get spammed by them?
What criteria should be used?
perhaps another threshold/counter - eg no more than X per hour?? one advantage of the trigger.conf is that it can be used to bootstrap an external process...so, for example if the one RADIUS server is getting a little 'hot', I can instruct my S3/cloud/VM system to spin up another VM and send a message to the load-balancer to say theres another box it can use...and when things go quiet the server farm can be dynamically shrunk again. alan
Alan Buxey wrote:
perhaps another threshold/counter - eg no more than X per hour??
Right now, it just tracks requests in the last second. That was easiest to implement. I'm not sure that tracking requests/hour is useful. The server can get sudden spikes on a 2-3 second basis. The goal of the packet/s tracking is precisely to catch those spikes.
one advantage of the trigger.conf is that it can be used to bootstrap an external process...so, for example if the one RADIUS server is getting a little 'hot', I can instruct my S3/cloud/VM system to spin up another VM and send a message to the load-balancer to say theres another box it can use...and when things go quiet the server farm can be dynamically shrunk again.
That's the idea. The issue for me is the internal decisions to ensure that you only get *one* of those messages, instead of one per second, or one per packet. Alan DeKok.
On 23/02/12 08:50, Alan DeKok wrote:
Alan Buxey wrote:
I assume that these values are exposed to eg the status server so we can see them with current monitoring probes, eg monit ?
Not yet. I suppose that could be done.
...and likewise send out an snmptrap via triggers.conf?
Yes, that too.
The issue there is WHEN do you send traps?
- when the queue of delayed packets gets more than half full?
- when the PPS IN-OUT> ... ?
- how to rate limit the traps so that you don't get spammed by them?
What criteria should be used?
Maybe best to leave this to external tools; just expose the absolute COUNTER, and the various rate GAUGE values, and let the tools send the alerts, IMO. For what it's worth, a suitably compiled net-snmp can watch its own internal OIDs and execute user-configurable threshold traps.
Phil Mayers wrote:
Maybe best to leave this to external tools; just expose the absolute COUNTER, and the various rate GAUGE values, and let the tools send the alerts, IMO.
That's less work for me. :) I'll take a look at updating the MIBs with this information. That might take a while, tho. For now, exporting them via the "status" virtual server (RADIUS packets) is easy. Alan DeKok.
participants (3)
-
Alan Buxey -
Alan DeKok -
Phil Mayers