Sure. We¹re doing a couple of things. For alarm processing where it¹s more important that the alarm be processed for sure, but not necessarily immediately (e.g. audit logging), we¹re using the file system method. For processing where we want the alarm processed quickly or not at all (e.g. automated troubleshooting), we¹ve done something a little different. At the start of those scripts we set a timer that generates an alarm signal. Then we have a handler for that signal, which will exit and log an error. In essence the script sets a limit on how long it can run, and will log an error and die if that limit is exceeded.
HTH, Jim On 7/22/11 2:11 PM, "Lalit Tyagi" <[email protected]> wrote: > Jim, > > Can you please share that how set\clear scripts works in your environment if > possible? > > I have wrote some MOM scripts which easily identify the issue with notifer. I > have basically created a synthetic transaction process (Create alarm->check > alarm->email notification->confirm email delivered to receipted inbox within > one minutes-> if email delivered in one minute then send our trap to > spectrum->spectrum clear MOM alarm which completed the cycle) which runs every > half an hour and notify us if spectrum alarm process failed on any of its > stages including hang set\clear script. > > Thanks for your response. > --Lalit Tyagi > > > > > From: Pfleger, Jim [mailto:[email protected]] > Sent: Friday, July 22, 2011 4:49 PM > To: Lalit Tyagi; Spectrum users > Subject: Re: [spectrum] Delay in setscript\clearscript > > Lalit- > > I think that having the set/clear scripts immediately exec a new process is > the better of the two options. It gets you around the single-threaded nature > of the Notifier, which you¹ve seen limits how quickly you can process alarms. > It also gets you around a related issue we¹ve found, which is that if > something goes wrong and the set or clear script never exits, the Notifier > will sit and wait forever. In effect, it stops processing alarms. > > Another option would be to have the set/clear scripts write files to a > particular directory one file per invocation. Then you have a daemon watch > the directory, and process and delete the files. This offers a couple of > advantages. First, files sitting in the directory for some time can indicate a > problem. Also, unlike with the Notifier where you only get one chance to > process a particular alarm, if there are any issues with a particular alarm¹s > file, the daemon can simply retry the problem file again as long as it¹s > sitting in the directory. > > HTH, > Jim > --- To unsubscribe from spectrum, send email to [email protected] with the body: unsubscribe spectrum [email protected]
