Forum Discussion

teppotahkapaa's avatar
teppotahkapaa
Icon for Leader rankLeader
2 months ago
Solved

# of trap event policies and collector load

Question about collector event management load versus number of defined event policies. 

We just got requirement to add some 800 trap event policies into our SL1, and I started to wonder what kind of effect that will have in collector load. So, when trap is coming in how is that checked against defined event policies. For example how much it slows collector if number of trap event policies go from 2k to 3k? Especially when there is anyway quite constant "flood" of traps anyway more or less all the time.

And because there is still (SL1 12.1.*) no way to tell that "use these policies on this CUG only" but all the policies will be distributed to all CUGs, so the load is added everywhere.

  • ErickBurgess's avatar
    ErickBurgess
    2 months ago

    Hi Teppo, I ran this question by one of the event engine developers.  SL1 Trap event processing includes a pre-filter for OID.  

    If you are adding 800 new event policies each with a different OID, a new trap received for one of those policies is just a single lookup and doesn't add any extra load. 

    If you are adding 800 policies using the same OID with different matching rules, that would add the load Tony described.  All 800 polices would be searched for a match for every trap including that OID.

    Regards,

    Erick

  • TonyAndres's avatar
    TonyAndres
    Icon for Moderator rankModerator
    2 months ago

    Hello Teppo,

    Per the design of the Event Engine, every time a SNMP trap is received by SL1, it is compared against every single Trap event policy for a match. Once a match is found, it then checks to see if all other conditions are met before the event is triggered. The performance impact would be that the amount of time to process each incoming trap will become longer and longer. While we do not have any concrete figures, eventually, this may result in SIGTERMs if there are too many traps and too many event policies to compare against.

    To reduce the impact, we recommend sending SNMP traps and syslogs to message collectors, load balanced to split the load evenly. This will prevent the performance impact from affecting data collectors and reduce the performance impact across all of the message collectors evenly.

    Antonio Andres

    Senior Technical Support Engineer | ScienceLogic

    • teppotahkapaa's avatar
      teppotahkapaa
      Icon for Leader rankLeader
      2 months ago

      Hi Tony,

      so, adding 50% more policies will take 50% more time in Event Engine, generally said. 

      The unfortunate reality with this case is knowing that those traps can come only to one message collector, but then the same load affecting to 20 others. 

  • TonyAndres's avatar
    TonyAndres
    Icon for Moderator rankModerator
    2 months ago

    Hello Teppo,

    Unfortunately, we do not have a way in the product to limit event policy scope by CUG. I recommend submitting this feature request to our Idea's Hub Category: Ideas Hub | Nexus ScienceLogic Community.

    For now, you can suppress devices or device groups in the Suppression tab for the event policy, which will cause it to skip that event policy during when the event engine reviews the incoming traps.

    Antonio Andres

    Senior Technical Support Engineer | ScienceLogic

  • ErickBurgess's avatar
    ErickBurgess
    Icon for Moderator rankModerator
    2 months ago

    Hi Teppo, I ran this question by one of the event engine developers.  SL1 Trap event processing includes a pre-filter for OID.  

    If you are adding 800 new event policies each with a different OID, a new trap received for one of those policies is just a single lookup and doesn't add any extra load. 

    If you are adding 800 policies using the same OID with different matching rules, that would add the load Tony described.  All 800 polices would be searched for a match for every trap including that OID.

    Regards,

    Erick