Showing results for 
Search instead for 
Did you mean: 
Create Post

SNMP Trap & Syslog Rules Overhaul

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.

Tags (1)
Level 15

Uggh.....I'm going to have to start kissing babies or getting a lobbyist to get this more votes....Had to create 6 rules today (all with basically the same settings) with the simple difference of something in the trap details causing the emails to have to go to 6 different groups.  Took me an hour because there is no copy/paste.

Level 21

Yeah, I agree that there is still a lot of room for improvement here so I am going to vote for this as well.  I would also like to see this functionality moved to the web console as it's one of the few things I still need to login to the box for. 

Level 12

Between this and the UnDP's lack of functional 2D table handling, these are two that have been painful for quite a while.  +1 on this, and please.. all you folks who don't understand this because you don't pay attention to syslog and traps, please vote for it..


Level 15

Great point Peter.  Even though there are many customers that don't use syslog or SNMP they are a staple of any well rounded network management product and should not be dismissed.

Level 16

I have begged for this for years as well.  So many people want to send me traps as if that is a great thing.  I now create a trap rule to log to an event, then I have an app that watches the event log for that trap....  too messy...

I'll chip in for a lobbyist  🙂

Level 15

Great...I had to write three rules today that had to go near the top...over 150 clicks each to move them up.

Level 12

Yeah, it would be so much easier if there was simply a "rule number field" that could be edited and have it be smart enough to insert it above whatever rule number it was replacing, shifting the whole list down.

Even better would be able to manually set the rule number to a random number between 1 and say 65536, so that I could set ranges of rules based on devices and organize that interface that's good for 20 trap rules, but horrible for 200.


Level 13

sorry I didnt see this sooner - this is becomming a MAJOR item on my list. With more and more devices using Syslogs, better rules are becomming a necessity.

I have, like some others, been waiting for this to be better with Orion. I am almost to the point of using a "Non-Solarwinds" tool!

Level 15

Finding a new solution is on my list of things to do. 

Level 12

One additional comment on the whole syslogs and traps rules thing, in general and I guess this goes for Advanced alerts as well..

I'd like to be able to truly import/export my alerts.  Specifically, I'd like to create an alert, export it, make some minor changes that would be of course, database driven, and then be able to bulk import the new pile of alerts with complete actions that are unfortunately very often manual per alert.  Things like trap handlers, where I create one that tracks down one specific trap, but I have a list of OID's, and a list of ideas of what I want to start with for alerting points in the case of Advanced alerts, in the case of traps, there might be one trap that I need to parse literally 200 times with a different rule just to get the behavior I need, based on what I can *actually* pick out about the trap details.

Another thing is the handling of traps when they come in.. the only way I could get detailed trap data into the traps was to go out and translate on an external DB running on the SQL server, it's pretty janky, to be perfectly frank, and the data is in the source MIB, which happens to be a Turin-->Force10-->Dell product.  Other trap and syslog use-cases can be worked around, but in a truly inferior fashion.

Probably the biggest part of the problem is really the limited parsing engine in the first place, and the fact that the level of sophistication that ANY part of NPM has about deltas over time, or quantity-based alerting, is pretty much non-existent.  It's the fault of the complexity of relationships between events, rules, and actions, simply doesn't allow alerts to be crafted that would cut a broader swath.  This makes extensive efforts at making them manageable at scale, of course, terrifically important, but it's really that SW can't quantify anything relating to "time or quantity over time" in the product, except for simplistic single oid statistical values.  Imagine, if I get 16 syslog messages, I may not care, but if I get 16K, I'm really going to care, even though I may have NO defined alerts of my own.  It's watching statistical deltas in events like that that is crucial to monitoring a network, and it's largely done by the seat of our pants, relying on SW heavily.

Just to digress slightly more, deltas over time on basic port utilization.  If usage on the port is normally running 70/55Mb say, and it suddenly spikes to 90/90, that's a delta change we could have never predicted.  I did consider offloading this task to a perl framework that would go out and watch this stuff, and set a custom property value for base values, and then attempt to have an alert trigger off of a percentage increase in actual over base, but it's honestly a bit overly complicated, and should be something you guys should be doing for us.

I'm kind of sick of the fact that screen-watching and stare and compare are pretty much the only option for catching many critical types of network events.  This product isn't supposed to be about bio-automation.

I already have, and would most certainly continue digressing this particular feature request into a huge review of everything that it could touch, but I'm trying to exercise a modicum of restraint