Hi Tim,
>From your description it looks like you are trying to
find a way to 'turn off' and 'turn on' processing of all rules
during a maintenance window.
Several thoughts come to mind:
1. Recall that SEC just reads log files and operates
on input. If you have the ability to use the Unix
logger(1) command you can use logger to send
a defined string to syslog:
logger -p local3.info "XXXX SEC_OFF"
which is easily detected by a match rule. After
matching the rule you could create a context
for "SEC_OFF" and test for that context in
the first rule in the rules file, and ignore the remaining
rules if the context is found.
You could likewise use "XXXX SEC_ON" to remove
the context.
logger(1) can be a part of your change control
process, or put into a cron rule if changes follow
strict windows, or you could build it into a web
page that you use. Obviously, this would be
best done in a secure manner (authentication
required) since anyone who sent that log entry
would be able to turn off your SEC network monitor.
I'm sure you can find a way to secure this type
of processing.
2. If you are talking about removing *individual devices*
from SEC processing, this is a little trickier, but still
doable.
In the past, I've used a similar technique to that above
to create contexts for individual devices that are
known in advance. This comes from an pre-prepared
asset file that can be read at startup:
router1 UP
router2 UP
...
The file is read and individual contexts for each device
are created:
router1_UP
router2_UP
A context would thus exist for every device you manage.
When it is necessary to remove a particular device from
SEC processing, a different entry is concatenated into the
SEC input stream (syslog or :some other special file)
router1 DOWN
...
which would trigger a rule to delete the context for that
individual device.
Your ruleset would have to take into consideration
the presence or absence of a specific device context:
context=SOME_OTHER_CONTEXT && router1_UP
There are some tricks that can be used to create and recognize
context names with regular expressions. These may help
with managing many devices.
I've successfully used these types of rules and processing in several
projects with over 2000 devices. Contexts (a perl hash) don't
add that much overhead to SEC operations.
Hope that provides you with some ideas,
Jim B.
________________________________
From: Tim Peiffer [mailto:[email protected]]
Sent: Tue 6/8/2010 6:54 AM
To: [email protected]
Subject: [Simple-evcorr-users] SEC - programmed ignore
I am looking for ideas on a mechanism of causing SEC to ignore events on
a schedule on rules similar to the ones listed below. I have to modify
the SEC configuration on 4 independent network monitoring hosts during
scheduled configuration upgrades, along with reload of the SEC rules,
and I really want to get out of that business because it ties me
personally too close to the configuration upgrade process. Does this
group have any ideas on what such a mechanism would be, and what SEC
rules would need to be used to take advantage of the mechanism
automatically?
The schedule might come from scheduled down time for a host, device,
peer, or circuit. The schedule must be controlled external to SEC, and
must be reachable via some customer process. I have mysql available,
and so are file transfer methods to pull down columnar data (sftp,
https, etc) in order to fulfill the latter requirement. I would like to
scrape the information from a change control process that declares a
maintenance window, and also have a method of superceding it in the case
where the maintenance action is completed before the end of the
maintenance window..
Table: scheduled maintenance
Event Start, Event End, Host/Port/Peer, supercede?
20100607T2200, 20100607T2345,myhost.mydomain, no
type=Single
ptype=RegExp
pattern=Node Unreachable: (<host name or IP address>)
desc=Scheduled outage on %s
action=none
type=Single
ptype=RegExp
pattern=Peer Down: (<peer name or IP address>)
desc=Scheduled outage on %s
action=none
type=Single
ptype=RegExp
pattern=Link Down: (<Host + Port identifier >)
desc=Scheduled outage on %s
action=none
Please advise,
Tim Peiffer
--
Tim Peiffer
Network Support Engineer
Office of Information Technology
University of Minnesota/NorthernLights GigaPOP
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Simple-evcorr-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Simple-evcorr-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
