Ill try and get a screenshot next time it happens of the sensors, as it shows that the sensor value is still there in terms of the actual voltage, but the threshold limit isn’t there at all and just shows 0 or the infinity symbol from memory
Richard
On 29 May 2019, at 20:16, Richard Savage via observium observium@observium.org wrote:
Its a 9006 running 5.3.4 with 2 x A9K-RSP440-SE with some A9K-40GE-L and A9K-16T/8-B line cards in
Thanks
Richard
On 29 May 2019, at 19:24, Klimek, Denis <DKlimek@Stadtwerke-Norderstedt.de mailto:DKlimek@Stadtwerke-Norderstedt.de> wrote:
Hi Richard,
which ASR9K model do you have and which IOS-XR version are you running?
Regards, Denis
Von: observium <observium-bounces@observium.org mailto:observium-bounces@observium.org> Im Auftrag von Richard Savage via observium Gesendet: Mittwoch, 29. Mai 2019 17:16 An: Observium <observium@observium.org mailto:observium@observium.org> Cc: Richard Savage <richard@zananet.com mailto:richard@zananet.com>; Adam Armstrong <adama@memetic.org mailto:adama@memetic.org> Betreff: Re: [Observium] Sensor limits creating false alerts
It seems to have become more of an issue on the ASR9K's in the v19.5.9916 that we are running.
Its happening more frequently now and is causing lots of false positives. Is it possible once the threshold are polled, then just set them in stone? I cant see any reason why the thresholds need to change? For example a Voltage should always be between 2 values and those threshold values should change? From what I can see its the actual limits that disappear and not the values.
Thanks
Richard
On 29/05/2019 14:55, Adam Armstrong via observium wrote: Ahh ok.
I assume this is related to unstable polling. These are all from CISCO-ENTITY-SENSOR-MIB, which is pretty heavy, and Nexus has iffy SNMP.
I'm not sure how we can work around this. It's hard to know if something is not there forever, or just for now, and storing state on that stuff is pretty messy.
Is this is a more recent thing, or has it always happened?
Disabling faster polling modes on a device like this would probably make it unpollable.
adam. On 2019-05-29 14:52:14, Richard Savage via observium observium@observium.org mailto:observium@observium.org wrote:
Hi Adam
This is mainly seen on Cisco ASR9K's but we have also seen this on Cisco Nexus switches as well.
No this affects Voltage, Temperature, and dbm levels on SFP's
Happy to provide debug if required.
Those are a few examples. It seems to be a mass load of sensors at any one time.
Thanks
Richard
On 29/05/2019 14:46, Adam Armstrong via observium wrote: Hi Richard,
I assume this is because sometimes the OIDs from which the limits come aren't polled sometimes?
Is this only a single (os) device? Only a single type of sensor, or multiple? (you should now be able to see the mib/oid on the sensor page)
adam. On 2019-05-28 10:24:00, Richard Savage via observium observium@observium.org mailto:observium@observium.org wrote:
Hi All
just wonder if anyone has any ideas on this? (Mike / Adam)
Thanks
Richard
On 21/05/2019 14:50, Richard Savage via observium 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 mailto:observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org mailto:observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org mailto:observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium