sysname variable in trap alerts

I have been waiting patiently for this app to allow the same level of functionality as the syslog viewer.  The syslog viewer makes up for a lot by being able to both do message tylpe variables as well as key word variables in the message content.

 Ah the sound of silence.... Sigh I was half hoping to get zinged for not knowing about some forth coming developments that would resolve these issues..

 I think what you're asking for are more variables in Syslog and Traps.  Our roadmap has work on both Syslog and Trap alerts to make them more like Advanced Alerts, but I don't have a timeline yet.

I'd like to see this too.  The alerting to the log file would be much more useful if I could fashion the file with only specific information from the trap.   The whole message regurgitated into the log makes parsing difficult. 

When we will see some movement on this request?  Trap alerts are messy.  Here's what I would like:

1) No separate traps alert configuration - put them in the Advanced alerts.  Ditto for Syslog events.  Three separate alert consoles is dumb.

2) Full set of macros so we can get ${Nodes.Caption}, special properties, etc.  Today I have to manually create host records for approx 1000 network devices in Active Directory just so Orion can populate ${Hostname} on a trap alert.  This is silly since the Traps table already has the NodeID.

3) Ability to reference individual VARBINDS records using the index field so I can avoid clutter created by the vendor.  Usually the useful content is in 1-3 of the VARBINDS records.  Or better yet, let us define a trap template for our devices along with the mapping to OIDs so we can stop storing denormalized raw VARBINDS data.  This would also allow us to discard unnecessary data and keep the TRAP table size under better control.

4) Some self monitoring/alerting by Orion when trap service fails or is getting overloaded.  I realize I can do my own independent monitoring for trap warnings in the window event log but I think the monitoring tool should provide some built in proactive information for the administrator.

5) Expand the Trigger Threshold to include the entity in VARBIND records.  If you have a device with multiple components, say fans or drives then you really want to fire traps based on IP-Drive ID or IP-Fan ID not just IP.  You naturally need to monitor the more complex and expensive equipment and these have many components.  In our shop, one storage raid head contains 125 individually monitored components.

There is a SW post in Thwack suggesting some of the Syslog/Trap stuff that they are currently working on...