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
  • I would like to see it work with a single alert mechanism. At the moment the Trap, Syslog, and core NPM alerts are all completely seperate enities and alert actions have to be built seperately in each. There is very little integration other then being viewed with a single log on. It seems that one ought to be able to trigger an alert from Traps or Syslog which associates the customized alert with the device that sent it. Then all alert actions could be set using the advanced alert manager and it would all behave as one alert system rather than 3 independent ones.

  • As I write this, I am creating 98 new trap alerts.  Each one will write to the event log, then an application in SAM will watch the event log for a 3003, then Orion will kick off an alert that will generate a ticket in Remedy, email the affected groups and display an event on the multiple different dashboards.

    Not very efficient.  Using the event log is a process that should not be needed.  When I explain this to management they complain and lose a little faith in the system....


  • I use a very similar configuration only we use SCOM and HP Service Center.  It is bulky, and somewhat embarassing to explain how it works.  Not to mention, the people who handle SCOM are not in my group.  If I need anything changed or updated, I have to re-explain this via a whiteboard and markers with fumes that make me feel loopy.  30 minutes later I have the munchies and glazed over looks from the audience.

    The other issue I have is the content of the traps is ofter distorted.  They may as well be hieroglyphics.  We have an added step where an operator will monitor SCOM for alerts and then create incidents in HP Service center (non-automated). At one point, there was a SCOM/Orion management pack, but it did not prove to be useful and I was informed that the person who wrote it no longer works for SW.  This may have changed since I last dealt with it.

    Regardless, there really should be a cleaner way for us to automate taking a raw trap, parsing and/or deciphering it, and then making a meaningful action. If this requires making many rules (I see no way around this) then the product should be better designed to allow ease of creation of these rules and ordering them as noted.  

Comment
  • I use a very similar configuration only we use SCOM and HP Service Center.  It is bulky, and somewhat embarassing to explain how it works.  Not to mention, the people who handle SCOM are not in my group.  If I need anything changed or updated, I have to re-explain this via a whiteboard and markers with fumes that make me feel loopy.  30 minutes later I have the munchies and glazed over looks from the audience.

    The other issue I have is the content of the traps is ofter distorted.  They may as well be hieroglyphics.  We have an added step where an operator will monitor SCOM for alerts and then create incidents in HP Service center (non-automated). At one point, there was a SCOM/Orion management pack, but it did not prove to be useful and I was informed that the person who wrote it no longer works for SW.  This may have changed since I last dealt with it.

    Regardless, there really should be a cleaner way for us to automate taking a raw trap, parsing and/or deciphering it, and then making a meaningful action. If this requires making many rules (I see no way around this) then the product should be better designed to allow ease of creation of these rules and ordering them as noted.  

Children
No Data