![]() |
![]() |
Subject: | Zenoss 4.2.5 Zenup 732 - Production State problem |
Author: | Pheripheral Pheripheral |
Posted: | 2018-05-09 12:30 |
A change in production state does not take effect in regards to monitoring until a daemon restart?
I've recently noticed some funny behaviour regarding the production states and how they affect monitoring of devices after moving to Zenoss 4.2.5 Zenup SUP 732
Previously, on Zenoss 425 SUP 671 if a device is set to decommissioned (i.e. -1, or any production state value less than its zProdStateThreshold value – which defaults to 300 for devices) it would no longer monitor the device via ping or by snmp and no further events would be raised until the production state was set back to something above the zProdStateThreshold.
However, I've noticed on SUP732 that this is no longer the case and setting the production state lower than the zProdStateThreshold does not prevent monitoring or events being raised.
With further experiments I discovered that once prod state is lower than the threshold, restarting the zenping will stop ping monitoring and restarting the zenperfsnmp daemons will stop snmp monitoring.
This behaviour is also similar once re-raising the production state whilst monitoring is off. Until the ping and snmp daemons are restarted monitoring for each protocol does not begin again…
Is this a bug that has crept in during the 732 update? – I noticed that 732 has added a whole set of things around production state under zenutils and introduced a ProdStateManager.
Has anyone else noticed this behaviour or are they able to recreate it to confirm my findings?
And any ideas of how to rectify it so that reducing the production state below the zProdStateThreshold once again stops monitoring as it is supposed to?
Subject: | RE: Zenoss 4.2.5 Zenup 732 - Production State problem |
Author: | Jane Curry |
Posted: | 2018-05-16 10:18 |
Subject: | RE: Zenoss 4.2.5 Zenup 732 - Production State problem |
Author: | Pheripheral Pheripheral |
Posted: | 2018-05-17 11:54 |
Subject: | RE: Zenoss 4.2.5 Zenup 732 - Production State problem |
Author: | Jane Curry |
Posted: | 2018-05-18 04:07 |
Subject: | RE: Zenoss 4.2.5 Zenup 732 - Production State problem |
Author: | Pheripheral Pheripheral |
Posted: | 2018-05-21 06:45 |
A change in production state does not take effect in regards to monitoring until a daemon restart?
I've recently noticed some funny behaviour regarding the production states and how they affect monitoring of devices after moving to Zenoss 4.2.5 Zenup SUP 732
Previously, on Zenoss 425 SUP 671 if a device is set to decommissioned (i.e. -1, or any production state value less than its zProdStateThreshold value – which defaults to 300 for devices) it would no longer monitor the device via ping or by snmp and no further events would be raised until the production state was set back to something above the zProdStateThreshold.
However, I've noticed on SUP732 that this is no longer the case and setting the production state lower than the zProdStateThreshold does not prevent monitoring or events being raised.
With further experiments I discovered that once prod state is lower than the threshold, restarting the zenping will stop ping monitoring and restarting the zenperfsnmp daemons will stop snmp monitoring.
This behaviour is also similar once re-raising the production state whilst monitoring is off. Until the ping and snmp daemons are restarted monitoring for each protocol does not begin again…
Is this a bug that has crept in during the 732 update? – I noticed that 732 has added a whole set of things around production state under zenutils and introduced a ProdStateManager.
Has anyone else noticed this behaviour or are they able to recreate it to confirm my findings?
And any ideas of how to rectify it so that reducing the production state below the zProdStateThreshold once again stops monitoring as it is supposed to?
Subject: | RE: Zenoss 4.2.5 Zenup 732 - Production State problem |
Author: | Jane Curry |
Posted: | 2018-05-22 03:55 |
Subject: | RE: Zenoss 4.2.5 Zenup 732 - Production State problem |
Author: | Pheripheral Pheripheral |
Posted: | 2018-05-22 06:48 |
Subject: | RE: Zenoss 4.2.5 Zenup 732 - Production State problem |
Author: | John Boyle |
Posted: | 2018-05-22 08:50 |
Subject: | RE: Zenoss 4.2.5 Zenup 732 - Production State problem |
Author: | Jane Curry |
Posted: | 2018-05-23 04:29 |
Subject: | RE: Zenoss 4.2.5 Zenup 732 - Production State problem |
Author: | Thomas Luther |
Posted: | 2018-05-31 02:40 |
Subject: | RE: Zenoss 4.2.5 Zenup 732 - Production State problem |
Author: | Willy Hidayat |
Posted: | 2018-06-05 01:14 |
Subject: | RE: Zenoss 4.2.5 Zenup 732 - Production State problem |
Author: | Jane Curry |
Posted: | 2018-06-06 05:48 |
Subject: | RE: Zenoss 4.2.5 Zenup 732 - Production State problem |
Author: | Jay Stanley |
Posted: | 2018-07-05 07:12 |
Subject: | RE: Zenoss 4.2.5 Zenup 732 - Production State problem |
Author: | Pheripheral Pheripheral |
Posted: | 2018-07-05 12:42 |
Yes, i'd be very interested in seeing the patch!
I did some quick playing around with this adding an extra line or two to push the changes in my custom bit of code i was using to toggle between 2 production state via one custom button press, and i think it seems to work once i added the line device._p_changed = True which seems to be what pushes it to the collectors. This may be the wrong way to do it though, and ti certianly won't fix the normal prod state change functionality.
prodState = device.productionState
if prodState == self.PRODSTATE1:
Subject: | RE: Zenoss 4.2.5 Zenup 732 - Production State problem |
Author: | Jay Stanley |
Posted: | 2018-07-05 13:15 |
Attachments:
ZEN-30167.patch.txtSubject: | RE: Zenoss 4.2.5 Zenup 732 - Production State problem |
Author: | Thomas Luther |
Posted: | 2018-07-06 04:52 |
Subject: | RE: Zenoss 4.2.5 Zenup 732 - Production State problem |
Author: | Jane Curry |
Posted: | 2018-07-06 10:56 |
< |
Previous Zenoss 4.2.5 job_catalog corrupted and POSKeyError |
Next Close events at change to decommision status |
> |