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

Reply via email to