[mrtg] Re: Threshold Checking

[SCHAAF PETER]

Interesting how you work. Specially your utilisation web page. It's true,
with such an implementation
it makes no sense to limit.
My threshold program is a snmptrap forwarded to a management console. This
is normally not a problem,
but it's via WAN. My intention is to reduce the WAN traffic and the console
messages.
By the way, it seems that MRTG is really used in the world!
Regards,
Peter.

Peter Schaaf
Support Center Engineer
Department ITS SC31 - Network/System/Application Management
International Support Center Brussels
 n.v. 
Guido Gezellestraat 121 / Building 32/0
B-1654 Huizingen
Belgium

Phone  : +32-2-536.3950 
Fax      : +32-2-536.6870
e-mail  : peter.schaaf at icp.siemens.be <mailto:peter.schaaf at icp.siemens.be> 



	-----Original Message-----
	From:	Bradford Woodcock [SMTP:bwoodcoc at bbn.com]
	Sent:	Thursday, October 21, 1999 3:49 PM
	To:	David C Prall; mrtg at list.ee.ethz.ch
	Subject:	[mrtg] Re: Threshold Checking

	Actually I even prefer how it works today. Each time a SET occurs I
write
	to a file in a certain directory and also to a running log for the
day. If
	the same SET occurs in the next 5 minutes it overwrites the previous
file
	with the current values. If a CLEAR occurs it is deleted. This could
also
	be used as a control function to limit pages/mail if I needed it to
	(although I'm not using it for that today). This is identical to
David's
	suggestion.

	The advantage to this technique when working with log files is that
I can
	keep a list of *current* (ie. last 5 minutes) threshold alarms
stored as
	seperate files in a directory with associated values. Now every time
we
	bring up our default web page a cgi runs to get all the files in
this
	directory, convert the text to html table format, then display. The
web
	page then reloads every minute showing any current utilization,
ifErrors,
	Fecn/Becn, and ifDiscards over a threshold for all interfaces. The
same
	technique is also applied to Spectrum alarms so we know our hard
outages
	too via the same web url display.

	The running logs can also be used to provide summary info for
trending
	thresholds observed (top links to worry about, etc.). A script to be
	written later on this quarter.

	good stuff cheap,

	cheers,
	brad...
	At 09:00 AM 10/21/1999 -0400, David C Prall wrote:
	>> it helps and now we've found where we can change this in MRTG
script.
	>> By the way, we found another thing. When a threshold is reached,
each
	>> poll cycle the action will be fired. Now we are still busy to
	>correlate this
	>> in MRTG script. Imagine, each poll cycle the same threshold mail
or
	>snmptrap
	>> will be sent! When it works fine we should find a way to
implement
	>this in
	>> MRTG generally.
	>
	>You confused me a little here. If you don't want it to run
	>everytime/multiple times. You can write your script so that it
checks
	>the ThreshDir for a file pertaining to the target. If this file
exists,
	>don't send the email except perhaps every fifth time. It would take
a
	>little more checking and scripting, but could be done.
	>
	>David C Prall, MCNE MCSE          DCP Technologies
	>dcp at dcptech.com                       Alexandria, VA
	>dcppage at dcptech.com               http://www.dcptech.com
	>
	>
	>--
	>* To unsubscribe from the mrtg mailing list, send a message with
the
	>  subject: unsubscribe to mrtg-request at list.ee.ethz.ch
	>* The mailing list archive is at http://www.ee.ethz.ch/~slist/mrtg
	>
	>

	--
	* To unsubscribe from the mrtg mailing list, send a message with the
	  subject: unsubscribe to mrtg-request at list.ee.ethz.ch
	* The mailing list archive is at http://www.ee.ethz.ch/~slist/mrtg

--
* To unsubscribe from the mrtg mailing list, send a message with the
  subject: unsubscribe to mrtg-request at list.ee.ethz.ch
* The mailing list archive is at http://www.ee.ethz.ch/~slist/mrtg