The NPM team is busy at work on a number of highly requested enhancements:
FIPS support – ensures product operability on a Windows OS (2003 & 2008) with the FIPS Group Policy Object (GPO) enabled, which restricts which cryptographic algorithms are allowed
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. We are working on a number of other smaller features in parallel. 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!
Chis, the way that I have worked around the issue of limited threshold controls is to add a number of custom properties that I use as 'Alert Package Designators'. These are organized in a tiered structure with system wide defauts at the bottom of the list and the most granular at the top (volume & interface specific). Then I build alert packages for the different types of alerting that I want to do and populate the appropriate custom property with the package codes (example: DISKMSSQL001 for one of my disk volume alerting packages used for MS SQL servers).
This seems to allow for a fair amount of flexibility to those managing servers while keeping things grouped up enough (and query-able) to be able to maintain things.
Also it would be really cool if you could have the ability to project future trends. The graphs could say (and notify in an alert) that a volume will run out of space in X number of days.
Also smarter email routing will be good. Currently we use email rules to forward email alerts to the appropriate people based on the content of the message. I would like this to be part of the product rather than having to use email rules. Possibly having the ability to have variables in the 'To' field of the email alert would be useful.
Thanks for the responses. I wanted to address each comment
Spiky - this is on our list of items to add to the product, but based on current priority did not make the cut for the next release
Jason - this item is on our list as well, but as indicated in the post, did not make the cut for the next release. Regarding your second question it is hard to answer that. Mainly because our priorities today can and does change over time based on feedback from ya'll in the community, internal and external factors. So what is high on my list today may move down the list based on these events. Hopefully that makes sense. The last thing I want to do is commit something until I know it is a sure thing which means we are working on it.
Chris - we do have the first item in the system for a future release. Regarding trending you can do some of that today with 9.5, if you edit a chart and set the period for sometime in the future for example, you will see a trend line out into that future time based on the historical data we have gathered. What is not there is alerting on that, which is something we have heard from other users as well. And finally regarding the email item, it is something I will log into the system, but have not heard a ton about from ya'll. So for those reading this, if this or any of these things are important to you, please chime in and tell us so we can shift priorities based on the feedback.
kupjones - are you seeing this with 9.5? I beleive in that case we'd pick one of the IP's and only use that. If this is not the case, please let us know.
Yes, putting variables in the "To" and "server" feilds of alerts would be realy nice to have.
Changed email server a few weeks ago and there where a lot of rules to change in...
Thanks for a good work!
If you are a current customer under active maintenance and are interested in helping us test out a beta of Connect Now and VMWare API support, please send me a PM via thwack. This is on a first come first serve basis, so we may not be able to have everyone participate. In your note to me, please include your SWID and which of the two features you are interested in helping us with.
Brandon, sorry I was not clear -- so I cobbled together a screen shot of NPM with what I *think* the Presentation should look like. Operationally, this is how I think it should work:
- SNMP will give you both the interface table (L2) and the IP table (L3).
- We are interested in both.
-- The L2 table is good as it allows me to alert on events that occur at Layer 2.
-- What is missing is a really good representation of L3. If I want to monitor a Layer 3 I must create a separate device for each IP addr -- and thus I end up with multiple devices, all with the exact same L2 interfaces. I should be able to discover a device via a seed IP, then "tell" Orion which L2/L3 combinations I am interested in. I attached the cobbled together "screenshot" of NPM where I show not only the monitored physical interfaces but also the IP addresses and the L2 interface that they are attached to. The L3 addresses should be selectable as to whether or not they are being monitored.
One big reason for having multiple L3's is if reachability is achieved through multiple L3 routes. Thus, I want to be notified when an L2 goes down but it is equally important for me to know that the *device* is still reachable via the alternative L3 interface.
I believe NPM 9.5 still has the default behavior of "picking" an IP address, unless I specifically discover an address.
Does this help?
I was really hoping to see the alert dependencies rework in this release, for help with alert suppression. Last I heard, there was other work to be done first structurally to allow this.
I know that ALL of your customers can benefit from this, not just a select few; I figured that would weight this differently.
Not sure if this has ever been brought up, but how about adding a Custom Module that would allow us to fill with whatever we want and name it what we want?
MODULES: IP Address Manager My Module <-- Name customizable
Within that module allow custom html, scripts or whatever. If someone wants to just bring in a whole website, then so be it. If someone wants to create a site with their own content, then so be it.
So you want to add your own tabs/label section like we use for modules?
The links in the nav bar not working?
Yes, I have few links to external sites like Thwack already in the Nav bar, but with currently 13 views/links in the nav bar, it is pretty busy and squished on smaller screens. It would be nice to add your own Tabs so to speak along the top and then have no menus or hide the nav bar all together so you could pull in your own Intranet or Internet sites.
Send me a PM BakerD, I have some ideas I want to run past you
Uh, I must be missing something, I don't see anyway to send a PM. Looks like I can contact you via email under your profile, is that what you meant?
It does and it is high on our list. As you can see from my list, all of these are high value items in which there are multiple threads on thwack about, we are working on chugging through them all as quickly as we can
Thank you for giving us some insight on what we can expect in the future.
What about allowing Orion NPM to differentiate between systems based on the SNMP port? I know I've seen a few posts where people are trying to monitor modules in chassis-based systems with a single management IP or (as in my case) using PAT to traverse a firewall when provisioning VPNs is not a solution. This functionality seems like it is a high priority for those users attempting to make it happen.
Also, is there a place that describes the upgrade cycles for NPM? If I have to say "the feature might be coming," we'll want to know how long it could take. For instance, if it doesn't make it in the next upgrade cycle, how long will I have to wait for the next cycle for a possible update?
Thanks for all of the information.
This is critical to us as well. We monitor a number of customer networks where we have very limited access to their resources i.e. a single IP address with PAT used to map each of the monitored devices SNMP ports.
A bump in priority of this feature would be greatly appreciated!
Brandon, something else to consider for features:
When performing a discovery of a network we will run into network devices that are multi-homed (MH) and in cases of fairly large networks these multi-homed devices will have multiple Layer3 paths. The issue we run into is that during the discovery each IP address, although discovered, ends up being presented as a separate device. So for any one device I will end up with N instances, N being determined by the number of pingable interfaces.
Granted, I can fix this by following best practices and enabling loopback then scanning the loopback network, but this only works for multi-homed devs that provide a loopback that is -- flexible (eg., Cisco).
Ideally, I should be able to discover an MH device and during that discover and MIB-walk Orion will figure out that I have multiple IP addrs -- which would show up in the node details. Once done I could then select the ip addr that I would like monitored ( like the loopback), and perhaps even designate alternative/secondary IPs for monitoring .
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 150,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process. Learn more today by joining now.