Configuring and Working with the Statistics Service

To obtain statistics about the filter node, use the wallarm_status directive, which is written in the NGINX configuration file.

Configuring the Statistics Service

Important.

It is highly recommended to configure the statistics service in the separate configuration file wallarm-status.conf and not to use the wallarm_status directive in other files that you use when setting up NGINX, because the latter may be insecure.

Also, it is strongly advised not to alter any of the existing lines of the default wallarm-status configuration as it may corrupt the process of metric data upload to the Wallarm cloud.

When using the directive, statistics can be given in JSON format or in a format compatible with Prometheus. Usage:

wallarm_status [on|off] [format=json|prometheus];

The directive can be configured in the context of server and/or location.

When configuring the wallarm_status directive, you can specify the IP addresses from which you can request statistics. By default, access is denied from anywhere except for the IP addresses 127.0.0.1 and ::1, which allow executing the request only from the server where Wallarm is installed.

An example of a secure configuration of the filter node statistics service (wallarm-status.conf) is shown below:

server {
  listen 127.0.0.8:80;
  server_name localhost;
  allow 127.0.0.0/8;   # Access is only available for loopback addresses of the filter node server  
  deny all;                  
  wallarm_mode off;
  access_log off;
  location /wallarm-status {
    wallarm_status on;
  }
}

The listen directive

Note that if you change the IP address of the listen directive (in the example above, 127.0.0.8), you will need to adjust the monitoring settings of the filter node to the new IP address. In addition, you may need to add or change the allow directive to allow access from addresses other than loopback addresses (the above configuration file allows access only to loopback addresses).

To allow requests from another server, add the allow instruction with the IP address of the desired server in the configuration. For example:

allow 10.41.29.0;

Working with the Statistics Service

To obtain the filter node statistics, make a request from one of the allowed IP addresses (see above):

curl http://127.0.0.8/wallarm-status

As a result, you will get a response of the type:

{ "requests":0,"attacks":0,"blocked":0,"abnormal":0,"tnt_errors":0,"api_errors":0,
"requests_lost":0,"segfaults":0,"memfaults":0,"softmemfaults":0,"time_detect":0,"db_id":46,
"lom_id":16767,"proton_instances": { "total":1,"success":1,"fallback":0,"failed":0 },
"stalled_workers_count":0,"stalled_workers":[] }

The following response parameters are available in filter node version 2.10 and lower:

  • requests: the number of requests that have been processed by the filter node.
  • attacks: the number of recorded attacks.
  • blocked: the number of blocked requests.
  • abnormal: the number of requests the application deems abnormal.
  • requests_lost: the number of requests that were not analyzed in a post-analytics module and transferred to API. For these requests, blocking parameters were applied (i.e., malicious requests were blocked if the system was operating in blocking mode); however, data on these events is not visible in the UI. This parameter is only used when the Wallarm Node works with a local post-analytics module.
  • tnt_errors: the number of requests not analyzed by a post-analytics module. For these requests, the reasons for blocking are recorded, but the requests themselves are not counted in statistics and behavior checks.
  • api_errors: the number of requests that were not submitted to the API for further analysis. For these requests, blocking parameters were applied (i.e., malicious requests were blocked if the system was operating in blocking mode); however, data on these events is not visible in the UI. This parameter is only used when the Wallarm Node works with a local post-analytics module.
  • segfaults: the number of issues that led to the emergency termination of the worker process.
  • memfaults: the number of issues where the virtual memory limits were reached.
  • time_detect: the total time of requests analysis.
  • db_id: proton.db version.
  • lom_id: LOM version.
  • proton_instances: information about proton.db + LOM pairs:
    • total: the number of proton.db + LOM pairs.
    • success: the number of the successfully uploaded proton.db + LOM pairs.
    • fallback: the number of proton.db + LOM pairs loaded from the last saved files.
    • failed: the number of proton.db + LOM pairs that were not initialized and run in the “do not analyze” mode.

The following parameters are available in filter node version 2.12:

  • stalled_workers_count: the quantity of workers that exceeded the time limit for request processing (the limit is set in the wallarm_stalled_worker_timeout directive).
  • stalled_workers: the list of the workers that exceeded the time limit for request processing (the limit is set in the wallarm_stalled_worker_timeout directive) and the amount of time spent on request processing.

The data of all counters is accumulated from the moment NGINX is started. If Wallarm has been installed in a ready-made infrastructure with NGINX, the NGINX server must be restarted to start Wallarm.

results matching ""

    No results matching ""