Optic dbm alert checker and interface status
![](https://secure.gravatar.com/avatar/539f31d140f2ab5a5f0eb26f4cddcabc.jpg?s=120&d=mm&r=g)
Hi,
Is there a way to only trigger the dbm sensor alert if the corresponding interface is up? I thought I could get away with just testing if the sensor values fall outside the sensor limits. But when ports are down (even when unplugged) I get spiky readings which will trigger the alert. So it would be nice to check if the interface is up as part of the alert check.
I suspect this isn't possible as things are right now. It seems sensors have no relationship to another entity (e.g a port on a router). Ideally, I would like to say something like this:
Port Checker Condition
ifOperStatus eq up sensors.dbm.juniper-dom-rx.sensor_value < @sensors.dbm.juniper-dom-rx.sensor_limit_low
Port Checker Entity Match
ifAdminStatus eq up dbm in sensor_classes juniper-dom-rx in sensor_types
So only ports that are admin up and have an associated sensor type of the appropriate type would get added to the checker. This will ensure the condition will be able to refer to the appropriate sensor.
This would imply there is some mapping/relationship between sensors and other entities. This is probably very MIB specific and very platform specific. But it would make for a very useful checker.
![](https://secure.gravatar.com/avatar/33de7b2e356bcdefce13825418e71ab6.jpg?s=120&d=mm&r=g)
Hi all,
We are suffering the same problem on a lot of 10G interfaces that we have down. We think that this is a junos bug. Sometimes, checking diagnostics optics on the cli, you can see the RX optical power as "-Inf", instead of a dbm value. When this happens, the snmp value returned on jnxDomCurrentRxLaserPower is 0, instead of the real dbm value (typically between -20dbm and -40dbm). This situation results on triggering the alert when the real value is returned again.
There is a possible workaround to avoid this. In the same MIB, if you check the value of jnxDomCurrentAlarms and domRxLaserPowerLowAlarm is active, then you can ignore a 0 in jnxDomCurrentRxLaserPower, and replace it by a logical value like -40dbm, or jnxDomCurrentRxLaserPowerLowAlarmThreshold - 0.01.
Best regards
Javier Valero IP Services Coordinator IslaLink / OranLink
De: observium [mailto:observium-bounces@observium.org] En nombre de Milton Ngan Enviado el: viernes, 3 de noviembre de 2017 5:34 Para: Observium Network Observation System observium@observium.org Asunto: [Observium] Optic dbm alert checker and interface status
Hi,
Is there a way to only trigger the dbm sensor alert if the corresponding interface is up? I thought I could get away with just testing if the sensor values fall outside the sensor limits. But when ports are down (even when unplugged) I get spiky readings which will trigger the alert. So it would be nice to check if the interface is up as part of the alert check.
I suspect this isn't possible as things are right now. It seems sensors have no relationship to another entity (e.g a port on a router). Ideally, I would like to say something like this:
Port Checker Condition
ifOperStatus eq up sensors.dbm.juniper-dom-rx.sensor_value < @sensors.dbm.juniper-dom-rx.sensor_limit_low
Port Checker Entity Match
ifAdminStatus eq up dbm in sensor_classes juniper-dom-rx in sensor_types
So only ports that are admin up and have an associated sensor type of the appropriate type would get added to the checker. This will ensure the condition will be able to refer to the appropriate sensor.
This would imply there is some mapping/relationship between sensors and other entities. This is probably very MIB specific and very platform specific. But it would make for a very useful checker.
![](https://secure.gravatar.com/avatar/539f31d140f2ab5a5f0eb26f4cddcabc.jpg?s=120&d=mm&r=g)
We have a port that is down, but is reporting between -12dBm and -11dBm on the RX. But yes, we could just monitor the alarm status, but this still doesn't let us correlate this with the actual port status. If the port is down (either operationally or administratively), we don't care about the light level since a higher level check will alert if the port is down.
________________________________ From: observium [observium-bounces@observium.org] on behalf of Javier Valero [javier.valero@islalink.es] Sent: Friday, November 03, 2017 6:18 AM To: Observium Subject: Re: [Observium] Optic dbm alert checker and interface status
Hi all,
We are suffering the same problem on a lot of 10G interfaces that we have down. We think that this is a junos bug. Sometimes, checking diagnostics optics on the cli, you can see the RX optical power as “-Inf”, instead of a dbm value. When this happens, the snmp value returned on jnxDomCurrentRxLaserPower is 0, instead of the real dbm value (typically between -20dbm and -40dbm). This situation results on triggering the alert when the real value is returned again.
There is a possible workaround to avoid this. In the same MIB, if you check the value of jnxDomCurrentAlarms and domRxLaserPowerLowAlarm is active, then you can ignore a 0 in jnxDomCurrentRxLaserPower, and replace it by a logical value like -40dbm, or jnxDomCurrentRxLaserPowerLowAlarmThreshold – 0.01.
Best regards
Javier Valero IP Services Coordinator IslaLink / OranLink
De: observium [mailto:observium-bounces@observium.org] En nombre de Milton Ngan Enviado el: viernes, 3 de noviembre de 2017 5:34 Para: Observium Network Observation System observium@observium.org Asunto: [Observium] Optic dbm alert checker and interface status
Hi,
Is there a way to only trigger the dbm sensor alert if the corresponding interface is up? I thought I could get away with just testing if the sensor values fall outside the sensor limits. But when ports are down (even when unplugged) I get spiky readings which will trigger the alert. So it would be nice to check if the interface is up as part of the alert check.
I suspect this isn't possible as things are right now. It seems sensors have no relationship to another entity (e.g a port on a router). Ideally, I would like to say something like this:
Port Checker Condition
ifOperStatus eq up sensors.dbm.juniper-dom-rx.sensor_value < @sensors.dbm.juniper-dom-rx.sensor_limit_low
Port Checker Entity Match
ifAdminStatus eq up dbm in sensor_classes juniper-dom-rx in sensor_types
So only ports that are admin up and have an associated sensor type of the appropriate type would get added to the checker. This will ensure the condition will be able to refer to the appropriate sensor.
This would imply there is some mapping/relationship between sensors and other entities. This is probably very MIB specific and very platform specific. But it would make for a very useful checker.
participants (2)
-
Javier Valero
-
Milton Ngan