![](https://secure.gravatar.com/avatar/a1d329397629b36a7837bc22eb10d3d4.jpg?s=120&d=mm&r=g)
From what I can see the sensor limits keep being updated on each poll. Surely they should just be a static value and not need to be changed??
Thanks
Richard
On 29/05/2019 20:22, Richard Savage via observium wrote:
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 mailto: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 _______________________________________________ observium mailing list observium@observium.org <mailto:observium@observium.org> 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
observium mailing list observium@observium.org mailto:observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium