Forum Discussion

PattyN's avatar
PattyN
Icon for Contributor II rankContributor II
3 months ago

Suppress a syslog event on a specific interface

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?

event_management
  • BryanHarding's avatar
    BryanHarding
    3 months ago

    '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.

    Ex. 

    (PKT_INFRA-LINK-[35]+-[^\s])+(?=.*TenGigE0\/1\/1\/7)

    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's avatar
    BryanHarding
    Icon for Moderator rankModerator
    3 months ago

    '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.

    Ex. 

    (PKT_INFRA-LINK-[35]+-[^\s])+(?=.*TenGigE0\/1\/1\/7)

    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.

  • SaraLeslieAdmin's avatar
    SaraLeslieAdmin
    Icon for Community Manager rankCommunity Manager
    3 months ago

    PattyN Hopefully Bryan's response helped resolve your question? Please review and mark as the Solution if its correct. Cheers, Sara 

  • SaraLeslieAdmin's avatar
    SaraLeslieAdmin
    Icon for Community Manager rankCommunity Manager
    2 months ago

    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: 

    https://docs.sciencelogic.com/latest/Content/Web_Events_and_Automation/Events/event_policies.htm#Best_Practices

    There are some additional examples under ‘Best Practices for Event Definitions’ on using match strings with different weights and severity levels:

     https://docs.sciencelogic.com/latest/Content/Web_Events_and_Automation/Events/event_policies.htm?Highlight=suppression#Best_Practices

    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:

    Event Policies for Syslogs and Traps (sciencelogic.com)

    I do wonder if this may be tied to:

    Customize the interface configuration when discovering trunk ports | Nexus ScienceLogic Community

    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.

    Thank you.

     

    • jclark's avatar
      jclark
      Icon for Employee rankEmployee
      2 months ago

      One possibility to consider is to have the network administrator be prescriptive about their configurations and to define them in such a way as to ensure only important infraces are configured to send logs/traps.  This way they are in charge of what's happening and can view their equipment to determine if something should be logging or not.  One example for cisco style switches is like this

      interface Gigabit a/b/c
  no logging event link-status

      It is possible in SL1 to use multiple event policies with different priorities with very specific interfaces defined and then suppressing them, but this isn't a very intuitive way.  If a network admin is expecting an event that was missed, this suppression setup won't be an obvious find of them.  They will believe that a message was sent but never received.