I am having an issue where a disk that I am disabling the sensor on is re-enabling itself. This seems to be happening daily.
has anyone else experienced this?
do you have some kind of a unmanage schedule in place which runs on a daily basis ?
is there a way to check the timestamp till what time it has been disabled on the DB (for that particular disk/sensor) you are talking about?
This happens here aswell, but only with certain sensors.
Those 3 for example, I have tried disabling them several times now, but after a couple of minutes they are "re-enabled".
It happens for the same sensor on different nodes.
The nodes have not been un/remanaged and we do not have an unmanage scheduele.
What type of device and what sensor type are you attempting to disable the monitoring of? Also, how is the node polled?
The ones i am having issues with are HP Blade disks. We are polling through Vcenter.
fcpsolaradmin Can you please open a case with support? This issue is being tracked internally under FB408488 and the parent for the case bravo opened. Please reference this number and this thread when opening your case to ensure it's routed appropriately.
Done, Thanks.Case #772287
Some sad news today:
Email form tech:
"
The ability to disable sensors or custom thresholds works with the SNMP/WMI polling. However, it does not work for the VMware polling as the pipeline for the VCenter polling is different as far as how the data is processed.
hat being said, they stated that a work around for you might be to switch the polling method of your VMware from VCenter to direct polling. They stated that that MIGHT help (but they cannot be 100% sure due to environmental variables).
he steps to do this are as follows: 1. go to detail page of v-center which hosts the nodes with hardware health where you want to control the sensors. 2. Click on Virtualization Settings button on Virtualization Assets resource (usually first on the page) 3. Within the tree structure of V-center select your ESX node. 4. Notice in the toolbar above the tree structure there is button "Poll Through" 5. Switch it from "Poll through vCenter" to "Poll ESX Server directly". 6. You might need to set up credentials for the ESX server (Click in the toolbar on Assign ESX Credentials) 7. Wait until Polling status become "Polling" for that ESX Node. 8. Go to ESX detail page by clicking on the node in the tree structure. You will be navigated to node detail page of the ESX server. 9. On the page you might want to click on "Poll Now" located on "Management" resource or wait couple of minutes for regular poll. Fresh data will appear a moment after that. 10. Thats it. You might expect different output than from vCenter and it is possible that some information previsouly available won't be available anymore. In case customer is not satisfied with output, he should turn back the polling back from "Direct" to "Pass through the vCenter".
However, this doesn explain why @John Light has the same issues on his cisco devices.
is it possible to remove all ESX disks from monitoring?
I remember I had an issue when I was using the direct method for polling.
The only method for which to exclude hardware sensors from SAM's Hardware Health Monitoring is through the method discussed in this thread. I would concur that the CIM method is more likely to work than the VMware API through the vCenter simply because it's more closely associated with the host, but I can't say definitively that it will resolve your issue without first trying it.
Ok thanks,changing it to poll through ESX directly works, Is there a downside to using this method to polling the hosts?
None. In fact you're likely to gather richer more complete hardware health information using CIM (direct) then using the VMware API (vCenter).
I am now having this same issue for the same sensors, but so far with only a single device and a much lower frequency.
Did you ever find a solution?
What type of device is this occurring on?
Cisco ASR 1002. The specific sensors are for a SPA-1X10GE-L-V2 with XFP-10G-MM-SR optics.
Perhaps you are looking too far up the stack for the solution to your issue. SolarWinds Hardware monitoring is driven by the Rediscovery process. As you disable sensors, they go silent, until the Node is rediscovered...
You should try poking a value into your snmpd.conf file on the device. This file is similar in function to the hosts file on a windows box in that it is read at system initiation and will trump the actual value in the snmp stack for the oid in question.
Using this method will not impact other nodes rediscovery or hardware monitoring, allows you to tune the spurious status collection and keeps the solution very focused.
I find it is also good practice to annotate this action in the Notes field on the Node in question, in case hardware changes.
While this is not ideal, it is workable and produces the desired results.
