4 Replies Latest reply on Jan 18, 2010 2:26 PM by ray.rechtin

    Critical Features for NPM

    pserwe

      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

        • Re: Critical Features for NPM
          seigniory

          1, 2, 3, 5 - To be honest, I could take those or leave them, and the general lack of these features industry-wide means that most will have some kind of workaround in place already.

          4, 6 - Absolutely agree 100%, but should be true for EVERY poller, not just custom ones.

          7 - A trillion times YES.  NPM is the only product I run that DOESN'T offer external authentication of some sort.

          • Re: Critical Features for NPM
            bshopp

            Peter,

            Thanks for the post.  We have talked about many of these items across various threads, but it is good to centralize them and get other people to weigh in.

            #1 - we for sure have this on the list with a bunch of other feedback we have gotten on the UnDP

            #2 - I would be interested to hear feedback from the community on this.  We don't hear this a ton to be honest

            #3 - understood and agree

            #4 - agree we have this on our list to add

            #5 & 6 - so if you have seen the in case you wonder what we are working on post, we are doing some Syslog and Trap work in the next version.

            #7 - agree, we have this on our list to add

            We have a ton of items on our list based on feedback from the community and we are working on getting through them based on the priority we gauge from the community as quickly as possible.  Please keep the feedback coming and if you feel strongly about a feature or item, please chime in.

            • Re: Critical Features for NPM
              byrona

              As far as these requests are concerned, #3 is very important to us as well, #7 is Critical to us.

              As far as #5 and #6 are concerned, I had the opportunity to see the Alpha of the next release and there are a lot of improvements being made here.