cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post
Level 17

Mount point capacity monitoring stopped

Jump to solution

Just opened a support case,1343324, as I had found after the upgrade to NPM 12.2 and SAM 6.4 our mount point drives on a servers are no longer polling capacity.   I learned this morning this is a recently discovered bug and I shouldn't upgrade my production system if I can help it.  The problem is the system is already upgraded.   This was not listed in the known issues on the release notes.  I understand development is working on a fix, however, just a bit of feedback here, it would be nice as these are discovered that release notes in the customer portal are updated to list out things like this.  It may be that in most environments mount points may not be a critical drive, however, in our environment, our SQL servers utilize mount points for their data and log drives.  This leaves us somewhat exposed as we now can no longer be pro-active on these drives in regards to capacity.   We will have little to know warning if these drives fill up.  Had this been in the release notes, I would have held off upgrading until a fix was released.  

1 Solution

That is correct. Core 2017.3 HotFix 2 has been released which addressed this issue. It's available for download now through your Customer Portal.

pastedImage_0.png

View solution in original post

28 Replies

Does anyone have a list of what this hotfix fixes doesnt have a link in the customer portal to show whats in it?

0 Kudos

stevenstadel​ posted a link in an earlier reply that has what's in the fix.  I'll post it again

Orion Platform 2017.3 Hotfix 2 - SolarWinds Worldwide, LLC. Help and Support

missed that thanks

0 Kudos
Level 13

Looks like Platform 2017.3 HotFix 2 addresses this issue. I have to wait for a change window for implementation. If anyone else is able to complete the install before I can (5 days) let me know. If not I'll update the thread after install.

Orion Platform 2017.3 Hotfix 2 - SolarWinds Worldwide, LLC. Help and Support

I can confirm that this fixed the issue for my company!

0 Kudos

That is correct. Core 2017.3 HotFix 2 has been released which addressed this issue. It's available for download now through your Customer Portal.

pastedImage_0.png

View solution in original post

I can confirm.  I just installed this on my dev deployment and I am seeing mount point metrics again for capacity

Just installed on my production system.

Looks to work on my primary poller. My additional polling engine still not working for some reason.

Any of you got an APE who can either confirm on otherwise on this behavior?

0 Kudos

Did you download the latest Scalability Engines Installer from the Orion web interface and upgrade your Additional Polling Engines with this hotfix?

Actually used the installer from the Orion webconsole, since I had issues with the scalability installer - suggested by Solarwinds. Installed the hotfixes according installed updates.

WIll test the newest scalability installer - downloading and installing now.

Thanks

0 Kudos

We had issues with the scalability installer for our remote pollers, it kept timing out. I am curious if it will only copy the necessary hotfix and we won't have that problem this time.

0 Kudos

If the Scalability Engines Installer times out and clicking the 'Retry' button doesn't successfully resume the process after several attempts, then please follow the steps outlined in the KB article below. Note this issue is something we're actively working to resolve.

Failed to download or run the Scalability Engine installer from the main server - SolarWinds Worldwi...

0 Kudos

We had to go a bit farther then this KB when we had our issue, as just coping that CoreInstaller MSI was not enough to mitigate the timeout issue. We ended up copying the entire \subinstallers\ folder each time the installer timed out to a different temp directory, renaming the [currenttimestamp] folder to match when we would run the installer again, then copy it back to the %temp%\SWOrionSetup[currenttimestamp]\subinstallers\ directory before starting the installer again. Doing this three times was enough to get all the files copied over. We also noted that we were able to put the folder with a matching [currenttimestamp] to the %temp%\SWOrionSetup[currenttimestamp]\subinstallers\ directory prior to restarting the installer was best, as long as the timestamp minutes matched the current time. This method was easier then the step 5 where you need to immediately copy the folder over before the installer tries copying the files across.

0 Kudos

I'll install in on my dev deployment now and let you know

0 Kudos

This is fabulous news!  I am going to try and get permission to install tonight.

0 Kudos

I will try to install either today or tomorrow, and can let you know the results.

0 Kudos
Level 8

My company is having the same issue. 

I opened up Case # 1325147 on 12 Oct 2017.  Same issue.  We have been using this script as a workaround https://thwack.solarwinds.com/docs/DOC-174800

We also now have a script that looks for volumes that are not monitored and alerts on that.

Yeah - I am forced to currently use a seperate temporary NPM 12.1 installation to monitor the affected systems with mount points.

Must say I am incredibly disappointed in the time it is taking Solarwinds to fix a core issue like this. Cannot understand how it can possibly take long over a month to find a fix - with no time estimates or feedback on progress 😕 Disappointing.

Thanks for the heads up.  I just finished creating SAM components to monitor these via WQL and Windows Performance counters, however, it's definitely not ideal.  

Level 9

Same issue for us - been waiting over 30 days now for a fix 😕 Hoping it will be released soon. Server admins are not too happy.