Here is my top 10 (okay, my top 11 in order) that I'd love to see in the next release of SolarWinds. That is if I controlled the world.
1. One alert engine. Configure alerts for events, syslog, traps from one interface and have all alerts listed in one place.2. Connect to relationship between nodes, or interfaces and nodes. I want to know what is connected to a switch, so when the switch goes down I don't get alarms for every node connected to it.3. After database is created and an account is created to manage that database, then no more SA privileges needed for Database Manager, and software upgrades.4. Multiple elements on one graph. I'd like to graph more than one custom poller on a graph, or if I wanted to to see bandwidth and CPU util on one graph. Whatever, just give me the ability to graph more than one thing.5. Change columns in advance alerts. I want to see the alert message, and current value of the alerts. Not group advanced alerts, just list them. I hate that I can't un-group the advanced alerts.6. Ability to un-manage a node or interface from the web.7. The ability to edit multiple nodes, or interfaces at once. For example, if I need to change the SNMP community string on all nodes.8. Ability to gather statistics of an interface, but I don't care if it goes down, so don't alert on it. Ability to turn off alerting on interfaces.9. Don't just roll up node up or node down status in node icons, but also roll up node problems (CPU, volumes, alerts from traps, syslog, custom pollers).10. Auto-discovery abilities in NPM.11. LANSurveyor to use NPM database to make map. Don't want to discover my entire network multiple times.
jds:3. After database is created and an account is created to manage that database, then no more SA privileges needed for Database Manager, and software upgrades.
Wasn't this addressed in 8.5?
Nope. I still can not add a SQL server in the Database Manager without SA privileges.
All of jds' items are definitely on my list. Another one I wanted to add was to have the new custom MIB poller use the polling engine's time to generate a time stamp, and not depend on the database to assign a timestamp when it gets written. Here's my problem:
Network Device, Poller, Orion Web Server - all on UTC
Database (on a separate server cluster and managed by another group) - on local time.
This leads to a device with custom MIB graphs showing a 5-6 hour gap in data. The canned graphs are all on the correct time.
We're moving toward UTC. The challenge is that we have multiple modules with different release schedules. So what's going to happen is that Orion and the modules will start to migrate to UTC, but for a while there will be some sections in one and some in the other. While this approach is not ideal, the alternative is to wait until we can move everything at once, which is tantamount to saying we'll never do it.
I have to echo a strong need for item #1 in particular. The separation of syslog, traps, and polls is a constant source of frustration.
The fact that I can't write an event to the NPM when I receive a particular type of trap or syslog, and then alert on it is majorly handicapping.
Many devices in my network don't have great polling capabilities, yet they trap furiously when something is wrong. So far, the most interesting thing I can do with traps or syslog is to blindly forward them along. I need to be able to create alerts with detailed instructions in them for escalation and other instructions for the people they are going to.
Item #2 is also high on the list. Having dependencies is something supporting in opensource monitoring systems like Nagios or Zenoss to name two.
Item #4 just makes sound sense, although my installation isn't developed enough to require it (yet).
Item #7 is something I've been wanting since the first month I had Orion installed. Mass editing of nodes, mass editing of users, mass editing of view limitations are all really important to me. I'm currently using a functional workaround for view limitations, based on Custom Properties.
Item #8 is critical. I have all kinds of interfaces I want to gather statistics on, but not bother alerting. Currently my only workaround is to ignore statistics gathering and leave them de-checked in the individual node properties, because I really don't need to know when a customer drops LAN ports on a IAD.
Item #11 is also big, but since I've ignored the map, it doesn't bother me at the moment.
Another one that's pretty big for me, would be the ability to have the Node Addition interface also allow me to put in custom properties based on whichever custom properties I have. I can't tell you how many times I've forgotten to set the custom properties only to find out my alerts (which are all transitioning to being based in part off of custom properties) don't work.
Peter