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

There have been a lot of requests for enhancements to Orion NPM Syslog and Trap capabilities in various threads and we're tackling quite a few of these in our next Orion NPM release. I've responded to the individual threads, but I realize nobody has time to read every post so I thought I'd consolidate the list of enhancements we're working on:

1. Ability to reference Trap variable binding names and value pairs as variables in alert messages (e.g. ${vbName1}, ${vbData1})

2. Ability to configure Trap alerts based on pattern matching on Trap Details field (similar to what's possible for Syslog messages)

3. Ability to reference Orion node variables in Syslog and Trap alerts (if source IP address of message exists as a managed Orion node)

4. Respect Orion NPM unmanaged node status in Syslog and Trap alerts

5. Ability to change the status of an interface in Orion NPM based on a Syslog or Trap message

6. Ability to make a Syslog or Trap alert show up in the alert list in the Orion website

PLEASE NOTE: We are working on these items based on this priority order, but this is NOT a commitment that all of these enhancements will make the next release. If you have comments or questions on any of these items (e.g. how would it work?) or would like to be included in a preview demo, please let us know!

Thanks!

Find more posts tagged with

Accepted answers

All comments

savell

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.

savell

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.

chris.lapoint

Yes, that's definitely on the list.

Congo

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.

smcdonald

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?

chris.lapoint

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.

Ralphr

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.

chris.lapoint

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

Yes, they should.

bgrossman

What about a master view of Alerts? I have trouble getting others to understand that there are three completely separate sets of Alerts in the System...a single unified view would be very helpful --- even if it had to lead to three different Editor screens due to options differences.

AZ_Tech

#6 would be a plus for us, we struggle to manage the number of machines we have and being able to get the most out of syslog and alerting is critical for us. We have multiple sites and want to be able to pool messages from network devices and servers to one location, filter and forward the critical stuff to a single location. That location would be great if it was the orion with both monitoring, alerting and logging. But in the past Orion could not handle the volumn of messages and the alerting was just to cumbersome and hinky. I have just purchased the Kiwi to install at each location for first level logging and hope to forward to Orion we hope this will reduce volumn and non critical messages. We have used Kiwi before but had moved away. The new web interface brought us back to test again. Each time we have ended up going back to linux with syslog-ng to handle the volumn and filtering we have but this leaves our techs out of the loop that don't savy grep etc. A good web interface for our syslog needs would allow filtering easy enough to use for our average tech to leverage it. So what we hope for is to be able to filter and forward and to be able to send alerts based on desired log messages, device status etc. If we can filter it well enough and control the out put of the alerts we would have it send critical stuff via SMS and potentially create a help desk ticket in our help desk ( Which supports email to request creation). Right now we send our alerts with a seperate server, log with linux and trend with Orion. Life would be much easier if we could leverage one server. We just upgraded from 8.0 to 9.5 to get a look to see how far Orion has come, we have been running Orion for years but stopped upgrading at 8.0 mostly due to price. Unfortunately we haven't been able to make it run reliably since the upgrade. We have to many servers anymore to be able to hunt through event logs, and to many devices, we have to get this working better. We are looking at several solutions but haven't found many that work much better than Orion for trending. Syslog and alerting is critical for us. If orion could handle this as well as it trends I would be a happy camper.

Ralphr

According to Chris L. once they implement number 6 the Trap and Syslog alerts will show up in the Event log as Triggered and or Reset Alerts. Our plan would be to leverage this as our "Master View"of all alerts.

droberts29

Add another to the growing list of people interested in item #6!

mtxpert

Looking forward to this functionality as well!!

clint1

#1. We have all so many applications that could send trap messages with stirngs of informaiton. One that everyone could use that is active in our environment is that one of our APC devices shows a High voltuage input status but the trap that is sent via email or page only shows the source and the MIB that was triggered. Why can't the trap show the text in the trap that spells our in plain English "mtrapargsString=UPS: Compensating for a high input voltage." This should have been cought in dev. a long time ago. Why trap if you can't forward the message in full to an email, pager, or sms.

shanepj

How long until we get to use this? We are having mass issues right now with using the trap receiver to the point we have begun looking into other vendors for this part of our toolset. Everyone of these would be a big deal to us, specifically #1 and #5.

duelunds

We have similar requirements and this feature would be a huge help for us. The ability to recieve traps from switches and backup devices and change the NPM icon status to suite the traps.

wouldn't mind knowing time frame on this as well.

mleeman

#6 is #1 with our organization. Please, Please, Please.

Thanks

Mike

byrona

It would also be nice if it pulled the detail information from the MIB that explains what the trap is, having this available with the trap or when you click on it would be nice.

The reason that this is important is because many traps such as HP has one trap for a single thing such as a drive array state change and all the trap tells you is the state number it changed to but without the reference for what those numbers mean the trap isn't very useful. State 1 may be NORMAL while state 3 may be FAILED.

In one of my other posts I also talk about the need for this...

mkomeara

#6 is a priority for us, with #1 right behind it.

Thanks

KenKasmar

Are there any updates on the status of these changes (#1, #3 and #6 specifically)?

Thanks

jmlivingston

Are there any updates on the status of these changes (#1, #3 and #6 specifically)?

I'd like to know if there's been any updates as well, especially for #6.

John

jkennemer

These would all be big with us; #6, #5 , #1 in priority.

Service Delivery Manager
Managed Network Services
Dr Pepper Snapple Group

jasadelll

Any updates on this, now that V10 is out? I'm particularly interested in #6.

bshopp

That particular item did not make v10, however, is high on our list still

FormerMember

on 3. would you be able to suppression alert it the node is unmanaged in npm?

buzzwork

any news on #6 when this is comming ?? still waiting for that function

Martin

mleeman

Been waiting for #6 as it would be very useful in a real time environment. Please correct me if I'm wrong. If an interface were to drop and come back up before the next poll cycle. Orion would not see it. If we can action alerts to the console on traps, then we would know immediately once the trap is/if received.

Thanks

thamizh85

Yup, if Interface flapped polling cannot spot it, traps would be the way to go.