Implemented

SNMP Trap & Syslog Rules Overhaul

In my opinion these two items have been neglected by SolarWinds for many years.  We use SNMP trapping extensively within my organization and every rule we have to create is an arduous process.  Ideally there are several aspects of both of these functions that should be improved upon.

1.  Copy/Paste rule creation.  When we look at alerts we can take a similar alert and make a copy of it altering the rule to suit our needs.  This element doesn't exist in the SNMP or Sylsog rules.  Each rule must be built from scratch.  For example I have multiple rules that are exactly the same with the minor exception being one specific OID for Netscaler traps.  If the OID equals one of our web servers we send it to the web team...if it is one of our exchange servers we send to our messaging team, and so on.  However to build these rules we have to manually create.

2.  Import/Export actions.  In alerts you can import/export an action for use within another alert.  This functionality is missing from the Syslog/SNMP rules.

3.  Enhanced ordering.  At my last count I have 160 + SNMP rules.  These rules are top down ordered.  When I create a new rule it is placed at the bottom.  If I need that rule to go to the top I have to click my mouse 160 times to get it to the top (no wonder I've had carpal tunnel surgery on both hands).  A drag an drop feature would solve this issue.

My first three requests I would think should be relatively simple because these features exist today within other components of SW.  The 4th I assume would be a little trickier to accomplish.

4.  Treat SNMP/Syslog rules like alerts that must be acknowledged (if desired).  Right now if I get an SNMP trap that I would consider to be critical it sends an email. It is not treated like an alert that requires acknowledgement.  I understand this would be a much greater challenge because you would have to have well defined reset scenarios.

I know that I am in the minority in this as it seems that many other members of the community rely less dependently on traps but they are a part of our environment and they aren't going away.  As they continue to grow I will be forced to look for alternatives to SW in this space if SW doesn't evolve these areas.  I have been using SW for 6 years and I have seen little to no improvement in these two areas.  I had hoped with the acquisition of Kiwi there would have been some nice improvements but alas that isn't the case.

Parents
  • Hi All,

    We are considering making some improvements to Orion's log management capabilities. We'd really like to hear how members of the Thwack community are managing log data in your environments and are therefore running a Log Management Survey and would really appreciate your response. It takes <5 minutes and upon completion you will be entered into a draw with a chance to win one of ten $50 AmazonRegistered gift cards*.

    Survey Link - SolarWinds Log Management Survey

    Also, I'm very interested in talking to users about their current log management practices, so if anyone is up for a quick discussion, please send me a direct message.

    Thank you!

    *Terms & Conditions available here.

  • jhynds

    Rather than see this ancient heavily upvoted issue get dumped onto a separately licensed product, we need the core product functionality issues to be resolved.

    I can't make the point any clearer than saying SNMP Trap handling does not belong in LEM by any stretch of the imagination. 

    It is one of the two core SNMP methods to get data on something.

    I looked at LEM, but the fact is 99.9% of the product was geared towards windows event log monitoring, which while is nice to
    have for ancillary systems on the network, isn't at all useful for equipment that sends primary notifications via SNMP trap.

    Sure there's things that can be done to translate traps to syslog, or translate traps into even windows event log, or use offboard systems like SEC
    to pre-parse traps and even take the place of all the functionality the core NPM trap server has, and has been stuck with since this feature request
    was made.

    Too much attention still, is paid to the enterprise needs. 

    While this is a wonderful and rewarding segment for you guys to gear the product to, aka, the Cisco/Windows/VMWare crowd,
    it's almost to the point where the product really isn't viable for an SP network, because you guys refuse to put any attention at all to the
    core functions SP's care about.


    Peter



Comment
  • jhynds

    Rather than see this ancient heavily upvoted issue get dumped onto a separately licensed product, we need the core product functionality issues to be resolved.

    I can't make the point any clearer than saying SNMP Trap handling does not belong in LEM by any stretch of the imagination. 

    It is one of the two core SNMP methods to get data on something.

    I looked at LEM, but the fact is 99.9% of the product was geared towards windows event log monitoring, which while is nice to
    have for ancillary systems on the network, isn't at all useful for equipment that sends primary notifications via SNMP trap.

    Sure there's things that can be done to translate traps to syslog, or translate traps into even windows event log, or use offboard systems like SEC
    to pre-parse traps and even take the place of all the functionality the core NPM trap server has, and has been stuck with since this feature request
    was made.

    Too much attention still, is paid to the enterprise needs. 

    While this is a wonderful and rewarding segment for you guys to gear the product to, aka, the Cisco/Windows/VMWare crowd,
    it's almost to the point where the product really isn't viable for an SP network, because you guys refuse to put any attention at all to the
    core functions SP's care about.


    Peter



Children