way to edit suppression key

[Nijin K]

hi all

we are using suppression key to segregate and identify different alarms from the probes for our auto ticketing but for dns_response probe different alarms have same suppression key so I wanted to know if there is away to edit suppression key

[Garin Walsh]

You can add/edit the suppression key on the fly using a preprocessing rule/script.

There are a bunch of examples if you use the search feature.

[Nijin K]

hi garin

I was not able to get any example can you provide me the links to those

[Garin Walsh]

Try going through https://community.broadcom.com/enterprisesoftware/communities/community-home/digestviewer/viewthread?MessageKey=9446b3c6-17d5-4fa0-9255-efa771b2b035&CommunityKey=170eb4e5-a593-4af2-ad1d-f7655e31513b&tab=digestviewer#bm9446b3c6-17d5-4fa0-9255-efa771b2b035

[Nijin K]

hi garin 

i checked the threads and understood that i need to create a small lua script for this but unfortunately i am not familiar with lua so i would require some guidance on variables that can be used for uim which can help me create a script in which i can match message from certain alarm from a certain probe and can change its suppression id

[Luc Christiaens]

from techdocs:

Custom Pre-Processing

The event table is placed into the Lua context prior to executing the "custom" pre-processing rule. You may alter (launder) the event by setting these fields: message, level, sid, source, hostname, user_tag1, user_tag2, visible, custom_1 through _5, supp_key, and origin. The following fields are present for the script to use:

.source     - source of the alarm (typically ip-address)    
.hostname       - resolved name (robotname or ip-address to name resolution)    
.level      - severity level (0-5)  
.sid        - subsystem identification. 
.message        - alarm message text.   
.origin     - origin of the alarm (stamped by nearest hub, or in some cases the robot.) 
.domain     - name of originating domain.   
.robot      - name of the sending robot.    
.hub        - name of the nearest hub to the sending robot. 
.prid       - name of probe issuing the alarm.  
.user_tag1      - user tag 1 (as set by robot). 
.user_tag2      - user tag 2 (as set by robot). 
.supp_key       - suppression identification key.   
.visible        - flag for visibility (true = visible)  

The script is expected to return the event (modified or not) or nil. A nil indicates that the event is to be skipped.
Small example to set a probe value if probe name is not filled in
-----------------------------------------
-- in case there is NO probe name
if event.prid == nil then
event.prid = "no_probe"
end
-- update event
return event
------------------------------------------

[Keith Kruepke]

So for your specific case, here is the easy part of the Lua script:

event.supp_key = "new_custom_suppression_key"
return event​

The (possibly) hard part is making sure the script uses the right value as the new suppression key.

[Nijin K]

yes keith 

I also reached the same lua now i am just confused on how to match a particular string or word from message text so that i put the above condition after the probe and word has from message has been matched

[Keith Kruepke]

Not sure if you've seen this reference before, but I find it super helpful:

http://lua-users.org/wiki/LuaShortReference

Patterns in Lua are very similar to regular expressions, but there are some differences. The two most notable differences are that is uses % instead of \ for escaping, and it is a bit pared down feature-wise. You can do a lot with Lua patterns but not as much as with regular expressions. They will more than likely meet your need though. Importantly, they support using (...) to capture part of the string.

Your code would probably look something like this:

supp_key = string.match(event.message, "pa(tte)rn")

if supp_key ~= nil then
   event.supp_key = supp_key
end

return event​​

[Garin Walsh]

The Google search hits are pretty good for Lua - drop "Lua how to match pattern string" into the search bar and you'll get plenty of responses.

https://www.lua.org/pil/20.2.html

  is the #1 hit and is full of examples.
​

[Nijin K]

hi all

i tried to perform this for dns_response probe with string being matched in event message is failed i came up with something like this

probe = event.prid
if probe == 'dns_response' then
supp_key = string.match(event.message, "/failed/")
if supp_key ~= nil then
event.supp_key = supp_key
end
end
return event
but i am getting error 
Error in line 1: attempt to index global 'event' (a nil value)
what am i doing wrong

[Keith Kruepke]

How are you running/testing the script? The event table is only available when the script runs as part of a pre-processing rule. If that variable is not set, I'm guessing you're trying to run it some other way, which can't work.

Also note that the pattern you pass to the string.match() function does not need slashes around it. If you include them, it will look for slashes in the string. And if you do not include any parenthesis in the pattern, keep in mind the entire match will end up saved in the variable.

I'd recommend setting the pre-processing rule to work on alarms from the dns_response probe only. Otherwise it's going to be running for more alarms than necessary, which will increase the load on the NAS. And then you can even skip checking the event.prid value within the script.

[Garin Walsh]

With this code, I usually do something like:

if ( event == nil ) then
// Supply test data
event = {}
event.prid = 'dns_response'
event.message = 'This is a sample message'
event.supp_key = 'testsuppkey'
end

probe = event.prid
if probe == 'dns_response' then
supp_key = string.match(event.message, "/failed/")
if supp_key ~= nil then
event.supp_key = supp_key
end
end
return event


That will get you past the testing part of stuff and you can use the same code in production.

Keith is correct about setting the filters but keep in mind that nas will run only one preprocessing script and so if you start doing preprocessing you will likely wind up rolling the scripts together into one.

But to go back to your original problem statement, supp_key is used to tie individual messages together - if you start changing and using supp_key for your own purposes, you'll likely wind up breaking other function in UIM - like being able to match the close message to an existing alarm.

Is there a reason you are not using the custom_1-5 fields to put your own data into? The same prerocessing logic can be applied but it would leave the supp_key alone

[Nijin K]

hi garin 

this is how we have been co-relating alarms to application to ticket queue and to severity so normally suppression has been different for different alarms or easily editable but for these probes its not but there so maybe ya if it harm nimsoft functionality we can use custom column

[Nijin K]

if i want to edit custom 1  or 2 what would be the command that i would use

[Nijin K]

i came up with below lines
string_match = string.match(event.message,{failed})
if string_match ~= nil then
custom3 = dns_lookup_failed
end
return event

but it is not working the alarm is coming as it was earlier

[Luc Christiaens]

Field name is: event.custom_3 = "dns_lookup_failed"
try coding the string_match like proposed by Garin ("/failed/")

[Nijin K]

string_match = string.match(event.message,"/failed/")
if string_match ~= nil then
event.custom_3 = dns_lookup_failed
end
return event

still not working any suggestion below is the message in alarm

DNS lookup of 'Domain' failed (type 'mx') on nameserver 'server name' for profile 'profile name'

[Nijin K]

does it take more time for nas to run the rule with script below is the settings

[Garin Walsh]

The warning "take more time for nas to run" is situational. it depends on the hardware you are running on and what your alarm volume is. 

If you are doing one alarm a second and you introduce this, it's one more string compare per second more than nas was doing without the criteria (under the presumption that adding dns_response to the profile criteria is the change you are talking about.) Consider further that string compare is really a series of integer compares and those happen extremely quickly. As such you are probably going to be unable to measure any impact of this change.

Change that to a case where you have added this compare to each of 100 profiles and you do a thousand messages a second and now that simple comparison is multiplied by a 100,000 and that you might see. But then the question is if that slowdown is worth the cost? And if it's a business need then it likely will be.

And to go theoretical on why there's this perception of slowing nas down, I personally think most of that stems from badly written criteria - /.*failure.*/ can run hundreds of times slower than /.*?failure.*/ - note the introduction of ? for force lazy matching on the *.

[Keith Kruepke]

The pattern you are using with the string.match() function will not match anything in that sample alarm text you provided. The slashes are not special in a Lua pattern, so it is looking for the word "failed" with slashes surrounding it. It would only match something like this:

DNS lookup of 'Domain' /failed/ (type 'mx') on nameserver 'server name' for profile 'profile name'

You really need to look at the Lua reference or some other guide. That gives the proper syntax for a pattern.

Also note that as you have the script written, if it actually matched, you'd end up with "/failed/" in custom_3. If that is not what you want, make sure you are using (...) to capture a different part of the message.

[Nijin K]

thanks for the suggestion all

but now i am confused a bit is my matching pattern wrong or the command to set the custom_3 field wrong 

if the matching pattern is right won't the custom_3 field be edited by

string_match = string.match(event.message,"failed")
if string_match ~= nil then
event.custom_3 = dns_lookup_failed
end
return event

[Luc Christiaens]

Example pre-process rule, here with another probe and matching message "unreachable":
1 - define your pre-process nas rule:

Define the probe AND the message string at this level
2 - the lua script:

3 - the processed message:

note1: I used custom_5 because custom_2 and custom_3 are in use
note2: if it still not work, check if you have multiple pre-process rules that "could" match because only the first matching pre-process rule is executed.

[Keith Kruepke]

@Nijin K, I think the script would match, but as written, dns_lookup_failed would be a variable with a nil value.​ If you want to use that as the suppression key, make sure to put it in quotes.

[Luc Christiaens]

Strange repost from a previous update (with all available variables), so removed the reposted text

[Luc Christiaens]

Strange... I did repost previous entry! (with all available variables) (I was even not logon today)

[Guillaume Briere]

Hello,

Don't forget that modifying the suppression_key could also affect the "clear" alarm. If you modify an alarm's suppression_key you also need to modify the "clear" alarm suppression key.

If, by example, you modify your suppression_key base on keyword inside the message. If the clear message is different, it will not match your script and will have nothing to "clear" since the alarm will keep the original suppression_key. That mean your alarm will stays forever inside the alarm console.

If you don't want to handle modifying the suppression_key of the alarm and his clear alarm, you are better to use the subsystem feature, the user_tag or the custom field.

Thanks