Twitter

by acls us

Monitoring UBNT UniFi WiFi with Zabbix and Node Red

UBNT

Zabbix

Node Red

   

Having implemented Zabbix monitoring for Tanaza managed WiFi devices (here), the next step was to monitor Ubiquiti UniFi APs that were managed via a UniFi Controller. Ubiquiti have been more and more of a closed system over the last couple of years as they introduce more ways to lock in their customers by introducing management systems and hardware that prevent their hardware being used by more Open Systems. A particular example is the UniFi AP v2 which has been locked down to prevent the installation of third party Firmware, although they are very coy about this. So OpenWRT with a Zabbix Agent cannot be installed. This means that the only Zabbix monitoring available is to PING the devices.

 

The approach taken to getting UniFi Controller Managed WiFi APs into the same Zabbix monitoring environment as other network devices was to make use of the UniFi Controller API. This API is not at all well documented and may disappear if Ubiquiti decide the lock down their systems even further. The API exposed a number of end points that return JSON encoded data. These are used by a timer driven Node Red flow that queries the UniFi Controller every 120 seconds via a Logon, a query for the sites names and queries for all the devices/clients per site. The flow then totals up the number of connected clients per UniFi AP and passes the device's status, site name and connected clients to Zabbix via the Zabbix Sender.

PS - There is a Node Red Node available for communicating directly with the UniFi Controller API "node-red-contrib-unifi" but I have not personally tried this out yet.

 

 

 

Monitoring Tanaza WiFi with Zabbix and Node Red

Tanaza

 

Zabbix

 

Node Red

   

Tanaza is one of a number of Managed WiFi Systems available today. If you exclude the TP-Link and Ubiquiti type approaches to WiFi Management, which are tightly bound to their own hardware, almost without exception the cross platform WiFi Management Systems are based on customised builds of OpenWRT. This provides a WiFi Management System that allows a wide range of hardware from a wide range of manufacturers to be managed by the same system. This is a good thing. The only bad thing is that you cannot directly monitor what's going on inside the Managed Access Points via a Zabbix Agent as you can normally with OpenWRT.

 

The approach taken to getting Tanaza Managed WiFi APs into the same Zabbix monitoring environment as other network devices was to make use of the Tanaza API. This allows access to a snapshot of the current status of your Tanaza Managed Networks. The Tanaza API Status query end point returns JSON encoded data with the status of every Managed WiFi AP connected to your Tanaza account. This is used by a timer driven Node Red flow that queries Tanaza every 120 seconds and converts the JSON data into a JavaScript object representation, as this is more convenient to work with. The flow then does a sense check that the Tanaza query worked ok, HTTP status 200 set and the Tanaza's errorCode is zero. A Node Red Function is then used to step through the Tanaza data extracting the status information for each AP in turn. Then another Node Red Function is used to take certain data from the AP status and build zabbix_sender parameters for each host item that is to be sent to Zabbix. Finally the zabbix_sender is invoked to send the data to the Zabbix Server. The data being monitored for each AP is its online/offline status, the number of connected WiFi clients (totaled across all SSIDs on the AP) and the name of the Tanaza Network the AP is used in.

 

 

 

PowerTXT alerts via Twilio and Node Red into Zabbix (Part 2)

Zabbix

Node RedTwilio

PowerTXT

   

The project (see here) has moved on from a proof of concept to live now. The original Node.Red flow has been updated to delete the original Twilio message after having passed it on to Zabbix. A new flow has been added to accept requests from Zabbix to send PowerTXT commands via Twilio and a small flow has been created to allow Zabbix to check that Node.Red is up and running ok.

 

 

 

The original inbound SMS Node.Red flow now has the extra steps (at the bottom) which check if the message was sent to Zabbix ok and if so builds the command to send via the Twilio API to delete the original message from Twilio.

Node.Red

A new Node.Red flow has been added to accept requests from Zabbix and then send PowerTXT commands. In Zabbix, the requests are created by a Zabbix script that uses wget to send the request, which includes the Zabbix hostname (in the for sms_44nnnnnnnnn where nnnnnnnnn is the mobile number without the leading zero) and a command to perform (register, on, off or query). The flow verifies the request has originated from localhost and checks that the hostname and command parameters have been supplied. The symbolic command names are then translated into PowerTXT commands (e.g. #07# for query) and passed into a step that builds the request for Twilio. The request is sent and the reply from Twilio examined to see if the message was sent or not, the result of this test is used to pass a status back to the Zabbix script that originally requested the message be sent.

Node.Red

Finally a short Node.Red flow was added to that Zabbix can send a web request that is replied to with "OK" so Zabbix can check that Node.Red is running ok. This flow also checked that request originated from localhost.

Node.Red