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.

FormerIdeaCreator

Top Comments

Parents

ChrystalT over 10 years ago

I would also like to add Macros to the various trap and syslog tables. Right now for traps, you can only pull in from the Trap table. We are wanting to pull in the RuleName similar to being able to pull in the AlertName in Alerts.
- Cancel
- Vote Up +2 Vote Down
- More
- Cancel
mdriskell over 10 years ago in reply to ChrystalT

Wow that would be extremely helpful. I can't tell you how many times I ended up using a color code to try and make sure that the trap hit a certain rule. However I do foresee one issue. If the rule doesn't have a stop processing it could hit multiple. I put stops in all rules but I can't guarantee everyone does.
- Cancel
- Vote Up +1 Vote Down
- More
- Cancel
mbrison over 10 years ago in reply to mdriskell

I took a step further (beyond color coding). Every rule I have tags a trap with my rule name. Then when I search through traps, I can sort based on tag. This saves me a lot of time and allows me to look through only the alerts that are related to a specific triggered rule. I still need to use color coding and other means of making traps stick out, and this does require a stop processing alert action or it defeats my efforts. I also have to use the server side Trap View to search my rules. The web GUI isn't helpful because of it's limited options for filtering. I am running 10.4.1 and running it with FOE.
On a side note: I don't know if there is a discussion pertaining to FOE, but I would strongly discourage the use of an FOE based on my experience. Without going too far on the tangent, the product complicates any SW updates and server maintenance and also does not play well with applications (i.e. anti-virus applications) that require the standby server to have some network presence.
Back to subject, it is simply crazy that there have been no developments for traps in the past unknown number of releases. I know this is not a feature that makes good selling points (not visually stimulating), but the lack of functionality makes the product difficult to use. This really needs to be bumped up in priority.
- Cancel
- Vote Up 0 Vote Down
- More
- Cancel

Comment

mbrison over 10 years ago in reply to mdriskell

I took a step further (beyond color coding). Every rule I have tags a trap with my rule name. Then when I search through traps, I can sort based on tag. This saves me a lot of time and allows me to look through only the alerts that are related to a specific triggered rule. I still need to use color coding and other means of making traps stick out, and this does require a stop processing alert action or it defeats my efforts. I also have to use the server side Trap View to search my rules. The web GUI isn't helpful because of it's limited options for filtering. I am running 10.4.1 and running it with FOE.
On a side note: I don't know if there is a discussion pertaining to FOE, but I would strongly discourage the use of an FOE based on my experience. Without going too far on the tangent, the product complicates any SW updates and server maintenance and also does not play well with applications (i.e. anti-virus applications) that require the standby server to have some network presence.
Back to subject, it is simply crazy that there have been no developments for traps in the past unknown number of releases. I know this is not a feature that makes good selling points (not visually stimulating), but the lack of functionality makes the product difficult to use. This really needs to be bumped up in priority.
- Cancel
- Vote Up 0 Vote Down
- More
- Cancel

Children

No Data