DX Unified Infrastructure Management

  • 1.  An incoming alarm and multiple matching auto operator profiles / pre-processing rules

    Posted Jan 16, 2012 09:18 PM

    Hi all,

     

    I have very basic query on auto operator profiles and pre-processing rules. Assuming an incoming alarm matchces more than one auto operator profile out of list of profiles, in that case will the action be executed for all the matching auto operator profiles or it will stop after first matching auto operator profile ?

     

    Similarly, what about pre-processing also ?

     

    Regards,

    Amit Saxena



  • 2.  Re: An incoming alarm and multiple matching auto operator profiles / pre-processing rules

    Posted Jan 16, 2012 10:16 PM

    For AO profiles, an alarm will run more than one. There is an explicit order set in the config. You can see a column for it in the NAS GUI. From what I have seen, it is possible for some profiles to have no order set on them, but I am not sure if that happens a lot. It would probably be best to occasionally set the order explicitly in the GUI just to make sure the profiles are run in the order you want.

     

    For pre-processing rules I am not sure. In the old days the only thing pre-processing rules could do was filter alarms, so order did not matter. Now that you can do other things with them, it could matter, especially if an alarm would stop after the first match.



  • 3.  Re: An incoming alarm and multiple matching auto operator profiles / pre-processing rules

    Posted Jan 18, 2012 07:06 PM

    Hi!

     

    I had some tests weeks ago about pre-proc and multiple roules... as I found out... nada... doesnt work, and by the way how should?

     

    You get an native alarm from a probe manipulate the native alarm and return the event to the nas (in case you run a script), I dunno thiong they gave it back to the bus but simply to the next instace of nas, I mean the AO

    Perhaps it would be a way if they gave those manipulated Msg back to the bus so the nas reveices it new....hmmm...

     

    cheers

    Matthias

     



  • 4.  Re: An incoming alarm and multiple matching auto operator profiles / pre-processing rules

    Posted Jan 20, 2012 11:37 PM

    Alarms can match multiple AO Profiles.  As mentioned earlier the ordering can be change (move up move down) and order set by right clicking on profiles.  In some cases, depending on the "Action type" of profile, you can set skip further check option on advanced tab, breaking further profile checks.  This is only enabled for some Profile action types.

     

    Pre-proc rules:  When I test it seems it will only match first instance hit therefore order and filtering would seem very important.  Also order of pre-procs cannot be manipulated (via the gui anyway).

     

    My Test - Created 2 pre-proc rules:

    - pre-proc-test1 & pre-proc-test2 each running custom script pre-proc 1 & 2

    - Scripts manip event.message to "hit pre-proc 1" "hit pre-proc 2" respectivly

    Both pre-proc rulels looking for sid i made up 3.9.9.9.

     

    Sent alarm with sid 3.9.9.9 with both rules enabled and only receive "hit pre-proc 1".  deleted alarm, deactivated the pre-proc-test1 (leaving only  pre-proc-test2 active) and message modified to "hit pre-proc 2"



  • 5.  Re: An incoming alarm and multiple matching auto operator profiles / pre-processing rules

    Posted Jan 20, 2012 11:48 PM

    It would be interesting to know if the alarm hit "pre-proc 1" because you added it to the config first (if you did) or because it comes first alphabetically. I am sure someone could figure that out with enough testing, but it seems like a bit of a hassle. It would be nice if that behavior were documented clearly. I could not find that level of detail in the help page for pre-processing rules.



  • 6.  Re: An incoming alarm and multiple matching auto operator profiles / pre-processing rules

    Posted Jan 21, 2012 12:14 AM

    I had added the pre-proc 1 rule first then pre-proc 2 so the order was 1,2 in rule list

     

    Deleteing the pre-proc1 rule and re-adding it so it comes after pre-proc 2 causes same situation. (2,1 in list)  now with both rules enabled i only get the "hit pre proc 2", the first rule hit.  If i deactivate pre-proc 2 rule it hits the pre-proc 1 active rule and i'll get message "hit pre-proc 1".  If it were to hit both with both enabled i would expect to always get whichever one was active and last in list no matter what came previously.  Basically expecting change of previous message to be overwritten.