cancel
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)
197 Comments
Level 12

I will try this.

Level 15

Peter, we are certainly not trying to hide this thread. Unfortunately we are having some issues with the Ideas platform. It's very inconvienient for us as well as we cannot access some posts to reply to. I'll also follow up with you about your support case.

This is a great thread with a lot of fantastic ideas. I am sorry we have not responded sooner.

It seems the main frustration is about usability of the Win32 app (with some performane concerns as secondary). As I am sure many of you have noticed, we are working on migrating our remaining Win32 apps to the web (this includes Reporting and Alerting). This feedback is extremely helpful when planning what work will be moved to the web and how it will work. I am working with the UX Research team to schedule calls with people who have posted on this thread. We would like to get even more information about what you are doing today and what you would like to see in the future.

In the interest of as much transparency as I can provide - you may have seen the "What we are working on" post that recently went up after the NPM 10.4 release. You will unfortunately notice no mention of Trap or Syslog. However, we are starting to collect more information on this request so we can begin planning for some enhancements in this area after we complete the Reporting work. Of course I cannot make a promise, but the data collection we are starting is good indicator about our intentions.

Level 12

I wholeheartedly apologize for jumping to conclusions when I found this thread link 404'd   I did in fact, clear out cache/cookies, close out my browser, and it came back properly.

I am glad to see you guys getting into the thread, and thanks for your email.  I will send another reply as well.

Many of us noticed the conspicuous lack of mention of Syslog and Traps in the what we're working on thread.  Very happy to see action on this one now, even still!

While we're at it, I'd also mention that being able to roll a proper MIB DB that encompasses our network eq (new and crusty old as well, as it always is) has a definite impact on the Traps issue.  I have a current workaround for Dell/Force 10/Turin DACS traps (Traverse product) that involves of all ungodly things, dipping to a secondary DB on the MSSQL server, just to translate the traps properly.  I cannot imagine it's lost on you what kind of load that puts the RAM cache on the DB server to have to do that 3000 times a minute in some rare cases.  It's a travesty and at the same time, really cool using those stupid vbscript variables.

That is ridiculous.  You guys do not handle this properly with the one-size fits all, oops it's limited to 512MB MIBS.cfg thing.  Do we still need 2-3 different copies of the same file on the filesystem?  It's been forever and 3 years since I looked, because I couldn't take Destiny's updates anymore without breaking too much.

Either 1 of two things is completely acceptable in my mind to handle that.

A)  Package up Destiny's tool, and give it to us, preferably with a very rudimentary win32|64 interface, and lets us roll our MIBs.  Give us the source base Destiny works from, so we can pick and choose what we do and don't need.  Spend no time on shading the buttons.  Seriously.  Make it a CLI only cmd.exe application.  That will keep the people who probably shouldn't mess with it from messing with it, and they can keep using the stock one.

B)  Get rid of the 512MB limitation on the MIBS.cfg and throw *everything* you've ever seen back into it.  Every version of IOS, blah blah blah.  I think B is a worse option but I wouldn't mind seeing B if it were coupled with A and I could live with B, because then I wouldn't have to go dig up and re-send Destiny all the mibs I care about more than 1 final time.

I totally did start a different idea thread about this, but it *is* relevant to traps.. very much so.

Peter

Level 15

Just so everyone is aware SolarWinds has reached out to me as the original requester to step them through the issues and enhancements we would like to see.  I will reread through this thread and try to cover as much of this during my meeting as possible. 

Level 7

We could use the copy and paste feature in other SW section, like configuration manager's compliance section.

Level 12

Any updates Mike?  SW?

Peter

Level 15

I did my session a couple of weeks ago with the UX team.  I had actually received a ticket to create a new rule the day before so I stepped through each part of the painful process.  Manually copying a set of trap actions from another rule, moving it to where it was needed in the chain, manually setting the RGB color codes because the custom palette doesn't save.  I also covered several other topics that were discussed in this chain.  At one point one of the UX team noted to me that the developers were rolling their eyes seemingly embarrassed about how cumbersome and complicated what should be a simple process actually was.  While of course they won't give any commitments about when changes can be expected I do trust that they will happen.

Level 16

what if I say "pretty please" ?


Level 15

It's been almost 2 full months since I did my UX session and I haven't heard anything further.  I know it's not SW practice to update on features until they hit beta but if someone could provide some semblance of an update I think we'd all appreciate it.

Level 13

PLEASE continue to work on this. This is one of the BIGGIST failiings in the Orion product line. so much so, that we are actually discussing moving to a new solution. (there are other factors, but this is one of the biggest).

As more and more infrastructure products use SNMP/Syslog for communications, as well as alerting, it is more important now than ever, especially for me, to be able to leverage the Advanced Alerting options we have with NPM and Syslog/SNMP traps.  Personally, I have had at least 3 instances that a device was sending traps about a failure, only to be missed because of the clunky, non-user friendly way we have to create rules.

ITS PAST TIME to overhaul these.