Brown, James wrote: > Hi Tim, > It might be more advantageous to update your Change Control > Procedures documentation to manually perform #3 before they > begin and #5 when they complete. These can be integrated into > a Standard Operating Procedure for all changes, similar > to calling the help desk before commencing changes, and > performing pre-change checklist activities. > I'm a fan of automation, but consider whether you are > building additional automated procedures that may > not apply in every situation- Change Window cancelled, > Change Window rescheduled, or that fail due to unexpected > conditions- database crash, network unavailable, etc. > I've found over the years that standardizing procedures that > people perform is just as important as finding ways > to automate things. > Just a thought. I agree in principal.. Manual is required in the event of unexpected conditions. However, I would be remiss if I did not have something where I was doing bulk changes surgically disabling tickets and notifications on a temporary basis because these are known events. I have several thousand routers/switches/AP, etc and user ports number about 90 thousand. I want to also be able to do events and event suppression on a subscription basis, so I will need methods of communicating known events. > That being said, I think the steps you've outlined below > mostly cover what you are attempting to do, but I'm > thinking an additional step has to happen at 3.5: > - Update the change control table with each completed item > i.e. set Compete=1 on each item. Agreed. > Cheers, > Jim B. Thanks - I appreciate others thinking about my issues. I am the only one here that is using SEC and I am trying to change that.
Regards, Tim Peiffer > > ------------------------------------------------------------------------ > *From:* Tim Peiffer [mailto:peif...@umn.edu] > *Sent:* Tue 6/8/2010 11:36 AM > *To:* Brown, James > *Cc:* simple-evcorr-users@lists.sourceforge.net > *Subject:* Re: [Simple-evcorr-users] SEC - programmed ignore > > Jim, > > Below is what I have so far from an earlier discussion with my Tier2 > support folks.. I haven't found a clean way of interacting directly with > the database, but given that SEC is a log processor, it makes sense to > keep the configuration channel in the log stream. I plan on > recirculating the logged event at some point back to the NMS, but as an > event type that is not processed again. > > I see that John Rouillard offered suggestions as well, and they seem to > coincide with my thinking. I think the difficult part for me will not be > SEC config, but rather the interaction with the change control system in > terms of entering change control information and extracting it from the > tables programatically or via SQL. > > Thanks, > - Tim > > NMS Change Control process outline > > 1. Need Oracle or MySql table to communicate changes > > ChangeControlTable > In sql parlance: > Create TABLE “ChangeControlTable” > ( > “Start” DATE, > “Stop” DATE, > “Duration” NUMBER(10,0), > “HostPortOrPeer” VARCHAR2(30), > “Ticket” VARCHAR(8), > “Complete” BIT > ) > > 2. Need process to extract change items from change control table > > Select Start,Stop,Duration,Host,Ticket,Complete > From ChangeControlTable > Where (Start - now < 5 minute) and (Start > 0) > > 3. Need process to write an event to a monitored syslog log stream. > logger –p local1.notice “$Host change control window $Duration ticket > $Ticket” > > 4. Need process to extract completed change items from change control > table > > Select Host,Ticket > From ChangeControlTable > Where (Stop – now > 0) and (Complete = 1) > > 5. Need process to write the completed event to a monitored syslog stream > logger –p local1.notice “$Host change $Ticket complete” > > 6. Need Event Correlator rules to read change control events to create > or delete contexts. > > > # Create a context quiet:<host> with a lifetime of <duration> seconds. > The context > # will be automatically harvested by the correlator. In addition, log > the action taken. > type=Single > ptype=regexp > pattern=(\S+) change control window (\d+) ticket (\S+) > desc=set change control window > context= !quiet:$1 > action=create quiet:$1 $2 ; \ > logonly %s > > # Delete a context quiet:<host> where change is complete > type=Single > ptype=regexp > pattern=(\S+) change complete ticket (\S+) > desc=set change control window > action=create quiet:$1 $2 > > 7. Need to modify any of the existing ticket methods to account for the > new context labeled ‘quiet’. > > type=PairWithWindow > ptype=RegExp > pattern=Node Unreachable: (\S+) > desc=Node Unreachable:down message > context= !quiet:$1 && !reboot:$1 > action=create "reboot:$1" 1200 ; logonly ticket requested %s ;\ > spawn SCTicket \ > -category "DATA SERVICE" \ > -subcategory "data switch" \ > -problemtype "connectivity" \ > -producttype "none" \ > -severity major \ > -title "%s" \ > -text "The host $1 is not responding to polls. Please investigate." > ptype2=RegExp > pattern2=Node Reachable: (\S+) > desc2=Node Reachable:Up message > action2=delete reboot:$1 ; logonly “Node $1 Reachable – possible bounce” > window=300 > > > > -- > Tim Peiffer > Network Support Engineer > Office of Information Technology > University of Minnesota/NorthernLights GigaPOP > > +1 612 626-7884 (desk) > > ------------------------------------------------------------------------ > Note: The information contained in this message may be privileged and > confidential and protected from disclosure. If the reader of this > message is not the intended recipient, or an employee or agent > responsible for delivering this message to the intended recipient, you > are hereby notified that any dissemination, distribution or copying of > this communication is strictly prohibited. If you have received this > communication in error, please notify us immediately by replying to > the message and deleting it from your computer. Thank you. ThruPoint, > Inc. > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > 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 > Simple-evcorr-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users > -- Tim Peiffer Network Support Engineer Office of Information Technology University of Minnesota/NorthernLights GigaPOP +1 612 626-7884 (desk) ------------------------------------------------------------------------------ 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 Simple-evcorr-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users