Skip to content

UniFi Miner guide in English

Grigory Prigodin edited this page Mar 5, 2021 · 16 revisions

Contents

Beware, Google Translate here!

  • Overview
  • System requirements
  • Installation and setting up
  • Command line options
  • Filters
  • Tool using
    • Examples of requests
  • Integration to monitoring system
    • Zabbix
  • Tips
    • UniFi Miner acceleration
    • Getting the data synchronized in time
  • Troubleshooting
    • Connection to the UniFi controller refused
    • Error SSL23_GET_SERVER_HELLO:unknown protocol caused
    • Problems that appear with PPerl using
    • Low-level discovering rule not running or new values into data items does not appear
    • Zabbix's data item going to "Not supported" state
    • Frequency of data revenues in Zabbix is disrupted, there are "gaps" in the charts, queue of Zabbix is grows
    • Incorrect work with multiple sites configuration

Overview

UniFi Miner - is a small tool written in Perl, which helps deliver to the monitoring system (Zabbix) operational data - metrics and settings obtained from the UniFi controller via API, provided by Ubiquiti. Zabbix's Low-level Discovery (LLD) protocol are supported. Also, there is highspeed client-server analog of UniFi Miner: UniFi Proxy

The practical result of the interaction of UniFi Miner and Zabbix is ​​a graph like shown below.

The number of clients served by the access points (UAP)

Zabbix: connected clients

Traffic on the wireless network

Zabbix: wireless traffic

System requirements

  • OS Linux;
  • UniFi controller v2, v3, v4, v5.

Just as Perl is a cross-platform programming language, the UniFi Miner, theoretically, it can be adapted to work on a variety of operating systems. However, the ability to run software on OS different from the development environment - Debian Linux, has not been investigated. The main test procedure maded on UniFi controller v5. An additional, but less careful (because not used in production) - on v3 & v4. The code for the v2 is written with the assumption that it is close to v3, with some exceptions. Such as, for example, no sites supporting.

Installation and setup up.

Installation of UniFi Miner is not so complex. To done with it, you must:

  1. Get the software from the site GitHub: git clone https://github.com/zbx-sadman/unifi_miner;
  2. Install necessary Perl modules. You can use Perl tools - cpan JSON JSON::XS LWP LWP::Protocol::https IO::Socket::SSL Data::Dumper Time::HiRes, or the package manager of your operating system - aptitude install libjson-perl libjson-xs-perl libwww-perl liblwp-protocol-https-perl libio-socket-ssl-perl libdata-dumper-simple-perl libtime-hires-perl;
  3. Make Perl-script executable: chmod 0755 unifi_miner/unifi_miner.pl

At this stage, UniFi Miner is ready to work, but it is worth spending a little more time and make some changes in the Perl-script to setting up for your operating system and the UniFi controller. Most of the parameters needed to obtain correct results, can be defined via command line options that will be described in detail below. However, some important settings can be maded only by editing of the source code. Be very careful when carrying out this operation - do not remove the quotation marks, commas and other characters that you may not seem very nice and unnecessary. If you understand what is written in the comments to code - do not hesitate to read them.

So, take advantage of the simplest text editor in your OS, so as not to make a PDF document or a HTML-page from the Perl-script.

Perhaps the only one mandatory thing that will need to be done - to make sure that the directory specified in the variable cachedir really exists. Without it, Miner can't work, as uses fast file cache instead of the slow HTTPS query to UniFi controller every time you will need to know anything about his condition. If your system is havent directory specified in this variable, you can specify any existing. It is necessary to take into account that it should be available for reading / writing with user credentials, which used to run UniFi Miner (for example, the zabbix user). To achieve maximum efficiency in the use of the cache, it must be placed on the RAM-disk. In this case, a instance of UniFi Miner, found outdated information (see -c option description), will very fast replace their with newly obtained, and if the OS is placed on the SSD drive - extend its lifetime. In Linux, you can find these partitions by keyword tmpfs in the output of df command. They can be /run/shm, /dev/shm and so on.

Also, you should pay attention to the variables cachemaxage (see -c option description), unifilocation (-l option), unifiuser и unifipass (-u и -p respectively), unifiversion (-v), and sitename (-s) if your controller have no more than one UniFi site. Setting up these script's variables will allow you to reduce the number of command-line options used for requests to the UniFi controller. This will give you focus on solving a specific problem, but not keyboard typing training.

As exist possible that for some OS installation the JSON::XS package can be not available, so, starting with v1.3.5, a JSON package is used, which allows you to specify the desired (available) backend.

Command Line Options

Almost any launch of UniFi Miner, you will use some command line options. Note that the values​of all options entered in lowercase. Reducing testing and case conversion function made Miner little faster - and it is at this point is very important. In the description of the options you will see references to the format JSON. Explaining this fact will be given in section "Tool using".

Thus, the format of the command line interface is:

unifi_miner.pl [-o object_type] [-i {id | mac} | -m mac] [-k key] [-a action] [-l unifi_location] [-s sitename] [-u unifi_username] [-p unifi_password] [-v unifi_controller_version] [-d debug_level] [-j stringify_method] [-n null_replacer] [-c cachemaxage_sec] where:

-o [ wlan ]

Type the explored object.

In most cases - its the value of JSON-key type, contained in data for object/device, connected to UniFi controller. That types currently supported:

  • site - UniFi site. Type actual for v3, v4, v5 controllers;
  • wlan - wireless network (configuration of it), considered as part of some site (for v3, v4, v5 controllers ) or not (v2);
  • uap - UniFi Access Point (wireless access point), considered as part of some site or not;
  • usw - UniFi Switch;
  • ugw - UniFi Security Gateway (UniFi router);
  • uph - UniFi Phone (UVP).
  • extension - registred VOIP-device information;
  • number - phone number that mapped to VOIP-device information;
  • alluser - the user, which listed in the controller's archive (ever connect through any supported by controller device);
  • user - the online user connected through any supported by controller device;
  • voucher - the voucher (see Controller's "Voucher Manager" feature);
  • dpi - information from the DPI tab that appeared in the v5 release;
  • sitedpi - information from the DPI tab in the modified API v5.6;
  • health - the current state of UniFi Controller module (see. Dashboard page on v4/v5);
  • sysinfo - an object, that contains certain information about the controller;
  • setting - object associated with the configuration repository (see tab Settings > Site );
  • network - defined on the controller network area (see Settings > Networks)
  • usergroup - user group (see Settings > User Groups);

Also, due to the fact that Miner version 1.1.0 and higher able to constructing LLD-JSON with custom JSON subtree, virtual objects types can be created by the user. These types are used to LLD-JSON form and their list can be added independently, by editing the perl script's source code. For example, that specially designed types can be used:

  • uap_vap_table - list of virtual access points of certain UAP;
  • usw_port_table - UniFi Switch port table.

Note that the object wlan almost always exists on the controller, allowing you to use the discovery procedure for debugging purposes.

-i []

Internal ID of the explored object.

As a rule - this value of JSON-key _id. It's generated by the controller itself and did not seem to correlate with any data of the connected device. The specific device ID contained in LLD-JSON output when discovery group operation will be performing. Also its can be found in the request process console output at a high level debugging (-d 3).

However, since version 1.1.0 Miner allows you to specify MAC-address of the UniFi network device with -i option. At the same time using of the -m option is not necessary, although it continues to be supported.

-m []

MAC-address of the UniFi network device.

The value of JSON-key mac. The option is valid only when used with the v4 controller and give acceleration for obtaining information about network device. In mac option using case, data search will be maded by the controller, but not slow Perl-script. I recommend the mandatory use this method of addressing with site, which contained a large number UniFi devices. When using the -m, -i option is not required.

Attention! In a future release of UniFi Miner support this parameter is discontinued. Instead, use -i.

-k []

Key of metrics or setting that you need to get.

Is the name of JSON-, composite or virtual key. Composite keys is structure, that describe path to JSON-key via JSON-subtree. So, for example, a composite key stat.tx_dropped, means that the requested metric associated with JSON-key tx_dropped, located in a nested JSON-object stat.

The composite key can also include a filter expression. This is necessary for addressing an elements of JSON-array, which haven't mnemonic names. For example, the filter may be used to obtain values from a table port_table, which contains the operational data of physical UniFi Switch (USW) switch. More information about filters can be found in the "Filters" section.

In addition, Perl-script supports the virtual key items_num. It is designed for a quick count of selected objects, for example - the number of devices of a certain type.

Available JSON-object keys may be seen with API, using the appropriate link (eg https://unifi:8443/api/s/default/stat/device) or analyze the cache file, or console output of discovery commands (see -a) at a high level debugging (-d 3).

The use of composite and other types of keys will be showed in the section "Examples of requests".

-a [ discovery ]

The group operation or action performed on the JSON-keys in the case that the list of objects is processed (for example - all UAP within the site). That actions currently supported::

  • discovery - to get a response in the JSON-format, which used Zabbix for low-level discovery (LLD);
  • get - to get the value of the metric which defined by the key (-k) contained in a single or a first suitable (filtered with some expression, for example) object.
  • count - to get the number of found JSON-keys (hence - JSON-objects) that correspond to the filter condition;
  • sum - calulation the amount of metrics belonging to different objects of the same type;
  • max - finding the maximum value among the results of selection;
  • min - finding the minimum value among the results of selection;
  • pcount - calulation the percent оf the selected by filter JSON-keys of their total number;
  • psum - calulation the percent of the sum оf the selected by filter JSON-keys of their total sum;
  • amean - calulation the arithmetic mean of the sum selected JSON-keys;
  • median - calulation the median value of the selected JSON-keys;
  • raw - return the fragment of the processed JSON tree, which selected by filter. The filter expression must be finished with a * virtual key.

There is no doubt that some group operations duplicates the functionality of the monitoring system, but there are situations in which the calculation on the UniFi Miner side preferably used. For example, delivery metrics values to Zabbix, generally not synchronized in a time. Metric num_sta (number of clients) from one UAP to the moment of obtaining the metric's value of the second or third UAP may vary quite significantly. Thus, it would be impossible to use any Zabbix's group operation within the same time period and to get the result, which reflecting reality. So, in my opinion, it makes no sense to deliver metric values to the monitoring system and keep it only to sum or count: for example, the authorized state of client, which connected to the access point, if you need to check the growth of unauthorized connections (pending users) only.

Due to the fact that certain metrics such as adopted, isolated, is_guest etc. are have Boolean nature, the result of count the number of objects (hence - JSON-keys) in a some state that reflected by the coincides metric value, will be equal to the result of sum of such metrics. In some cases, replacing count to the sum will decrease an runtime. For example, the calculation of the amount of metric vap_table.is_guest will be produced faster than counting metrics vap_table.[is_guest=1].essid by eliminating the stage of the filter matching.

-l [ https://127.0.0.1:8443 ]

Controller interface location.

Despite the fact that by using the -l option you can specify the location of the controller interface other than localhost, in my opinion more productive to use UniFi Miner on the same host, where is UniFi controller placed. The benefits of this will occur on systems that serve a significant number of devices or interrogated throught the public or other slow or highly loaded network. In this case taking big JSON-response from the controller within the same host will be much faster.

-s []

The name of the site, to which explored object or UniFi device is adopted.

Option actual for v3, v4, v5 controllers only. Since v1.1.0, if there is no name, Miner will make a request a list of all existing sites on the controller and consistently apply them to a given group operation. The result will be summarized.

Attention! Note the UniFi Controller v4 feature: site name that you see in the web-interface, is its description. Its real name, which is required to specify in this parameter, located in the url bar - https://unifi:8443/manage/s/the-sitename/dashboard. Thus, for the site 'Tokio Office' name, which should be used in UniFi Miner command line, may be, for example, 'zc6h0sgv'.

-u [ stat ]

Name of the account used to access the controller's API.

This account must already exist and activated on the UniFi controller at the time of run UniFi Miner. Ie its should be able to log in to https://unifi:8443.

Of course, you can use for access to the API username and password of admin account, created during the initial setup of the controller, but you need to bear in mind that user credentials used to access via SSH protocol to the physical UniFi devices and their publication may cause some trouble. Therefore, in the case of integration the UniFi Miner with monitoring system looks reasonable to use an another UniFi user account. Additional protection can give specifying the account name and password directly in the script through the variables unifiuser and unifipass - in this case they will not be transmitted through the network.

-p [ stat ]

The password of the account used to access the controller's API.

See notes to option -u

-v [ v5 ]

The controller version: v2, v3, v4., v5

For successful processing of the query Miner must use the correct methods to obtain data from the UniFi controller. This is achieved by specifying the right version of the controller with which to work. However, if you do not plan to use UniFi Miner with controllers of different versions, much easier to define the unifiversion variable in the Perl-script code.

-d [ 0 ]

Debug Level: 0..3.

In a process of any program using may occurs cases when programm does not start or gives incorrect results, but why it do - is unclear. If this happened with UniFi Miner, then determine the cause of strange behavior can help debug mode in which to console print a report of internal procedures progress and the values of important variables. A verbosity of a report is determined by the debug level: 0 - no, 3 - the most detailed. Maximal verbosity is also useful for those users who want to know what the objects and UniFi devices metric they can control.

-j [pretty]

JSON object's transormation method.

The result of some Miner's operations is a JSON object, which is converted to a text format before output. Starting with the release of v1.3.8, UniFi Miner supports the following methods:

  • inline - the text is send as single line with 65Kb's limit, which at the same time is the maximum size of the Zabbix's incoming text fragment (line), finished with the LF symbol (EOL, '\ n');
  • pretty is a formatted text with indents, alignment and consisting of more than one line. This allows you to bypass the restriction inherent in the inline method, and send to Zabbix data that exceeds 65k.

In earlier releases, only the inline method was actually used.

-n []

Substitute value JSON::null.

The values ​of some metrics may be take the null value (eg, ng_ast_txto of UAP object, which expected as numeric value). Or, the same occurs when filter's selecting result have not any value, but the lack of value on the Zabbix's graph will look incorrectly. However, the same value returns by the script if the given key is not present or point to nested object. And the result of query processing looks like a blank line.

In case of use Miner in conjunction with Zabbix, it causes a switching of "digital type" data items to the UNSUPPORTED state. If you are not satisfied with this behavior, as a workaround you can use the -n option and replace the null (empty string) to 0 or other convenient number. For example, when no data of environment's radio noise level was found, will be better to return the value -100.

But keep in mind that thoughtless use of this option will lead to disguise the real problems and obscure the UniFi Miner output.

-c [60]

Maximum age of cache data.

Miner uses caching JSON-data, which received from the UniFi controller. It allowing to speed up of user requests processing in a several times. Also it makes available a certain synchronization of key values which transmitted to Zabbix-server (the problem is described into -a option notes). This feature allows you to get right complex graphics and consistent reports.

Each started instance of the Miner checks the "age" of cached data and replace outdated JSON by slow HTTPS query to controller's API. The parameter value eqial 0 disables all procedures related to caching, and data are collected directly from the controller. In my opinion - the "age" shall not be less than the minimum time of updating data in the controller's web-interface and the minimum time of the data elements survey maked by the monitoring system.

This parameter can be set directly in the Perl-script code in cachemaxage variable.

Filters

During the query with the Miner, you may need to use aggregate functions to some metrics of the specified objects. For example - to the UAPs, operating only in the NG mode or to users, with the signal level less than 20dBm.

Filters should be used to select a number of the objects. The filter is a part of the composite key. Its must be enclosed in square brackets. The filter can contain one or more expressions. Several expressions should be joined by the logical operator sign:

  • & (AND operation);
  • | (OR оperation, used with Miner version 1.1.0 or later).

Attention! Different logical operators can not be used simultaneous in one filter expression.

The filter expression must be written as "JSON-keyconditionvalue." The condition is defined by characters:

  • = - equality;
  • <> - inequality (applies to version 1.1.0 and up);
  • <,>, <=,> = - Less, greater, less or equal, greater or equal (applies to version 1.3.0 and higher).
  • =~, !~ - found or not found with Regular Expression (applies to version 1.3.6 and higher). Filter value will be used in m/value/s operator;

Attention! Whitespaces on the left and the right of condition sign to be regarded as part of the JSON-key and value, respectively.

So, as an expression of the filter may contain whitespace, colon and other non-letter characters, I recommend to quote a composite key containing the filter.

Examples of filters using can be seen in the section "Tool using".

Tool using

It is important to know that the UniFi controller uses JSON for data exchange with external programs. This will help to understand the principle of making queries with UniFi Miner.

The basic store structure for information about the devices connected to the UniFi controller is an array of JSON objects. It containing the keys reflecting any metrics or setting of devices (e.g. access point, switch, etc.) or internal entity (e.g., website, wireless network, etc). Addressing specific object is carried by JSON key _id.

At your request UniFi Miner will apply a batch operation or action to all metric values associated with a key specified by the -k. The metric values are taken from the list of objects with type specified via -o (or the default type) within the specified site (-s). In that case, if you specify the ID or MAC (-i or -m), the action is performed on one object. When performing discovery group operations -k option is ignored.

The result of this scenario is the value of metric or group operations or Zabbix's LLD-JSON or an empty string (null). Null is returned if specified key is incorrect or an associated JSON key in the object is not exist (for example, physical device is switched off). However, some of existing and valid JSON keys can have a null value (see option -n).

Examples of using UniFi Miner

Getting LLD-response for a default object type within all sites

./unifi_miner.pl

Getting LLD-response for most actual list of "access point" objects within 'zc6h0sgv' site (see Note to the -s option). The data is taken from the controller directly (without the use of cache).

./unifi_miner.pl -a discovery -o uap -s zc6h0sgv -c 0

The same, but when working with the controller v3, located at https://127.0.0.2:8443

./unifi_miner.pl -a discovery -o uap -s zc6h0sgv -v v3 -l https://127.0.0.2:8443 -c 0 

Getting the number of UAP, registered on the controller

./unifi_miner.pl -a sum -o uap -k items_num

Getting the number of active UAP on all controller's sites

./unifi_miner.pl -a count -o uap -k "[state=1].state"

The percentage of active UAP of the total on all of the controller's sites

./unifi_miner.pl -a pcount -o uap -k "[state=1].state"

Getting the number of UAP on 'zc6h0sgv' site, that have adopted state is true

./unifi_miner.pl -a sum -o uap -s zc6h0sgv -k adopted

Getting the number of clients served at the moment all the UAP. Note that the second method will work faster, but can only be used on controllers v3, v4

./unifi_miner.pl -a sum -o uap  -s zc6h0sgv -k num_sta
./unifi_miner.pl -a get -o site -s zc6h0sgv -k num_sta

Getting the number of clients served at the moment a certain UAP. Note that when you specify the name of the site, Miner process the request quickly.

./unifi_miner.pl -a get -o uap -k guest-num_sta -i 5523fe519932508ffaf3b404 
./unifi_miner.pl -a get -o uap -s zc6h0sgv -k guest-num_sta -i 5523fe519932508ffaf3b404 

Getting key tx_dropped value , located in a table (nested objects) stat of given UAP

./unifi_miner.pl -a get -o uap -s zc6h0sgv -k stat.tx_dropped -i 5523fe519932508ffaf3b404

Getting the number of guest networks served by a particular UAP

./unifi_miner.pl -a sum -o uap -s zc6h0sgv -k vap_table.is_guest -i 5523fe519932508ffaf3b404 

Write to file report.txt debug data, that contain key names and internal identifiers of "access points" objects

./unifi_miner.pl -o uap -d 3 > report.txt

Getting the number of clients currently connected to the UAP from the MAC 00:27:22:d8:33:23 with considering that cache is valid for 1 hour (3600 sec). Note that in the second method, MAC-address specified in the parameter -i. This is used since Miner 1.1.0

./unifi_miner.pl -a get -o uap -s zc6h0sgv -k guest-num_sta -m 00:27:22:d8:33:23 -с 3600
./unifi_miner.pl -a get -o uap -s zc6h0sgv -k guest-num_sta -i 00:27:22:d8:33:23 -с 3600

LLD-JSON to UniFi switch ports. Note that -k define the JSON-key that refer to JSON-subtree over which the LLD-response build. The virtual object usw_port_table applies only to creating macros that used in LLD-JSON.

./unifi_miner.pl -a discovery -o usw_port_table -s zc6h0sgv -k port_table -i 5523fd299932508fda3fe987

Getting the number of UniFi Switch ports that stay in the 'POE enable' condition. The group operation sum applied due to the fact that the use of count lead to the calculation of the number of keys "up", regardless of their value, and consequently - the state of the ports.

./unifi_miner.pl -a sum -o usw -s zc6h0sgv -k "port_table.[poe_enable=1].up" -i 5523fd299932508fda3fe987 

Getting value of port_poe key, referring to the port #13 of the switch with the specified ID

./unifi_miner.pl -a get -o usw -s zc6h0sgv -k "port_table.[port_idx=13].poe_power" -i 5523fd299932508fda3fe987 

Getting value of port_poe key, referring to the switch port, having alias "Port 1"

./unifi_miner.pl -a sum -o usw -s zc6h0sgv -k "port_table.[poe_enable=1&speed=1000].up" -i 5523fd299932508fda3fe987

Getting the value jumbo key that related to a switch port, having alias "Port 1"

./unifi_miner.pl -a get -o usw -s zc6h0sgv -k "port_table.[name=Port 1].jumbo" -i 5571c343e4b0c5f69fea8d2c 

Get the number of bytes received collectively virtual access points operating in a guest mode with encryption other than WEP and owned by physical access points "UAP01" and "UAP08"

./unifi_miner.pl -a sum -o uap -s zc6h0sgv -k "[name=UAP01|name=UAP08]vap_table.[is_guest=1&is_wep<>1].rx_bytes"

The percentage of active users connected using any other devices other than Apple's devices

./unifi_miner.pl -a pcount -o user -s zc6h0sgv -k "[oui<>Apple].oui"

Percentage of ever users connect using Apple's or Samsung's devices

./unifi_miner.pl -a pcount -o alluser -s zc6h0sgv -k "[oui=Apple|oui=SamsungE]"

The average noise level for active clients registered on the access point with the specified MAC-address

./unifi_miner.pl -a amean -o user -s zc6h0sgv -k "[ap_mac=00:27:22:d8:33:23].noise"

Number of clients registred, зарегистрированных on access points with the MAC-addresses contained "16:5c" и "73:13" substrings

./unifi_miner.pl -a count -o uap -s default -k "[mac=~16:5c|mac=~73:13].num_sta"

UniFI Controller software Version

./unifi_miner.pl -a get -o sysinfo -k version

WLAN module status displayed on the dashboard page of UniFi controller's web interface

./unifi_miner.pl -a get -o health -s zc6h0sgv -k "[subsystem=wlan].status"

JSON, which will be fetched from UniFi controller when site object is processed

./unifi_miner.pl -a raw -o site -s default -k "*"

LLD-JSON for VOIP-devices registered on the controller

./unifi_miner.pl -a discovery -o extension -s zc6h0sgv

Phone number for VOIP-device associated with the specified by ID extension

./unifi_miner.pl -a get -o number -s zc6h0sgv -k "[extension_id=5698e7779932af54c74bad18].number"

Integration to monitoring system

Zabbix

Zabbix uses several ways to interact with the user programs:

I see the easiest and safest way of interaction with the expansion functionality of Zabbix agent that installed on the server, where UniFi controller hosted. In this case, you must include into a Zabbix-agent's configuration file or write to separate file and connecting it with Inclide= directive the following:

# (1) To run UniFi Miner in compatibility mode for the UniFi Proxy template using
UserParameter=unifi.proxy[*],/usr/local/bin/zabbix/unifi_miner.pl -a "$1" -o "$2" -s "$3" -k "$4" -i "$5" -n "$6" -c "$7"

Afterwards restart the Zabbix agent and test the UniFi Miner work: zabbix_agentd -t unifi.proxy[discovery,wlan].

The macros used in LLD ({#MACRO}) can be found in output of discovery group operations with desired object type.

Tips

UniFi Miner acceleration

If your host or template in Zabbix contains a large number of data items, calling a Perl-script execution, then most likely, you will face the problem of the high CPU load. The load increase in occurs every time when Zabbix's data item updated, because external program is started. Thus, the more often updates of data items calling more simultaneously executed UniFi Miner instances on your server. And the biggest will be its CPU/RAM load. Unfortunately, at the moment, there is no simple possibility to radically improve the perfomance, but there are a number of tricks, which allows to reduce the run time of a Perl script (Note: use UniFi Proxy instead Miner, if high speed is need).

  1. The simplest way is reducing the number of obtained metrics and/or increase the time of polling. In addition: use a simple keys to avoid the filters using in the complex keys and unwarranted group operations (for example, the value of num_sta key within the site object will be obtained faster than the sum of the values of num_sta keys within uap objects) or identify UniFi devices by MAC address. When Miner used with Zabbix, you must to specify the type of data item as a Zabbix agent (active) - in this case the results will be sent to the server as bulk.

  2. More difficult is to disable unused modules in Perl scripts, which reduce the initialization time. These can be considered: 'Data::Dumper' module (and u you will not be able to use the debugging, using the option -d), 'strict' and 'warnings' pragma. Just disable its with '#' symbol in the beginning unifi_miner.pl.

  3. The most effective way is using Persistent Perl. Its can be installed from CPAN: cpan PPerl or from the system repository: aptitude install pperl. Then you should replace perl to pperl into shebang at the first line of a Perl script. However, this method is really difficult - most likely you will encounter problems using this utility. How to solve some of them described in "Troubleshooting" section.

Getting the data synchronized in time

Using the tool which get only one value per run, for the situation analysis, that requiring a comparison of several parameters related to the risk of obtaining information for different periods of time, which could lead to misleading conclusions.

Miner avoids this situation due received data is cached. To use this feature, you can apply consistent requests:

#!/bin/bash
# Query that update UniFi devices cache  - relevance of cache 1 sec
NA_TX_DROPPED = `./unifi_miner.pl -a get -o uap -s zc6h0sgv -k stat.na-tx_dropped -i 5523fe519932508ffaf3b404 -с 1`
# Queries that uses updated cache - relevance of cache 60 seconds
NG_TX_DROPPED = `./unifi_miner.pl -a get -o uap -s zc6h0sgv -k stat.ng-tx_dropped -i 5523fe519932508ffaf3b404 -с 60`
NA_NUM_STA = `./unifi_miner.pl -a get -o uap -s zc6h0sgv -k na-num_sta -i 5523fe519932508ffaf3b404 -с 60`
NG_NUM_STA = `./unifi_miner.pl -a get -o uap -s zc6h0sgv -k ng-num_sta -i 5523fe519932508ffaf3b404 -с 60`
CCQ = `./unifi_miner.pl -a amean -o uap -s zc6h0sgv -k vap_table.ccq -i 5523fe519932508ffaf3b404 -с 60`
# Pushing values in the database
rrdtool update stat_uap_01.rrd N:${NA_TX_DROPPED}:${NG_TX_DROPPED}:${NA_NUM_STA}:${NG_NUM_STA}:${CCQ}

Of course, you should be sure that all requests are met for 60 seconds.

Troubleshooting

Connection to the UniFi controller refused

Symptom: connection to the UniFi controller refused with a valid user credentials when Miner try to access the controller's API.

Possible reason: incorrect version of the controller.

Fix: check of -v option value or the contents of the variable $globalConfig->{'unifiversion'} (you can use -d 2 to view it).

Error SSL23_GET_SERVER_HELLO:unknown protocol caused

Symptom: connection to the UniFi controller with error code 500. Error string 'SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol' on debug level 3 (-d 3) is showed

Possible reason: LWP module is not supported option 'SSL_verify_mode' and use SSLv2/SSLv3 protocol to connection UniFi controller, when TLSv1 expected.

Fix: uncomment following lines in the beginning of the UniFi Miner code:

#use IO::Socket::SSL;
#IO::Socket::SSL::set_default_context(new IO::Socket::SSL::SSL_Context(SSL_version => 'TLSv12', SSL_verify_mode => Net::SSLeay::VERIFY_NONE()));

Problems that appear with PPerl using

Symptom: after replacing perl shebang to pperl in the UniFi Miner code, script does not run correctly, in the console output found an errors like 'Cannot open lock file'.

Possible reason (1): In home directory of user, which used to run UniFi Miner (under Zabbix-agent or otherways) .pperl directory is missing or rights not allow write to it. In earlier versions of PPerl there was the option -T, which was used to specify the working files location, but in modern (0.25) directory path hardcoded and cannot be changed.

Fix (1): create .pperl directory into the user's home directory and/or set correct access rights. The path to the home directory can be found with the command cat /etc/passwd | grep zabbix (if zabbix user's account is used).

Possible reason (2): no free space on the partition where PPerl worki files must be placed.

Fix (2): free some space.

Low-level discovering rule not running or new values into data items does not appear

Symptom: a Miner script fails with the error like '...unlink error' or 'Presumably no rights to unlink', which is showed in the Zabbix's web interface. The LLD rule fails with error "Value should be a JSON object".

Possible reason: there was a single or multiple script runs under the account other (e.g. root), that of a limited user (e.g. zabbix) account. Causing the cache files were created and owned by non-regular user and cannot be deleted with limited user.

Fix: Change group/owner of the cache files or delete them from cachedir. If u delete its, they will be recreated when UniFi Miner will be started. To speed up the fix process you can delete all the cache files.

Zabbix's data item going to "Not supported" state

Symptom: complex keys, which contains the filter causes data item going to "Not supported" state.

Possible reason: the Zabbix agent cannot process the key containing the characters'[', '&', ']' and etc.

Fix: use the UnsafeUserParameters=1 directive in the Zabbix-agent configuration file.

Frequency of data revenues in Zabbix is disrupted, there are "gaps" in the charts, queue of Zabbix is grows

Symptom: lines on Zabbix's graphs have "gaps" or look like a rare reference points. On the "Latest data" page can be seen that the frequency of receipt of some Data Item's values does not match with the expected. Zabbix Queue shown delays in obtaining data from Zabbix-agent.

Possible reason: Agent skips launch of checks that doing sequentially in the active mode (type of poller - Zabbix agent (active)) due of their large number, or slow host performance.

Fix: Reduce the number of Data Items to be checked with the active mode or switch them to passive mode (type of poller - Zabbix agent) with simultaneous increasing the number of Zabbix server's poller (StartPollers). You can also upgrade to UniFi Proxy.

Incorrect work with multiple sites configuration

Symptom: Result of Miner's work do not contain data from one, several, or all sites, except for 'default'.

Possible cause: Miner uses a specially created account to access the controller. This account does not have access to sites whose data are not included in the result of work.

Fix: create the account with the same password in all sites of the controller or use an account that is created by default.