How might one go about suppressing a syslog event for a specific interface, but still receive all other events for that device and interface?
For example, you have a syslog event message like:
5238379<187>267450: LC/0/1/CPU0:Aug 20 17:38:21.939 EDT: ifmgr[214]: %PKT_INFRA-LINK-3-UPDOWN : Interface TenGigE0/1/1/7, changed state to Down
Your existing event policy uses regex match logic as follows:
First Regular Expression:
PKT_INFRA-LINK-[35]+-[^\s]+
Second Regular Expression:
to.*(DOWN|Down|down)
Identifier Pattern:
Interface\s+([^ ,]+)
Identifier Format:
Interface: %1
Would you modify the event policy in some way? Is there other levers/knobs to in the system to tinker with that might get you the desired result?
Best answer by BryanHarding
'As you cannot suppress events via sub-entity (what you're extracting with Identifier Pattern, in this case "TenGigE0/1/1/7") I would suggest that you have two Event Policies; one with a lower Detection Weight that includes "TenGigE0/1/1/7" within one of the required matches and is marked for suppression against the particular device and a second Event Policy with higher Detection Weight to match the remainder.
In theory you could also choose to invert the approach by having an event policy that only matches if it doesn't contain certain text with a second event policy that catches all and suppresses against specific device(s), but depending on how many policies and devices you're managing that could change which approach makes more sense.
'As you cannot suppress events via sub-entity (what you're extracting with Identifier Pattern, in this case "TenGigE0/1/1/7") I would suggest that you have two Event Policies; one with a lower Detection Weight that includes "TenGigE0/1/1/7" within one of the required matches and is marked for suppression against the particular device and a second Event Policy with higher Detection Weight to match the remainder.
In theory you could also choose to invert the approach by having an event policy that only matches if it doesn't contain certain text with a second event policy that catches all and suppresses against specific device(s), but depending on how many policies and devices you're managing that could change which approach makes more sense.
@BryanHarding PattyN had wanted to give some additional context but was experiencing an issue posting her content so I am publishing on her behalf here:
My last reply got lost, so let me try this again.
Thank you Bryan for your suggestion. I don't know which specific path my customer will choose, but I'll mark your post as a solution.
I met with my customer after talking with support a bit. Your suggestion was a variation on some of the suggestions I got from support. We talked about making multiple event policies with weights and multi-match settings and then using device groups for suppression. We looked at some example documentation here in the ‘Defining Pattern Matching and Advanced Behavior in the Advanced Tab’ section regarding detection weights:
We also talked about the possibility of filtering the syslog messages from the source so that SL1 never evaluates them. (I believe this is the route that my customer is going to opt for investigating next.) We talked about the idea of using the Registry > Networks > Interfaces menu to find your target interfaces and then use the bulk action menu to adjust the severity level on an interface. Based on the documentation, it looks like the event policy then would also need to be updated to checkbox the ‘Use Modifier’ option on the Policy tab in order to evaluate the severity setting for the interface with respect to the event policy. The related documentation for that is found here, under the 'Use Modifier' section:
This feature request looks to combine about 3 different threads all related to ability to group interfaces in some way for discovery, reporting, dashboarding, etc. It might be worth some up-voting for a new feature request.
