![](https://secure.gravatar.com/avatar/a1d329397629b36a7837bc22eb10d3d4.jpg?s=120&d=mm&r=g)
Yes that doesnt sounds like its going to be easy to get as it just happens once in a while. I suppose I can run a debug discovery and see if the issue happens, might take a few goes I guess
Thoughts?
Would the command be ./discovery.php -h 235 -dd
Ill see what I can grab if anything, otherwise I think you are right and that you will need to debug all discoveries and save to a log perhaps?
Rich
On 24 Jun 2019, at 20:42, Adam Armstrong via observium observium@observium.org wrote:
A debugged discovery run where the thresholds are set to NULL would be useful.
Difficult to get, though. Perhaps we need the ability to debug all discovery runs.
adam.
On 2019-05-21 14:50:48, Richard Savage via observium observium@observium.org wrote:
Hi All
I have found a bit of a potential bug with the sensor data output which doesnt seem to be related to any particular version of Observium or device being polled (useful I know!)
However it looks like some sensors limits are being updated to NULL regularly, which is throwing alerts and scaring staff ;-) Noticed on both 19.3.9774 and 19.4.9840.
e.g from a device event log:
2019-05-10 12:36:07 Ethernet1/49 Lane 2 Transceiver Temperature https://stats.goodwood.com/device/device=170/tab=health/metric=temperature/id=55094/ Sensor updated (limits): limit_high -> "0", limit_high_warn -> "NULL", limit_low -> "0", limit_low_warn -> "NULL"
2019-05-10 13:08:08 Ethernet1/49 Lane 2 Transceiver Transmit Power https://stats.goodwood.com/device/device=170/tab=health/metric=dbm/id=55096/ Dbm Ethernet1/49 Lane 2 Transceiver Transmit Power above threshold: 0.03 dBm (> 0 dBm)
A re-discovery of the affected device will fix the issue, until the next time it happens.
Happy to provide any further debug required.
Thanks
Richard
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium