Orion Syslog/Trap - what we're working on...

Item #6 is one we would love to have implemented - I'm always asked by our Operations people why I must send e-mail alerts when they have the alerts screen in front of them.

A couple of other related suggestions in the same area if I could (they might be already addressed in 9.5, but I'm holding out for a few more weeks).

The service that writes the SNMP traps into the database appears to be single threaded in some way, or at least during peak times it falls behind in performing the table insert in our implementation. You can see the memory increase on the service, and the timestamp of the last SNMP trap falls further behind. I've opened a number of records back to version 7.x, but the performance hasn't changed (although our database server has been upgraded a few times).

The web page interface for viewing syslog records is also very very slow. The page refreshes on us before you can perform any useful activity. We RDP onto the poller to view the syslog messages - it's very quick if we don't use the web interface. Once again this has been the subject of a number of problem records. Database traces show that the records get returned to the web server very quickly, meaning that something is going on within the web presentation layer (maybe it's the parsing of the 5000 devices that appear in the drop-down box each time the screen refreshes).

Happy to open up a couple more problem records if you don't think changes were made in this area for 9.5.

Thanks for taking the time to inform us of possible future enhancements - it's great to understand both the direction and your priorites.

Dave.

Out of interest Chris, is the ability to strip out the "Original Address=192.168.1.1" type tag (that kiwisyslog can insert when forwarding a syslog) on the list somewhere.

As kiwisyslog and Orion users, we would love to be able to log forwarded kiwisyslog messages under the real address within Orion (firewalls prevent us using the spoofed udp method).

Dave.

Yes, that's definitely on the list.

I was also hoping that #6 would be of higher priority. We have been asking for that feature for quite some time. Same reasons as the above user.

Good news that syslog and snmp traps are getting worked ok.  Have been wondering if bringing onboard the Kiwi stuff would bring extra features anytime soon.  I've been especially surprised the SNMP trap console is so basic compared to the Syslog console in terms of alerting/filtering etc - it definitely needs some love!

We use syslog very heavily but it was only recently that we started looking at using snmp traps more since we're looking at retiring some old hp openview installations that the subject of snmp traps came up and I found it was missing all the great alerting features present in syslog.

I'm especially looking for #2 and #3.  Pattern matching is sorely missed in snmp traps - works very well in syslog and I was disappointed at the lack of finesse available in the SNMP compared to Syslog console - I could only send the entire msg and couldn't filter for specific content only.

#3 would really be helpful - I send emails based on incoming syslog msgs and include a link to the device - unfortunately I can't get the NODEID so all I can send is a search string with the IP or hostname which isn't ideal - would be nice to get straight to the device rather than to the search page.

 One thing I'm also looking for is a way to export all the Alarm config I have in syslog (and similarly trap alarms) so I can import on other solarwinds servers and share with my colleagues (and thwack perhaps?).  I've created a lot of custom alerts for servers/switches etc looking for specific event log/syslog msgs and even sending web links to cisco/microsoft pages to resolve that issue - we have this ability in UNDP - lets get in the syslog and trap consoles...!

Looking forward to the upgrades - sounds like great features!
Sean

Number one is extremely valuable - smart 'parsing' of traps would be excellent.  Being able to trim the fat from a massive trap with 15 varbinds is great.

Although when you say 'vbData1' 'vbData2' do you mean to interpret this as tokenized output, or will we be using the actual MIB values from MIBS.cfg for interpolation?

Thanks for the feedback.   We will use the same values you see after the "=" for each varbind in the Trap Details today if that's what you mean by the actual MIB values.

Chris,

When you implement #6 will those alerts then also show up in the Event Log as Alert Triggered and Alerts Reset ?

Thanks, Chris - I do understand that comment.  This is exactly how the filtering and 'smarts' should look like.

When you implement #6 will those alerts then also show up in the Event Log as Alert Triggered and Alerts Reset ?

Yes, they should.