There are a number of things, that after using the product for around 2 years, I now need seriously enough to pursue.
Switching platforms really isn't my favorite idea of what to do for the next few months, but the I need the functionality.
1) Custom poller table correlation: I need to be able to create a custom poller that pulls a table, and then pulls NN other tables and can correlate the data based off a key value found in the first one. There are quite a few custom SNMP implementations that need this sort of functionality.
2) View limitations that are more complex than the standard ones, so if I pull a load of tables for a device, I can point customers at them and have them only see the data meant for them. I don't want customer XX seeing polled values for customer YY, so if I'm graphing 30 customers with universal pollers on one device, I can have that customer see only the ones for them. One possible way to do this would be with custom views for the device for each customer - difficult to manage at best.
3) API for node, custom property, user account, view, and even possibly alert provisioning: I need to be able to provision all this stuff with an API, I want to be able to write scripts on a *nix management station and populate the values for all these entities. This is important. Manually managing thousands of nodes, thousands of customers, thousands of views, etc., simply isn't reasonable to do manually.
4) Multiple custom pollers on one graph: This issue, I would think, has been beaten into the ground. There's no horse left, just a faint stain in the dirt. For those devices that I can poll single values (get, get next) I need to be able to look at them without scrolling for 5 minutes.
5) Trap handling: Trap handling right now pretty much sucks. I need to be able to take traps, pull the values, and send alerts based on actually parsing the trap into human. I can't tell you how many devices I have that only really trap or syslog.
6) Syslog handling: Provide a way to integrate Kiwi into the main NPM product, and I'm probably set. I'd say good money says you guys are working on that already, but I need confirmation and a roadmap. Right now, syslog handling is just about as good as trap handling. I need the same things for traps, like, parse the messages, let me re-write the alerts into something meaningful for less technical humans, and deliver them.
7) Centralized authentication via an external source (with a high preference on LDAP, since just about everything else can either speak LDAP, or whatever it speaks to can speak LDAP). I have a host of systems already that can authenticate off LDAP, we know the connectors exist for pretty much every platform imaginable. This is well-traveled territory. Putting permissions into LDAP via a custom ldif would be the icing on the cake. If done properly, this would remove the need for an API for user creation/removal/modification, because it would all be done in LDAP and NPM would merely check against it.
I do not know what the primary demographic is of SW's customer base, but it would seem that it's not telecom, 5 and 6 are particularly poignant for telecom, as are 1,2,3,4, and 7 is useful for almost any enterprise. AD, for instance has an LDAP connector and anyone using AD for more than 50 people would benefit from the ability to be able to provision users for NPM from it.
Peter
