Don't alert on mikrotik wifi sensors

validate output:

==========================================================
Component | Version
--------- | -------
LibreNMS  | a1fffa4e8f49fb2dcb60f478a8666ebcffe1230e
DB Schema | 198
PHP       | 7.0.18-0ubuntu0.16.04.1
MySQL     | 10.0.29-MariaDB-0ubuntu0.16.04.1
RRDTool   | 1.5.5
SNMP      | NET-SNMP 5.7.3
==========================================================

I’m trying alter the default sensors over/under limit alert rules to ignore wlan interfaces on RouterOS.

The reason is that every so often they report either a 0 or a -90. This triggers the alert.

I’ve tried adding this to the alert: %sensors.sensor_descr !~ "^.*?\bwlan\d\b.*?\bSignal\b.*?$" &&
But it still triggers.

Any tips?
I thought about using sensors.sensor_type but I don’t know what type it would report as or how to check.

Do you mean wireless sensors? wireless_sensors

Yea, so I could use: %sensors.sensor_type != wireless_sensors &&?

wireless_sensors is a different table and therefore most likely a different rule you want.

Can you provide some more info on all of this?

Sorry, I’ll try.

Currently, we are using the general sensor under/over alerts that come with the installation.
These are fine in general.

However, they trigger if a Mikrotik wlan transmit power goes above or below the thresholds.
The alert is triggering on this:

#1: sensor_id => 1134; sensor_oid => .1.3.6.1.4.1.14988.1.1.1.2.1.3.120.108.28.207.140.33.12; sensor_descr => wlan1 Signal

This is happening because, sometimes, the router will report this value as 0 or -90. I don’t know why. But I also don’t really care, so I don’t want this alert to trigger if it is a RouterOS wifi sensor that is under/over threshold.

So you can either exclude routeros from the rule directly && %devices.os != "routeros" or create a group called No RouterOS and use that single item in the entity and map the alert rule to that new group

Hmm, I’ve tried a few things and it’s not working.

I’m not entirely sure the sensor I’m talking about is showed correctly.

It’s showing up under Health > Signal.

I expect this is designed for WIFI p-t-p links? Because I’m not sure how this metric is being arrived at for normal AP <> Station comms.

Is it showing in the correct place on LibreNMS?

The alert you showed above is the normal sensors rule. Why don’t you show some screenshots of what you are seeing and what you have done.

Sorry.
Here is the alert I don’t want/need:

It seems to be this data in Device > Health that is causing the alert:

For some reason, the Routeros devices I’m using will report this as 0 from time to time, triggering a pointless alert. It’s just the WIFI AP.

This is the alert rule:

%sensors.sensor_current > %sensors.sensor_limit && %sensors.sensor_alert = "1" && %sensors.sensor_oid != ".1.3.6.1.4.1.14988.1.1.1.2.1.3.120.108.28.207.140.33.12"

I tried to add the != logic to stop it alerting on this OID, but it seems that each device has a slightly different one, probably based on the interfaces on it.

Ok so that is just sensors, your original attempt at a rule is most likely just not matching on the regex.

To use your latest example just change it to be && %sensors.sensor_oid !~ ".1.3.6.1.4.1.14988.1.1.1.2.1.3.120.108.28.207.140.33.@"

I expect the differences you see in oids is that the index (last octet) changes. This will match any sensors of that type.

1 Like

Ah, I understand it now!
.1.3.6.1.4.1.14988.1.1.1.2.1.3 is a table.
It’s basically a table of all the wireless clients connected to a specific WLAN interface. The all the other octets are referencing a specific value for a specific row on the table.
So the above is the perceived TX/RX value of a single client device.

So to avoid alerting on it I need what you suggested @laf, but I can ignore anything after the .3. && %sensors.sensor_oid !~ ".1.3.6.1.4.1.14988.1.1.1.2.1.3.@"

I’m not sure that this is a useful value as it is right now. That graph basically shows a single client’s RX/TX info, but I’m not sure how it chooses which client, or even if it use data from the same client each time?
If we’re going to use this info, it needs to be presented in a table as intended.

1 Like

Thank you both for solving this for me. After enabling 802.11ac on my Mikrotik hAP it’s been alerting me for weeks now about poor signal and these alerts are spamming my every move on my Slack notifier.

Much happier now, thanks to you and @laf