Skip to content

LUNA PLATFORM v.5.17.0#

Changes#

  • Functionality for gathering statistics on completed requests was added. The statistics received will enable the analysis of LP usage to further improve the system. The following data is gathered:

    • the number of requests for LP resources, for example, 'POST: "handlers/handler_id/events"'.
    • the total number of estimations of the same type (for example, "estimate_liveness").
    • the number of successful requests and requests that failed with an error.

    Statistics are maintained for each error code for each resource for each service. Statistics are sorted by month.

    Statistics gathering works only when monitoring is enabled and InfluxDB of version 2.0.8 and later is installed.

    Monitoring is now enabled in services by default. Sending the above data to monitoring is enabled by default. The information is impersonal and contains only quantitative data.

    To get statistics, send a request to the "/luna_sys_info" resource of the Admin service or go to the "help" tab in the Admin service GUI and click "Get LUNA PLATFORM system info". The necessary information is contained in the "stats" section.

    Response example:

    { "stats": { "estimators_stats": [ { "count": 1, "month": "2021-09", "name": "body_descriptor_extractor_usages" } ], "routes_stats": [ { "service": "luna-api", "route": "GET:/version", "month": "2021-09", "errors": [ { "count": 1, "error_code": "12012" } ], "request_stats": [ { "count": 1, "status_code": "200" } ] } [...] ] }

    Statistics are gathered in InfluxDB based on data from the "luna_monitoring" bucket and stored in the "luna_monitoring_aggregated" bucket. The buckets are created in InfluxDB. Do not delete data from this bucket, otherwise, it will be impossible to get statistics.

    Tasks for gathering statistics can be found in the InfluxDB GUI on the "Tasks" tab.

    Statistics are gathered once a day, so they are not displayed immediately after the LP is launched. You can manually start the performing of tasks on the "Tasks" tab in the InfluxDB GUI.

    To enable statistics gathering, run the python influx2_cli.py create_usage_task --luna-config http://127.0.0.1:5070/1 command after launching the Admin service. The relevant information was added to the installation manual. The command automatically creates the necessary package "luna_monitoring_aggregated". If this command is not performed, the response "/luna_sys_info" will not display statistics.

    If necessary, you can disable statistics gathering by deleting or disabling the corresponding tasks on the "Tasks" tab in the InfluxDB GUI. See "Requests and estimations statistics gathering" in "LP_Administrator_Manual".

  • Support for InfluxDB version 1 was discontinued. The parameters for this version were removed from the configuration files. Now InfluxDB 2 is used to monitor LP operation (starting from version 2.0.8).

    If you previously used InfluxDB 1, you can migrate to a new version. A description of the migration is given on the official InfluxDB website:

    https://docs.influxdata.com/influxdb/v2.0/upgrade/v1-to-v2/docker/

  • Filtering by Liveness states (spoof, real, unknown) was added to the "/sdk" resource.

  • Changes were made to licensing.

    For Liveness V2, the ability to license the number of completed transactions was added. Now, when licensing Liveness V2, you can choose between an unlimited license and a license with a limited number of transactions.

    Each use of Liveness in requests reduces the transaction count. It is impossible to use the Liveness score in requests after the transaction limit is exhausted. Requests that do not use Liveness and requests where the Liveness estimation is disabled are not affected by the exhaustion of the limit. They continue to work as usual.

    The HASP utility was updated to version 8.23. When upgrading to a new LP build, you need to remove the old HASP utility and install a new one. The Licenses service will not start if the utility of previous versions is used.

    When using Liveness V2 with transactions, you will need to update the license when switching to a new build, because previously issued licenses do not support this feature.

    Information about the current license parameters is displayed in the response to the GET request to the "/license" resource of the Licenses service, in the response to the request to the "/luna_sys_info" resource of the Admin service and in the GUI of the Admin service on the "help" tab.

    See "Information about license" in "LP_Administrator_Manual" for details.

  • The Licenses service no longer depends on other LP services other than Configurator (when getting settings from it) and can be run independently of them. But LP services, such as Faces, now depend on Licenses. In this regard, the order of launching services in the installation documentation was changed.

    Services now write license data to the monitoring database themselves:

    • The Faces service writes data about created faces with attached descriptors to the monitoring database in the "license_faces_limit_rate" field.
    • The Handlers service writes data on the number of available Liveness V2 transactions to the monitoring database in the "liveness_balance" field.

    A warning about the exhaustion of the number of available transactions is sent to the monitoring and logs of the service when the remaining 2000 transactions of Liveness V2 are reached (this threshold is set in the system).

    • The Licenses service writes data about the expiration date of the license to the monitoring database in the "license_period_rest" field. This behavior was used in previous builds as well.

    See sections "Licenses service" and "Information about license" in "LP_Administrator_Manual" for details.

Fixed errors#

  • The request to get faces with attributes in the Faces service was expedited. Previously, the Licenses service could incorrectly process the value of the FacesLimit parameter on large databases.

  • In the Index Manager service, a problem was fixed when an index was not rebuilt. The index was manually deleted or was not built due to a service crash, but was listed in the database as existing, so LP did not rebuild it.

    Now in these cases, the status of lists with a missing index will be set as "failed". Next, the index building task will be added to the scheduler, and the index will be built.