With NPM 11.0 just barely in our rear-view mirror, it is our great pleasure to announce NPM 11.5 has reached RC2 status. NPM 11.5 RC2 delivers on a ton of feature requests driven by the Thwack community, in addition to...
One look at the new "Manage Alerts" grid tells you this isn't just a port of the old Advanced Alert Manager to the web:
We could spend an entire post on the goodness of the new Alerting Engine- so in fact we did. If you would like to dive deeper into some of the new functionality, check out this: What We're Working On: New Alerting Engine
NPM can now display where your wireless clients are on your heatmaps. When client location is enabled, NPM periodically polls the wireless infrastructure for client signal information. NPM then uses triangulation and other techniques to determine where that client is on your floor plan and displays it right in your NPM web console. As time goes by, NPM periodically polls your wireless infrastructure, recalculates location, and updates the client locations on your maps.
Speaking of wireless, 11.5 RC also includes pollers for Aerohive, Aruba Instant AP, and Juniper/Trapeze. Check out the Manage Pollers page to apply them.
NPM can now report and proactively alert on the number of days before a problem occurs. This applies to CPU / Memory / Volume / Interface
Based on SNMP Location field, the Worldwide Maps resource will automatically place and aggregate nodes. We included new "zoom-level" aggregation logic as well.
Hardware sensors can be independently managed, thresholds set, or forced up. Cisco hardware MIBs are now selectable on a per-device basis
QoE now automatically discovers applications on defined sensors. This streamlines deployment and setup process greatly.
NPM 11.5 RC2 is available for customers under active maintenance via their Customer Portal
We'd love to hear you feedback on the new features- please let us know what you think below!
Was just playing around a bit on my dev server and knew I could do something quicker as a query in the Database Manager and happened to noticed that the "Nodes" table is now gone?
It seems to be replaced by a NodesOLD (which doesn't appear to be updating) and a NodesData table, which at a quick glance looks pretty much the same as the Nodes table.
Is this going to affect any reporting (ie: SQL queries) or SWQL stuff we might have done that depended on the Nodes table?
Will this stay this way in the release, or is it just the RC that is doing this?
Just curious of the ramifications of this for when the release finally comes out and we want to transition our old server rather than our dev server...
Another issue I'm having: When sending traps from NPM, defined variables used in the template are showed as deprecated in the trap sent (not in NPM directly ) and the link given is an Oops page.
.18.104.22.168.4.1.11307.10.7[OCTET STRING]="PropertyName" variable is deprecated in New Alerting; please see http://www.SolarWinds.com/documentation/helpLoader.aspx?lang=en&topic=OrionCoreAG-DefunctAlertMacros....22.214.171.124.4.1.11307.10.8[OCTET STRING]="PropertyValue" variable is deprecated in New Alerting; please see http://www.SolarWinds.com/documentation/helpLoader.aspx?lang=en&topic=OrionCoreAG-DefunctAlertMacros...
Another ticket was opened:
#757538 - Need documentation for variables that can be used for alerts in NPM11.5
The agent was clueless, and did not seem to understand the issue... after about an hour, I just required the documentation... It took me a while to explain to him what was a trap template and what this is used for... *sigh*
In which document was the information? We, too, need to update the SNMP trap template to forward alarms to another system.
I haven't seen an announcement for RC3, but it's available on the downloads page.
I'm very excited about the features. World Map using SNMP location is making everything a lot easier to set up some cool maps.
Looks like there are still a number of issues with alerts either not triggering or (more often for me) not recovering correctly, but hopefully those will get sorted out soon.
No biggie, only cosmetic, but during the upgrade to 11.5 RC3, The installer realized my license key was not updated. (Note the version in the title bar, I'm currently running v11.0.1)
I also had a few alerts that were not imported.
In worldmap edit mode, clicking here: brings me to this:
That being said, Kudos for improvements to the Worldmap section
There was an issue in RC1&2 with externally linked logos being broken on upgrade. Should not have occurred on RC3. Readding / linking the logo should fix it. If not, if you can send me the support ticket #, we can chase it down.
I've created a few tickets :
#754601 - Logo on login page does not appear
#754602 - Worldmap node status
#754607 - Disabled alert still firing...
#754610 - Wrong status description
I'll open a case later on today if times permit... it's only on the login page anyway.
I also realized that alert rules that were disabled prior to upgrade were reenabled (Traffic on Multicast groups) .
One of my favorite less talked about features is volume thresholds. Yay! No more custom properties. However, custom properties are still more useful because, unless I'm missing something, there isn't an easy way to bulk edit the Volume Thresholds. For example, lets say I have a large group of servers that I want to set the C:\ Drive thresholds to 95% and the D:\ Drive Thresholds to 97%. Right now I can't go into Manage Nodes and choose to edit only Volumes like I can with Interfaces, so that means I have to expand each server that I want to edit, select the C:\ drive, then click edit properties. Then rinse and repeat for the D:\ drive. Not a big deal if I just have a few, but lets say I have 20 or 30 or 100 or even 500 volumes, that's a lot of clicking and hunting and pecking just to select all of my volumes. We really need a way to search, sort, and Group by so that we can bulk edit these like we can with interfaces.
(While you are at it, please expand the Manage Nodes screens capabilities to let us Sort, filter AND Group By all at the same time. You can only Sort and search OR sort and Group by, you can't do both. Plus, there really isn't any filtering at all. The Manage Nodes screen should have the same sorting, filtering, grouping, and searching abilities that the Manage Custom Properties screen does. The Manage Nodes screen also needs to allow us to Group by Node OR Interface properties when editing Interfaces instead of only letting us Group by Node properties (and Node OR Volumes if you add a Volume drop down box as I've suggested). As long as I'm on a tangent, we need to be able to Group by Node properties in the Custom Property editor when editing Interfaces, Volumes, or Applications. Its funny that when editing Interfaces in Manage Nodes I can ONLY group by Node properties and when editing Interfaces in Manage Custom Properties I can ONLY Group by Interface properties. We need BOTH ).
Seriously though, amazing features in this release, and minor gripes aside, I'm really blown away by all the new stuff you guys packed in. If only one or two of the new features would have been added I would have been happy. Keep up the good work, and make the Manage Nodes screen and Manage Custom Properties screen just as amazing as all of your new stuff!!
This should really come with a 'do not upgrade' directive if you use any other major integration such as Web Performance Monitor. It's alerts dissappear until its upgraded to a beta release.
Ditto, I can't find anything on how to make this work. I thought maybe the existing nodes I had manually added were interfering, so I removed them, no luck . Tried turning the setting off and on in the Web Console settings, nothing. Added new nodes, nothing.
So, what is the magic to get this stuff working? Does the SNMP location field need to be in a specific format, and if so, what is that format? Are there variations allowed?
Personally I'd like to be able to use my SNMP location field for multiple things, such as grouping nodes in a node tree. That means if I had to specify the SNMP location field as something like "1 main street, albuquerque, nm" instead of "NM, Albuquerque, 1 Main Street", that everything would be scattered about based on the street address number, rather than grouped by State or City...
Any documentation on this? This has been out for some time with no real comment on how to use it. I'm really hoping that you don't have to use lat/long, that would be a royal pain!!
We call out to a MapQuest web service to perform the lookup. As long as MapQuest understands the format, we are good. "Paris" may resolve to either "Paris, TX" or "Paris, France" so we just need to be specific enough to avoid ambiguity.
So, how do we diagnose this? I have it set to auto-place items on the map, but new items I've recently added aren't getting added. I've double checked the address format against mapquest and it should work. Should they get added to the map immediately? After a period of time? Trying to figure the ins and outs of how this feature works.
Also, as I said before, how about allowing us to "transform" the address format before sending it to Mapquest. I like to have node-tree's display things by location, which works if you have a list something like:
NM, Albuquerque - 1 main street
NM, Albuquerque - 909 Montgomery Ave
NM, Las Cruces - 505 2nd street
TX, Dallas - 293 Fourth Ave
But if you have to have it in a format that Mapquest supports, you would end up with a list that looks more like:
1 main street, Albuquerque, NM
293 Fourth Ave, Dallas, TX
505 2nd Street, Las Cruces, NM
909 Montgomery Ave, Albuquerque, NM
I would think some sort of regular expression-like ability to transform the SNMP-location in the format I want it to a format that works for Mapquest would be a great feature!!
I guess that would bring up another question, if Lat/Long tables are populated as it find the nodes (I'm guessing), I'm hoping it keeps track of if there is a change in the SNMP-location field and does another lookup?
Of course ideally I would like to see in the future, if this is how its done, the ability to override and enter the lat/long coordinate directly in a way that so if you change the SNMP-location field it doesn't change these coordinates also. Maybe a "lock-coordinates" checkbox along-side the manually editable lat/long field in the "Edit Nodes" page?
I did notice there was no comment on the suggestion for address transformations too, should that be put in as a feature request? Should the suggestion wait for the actual release of the software with the feature in it to be submitted?
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.