The system status data passes through a locally installed
The agent's unstable or failing operation might cause:
- Incorrect display of statistical data in the Wallarm interface.
- Incorrect operation of external monitoring systems.
Starting Nagios compatible scripts. You can get the value of each parameter from
collectd_nagios. You can also get some of the parameters directly: each parameter's description has the information on what script to start in this case.
Getting the raw data stream from
collectd. You can get the raw data stream from any system that is able to receive raw data from
collectdvia any of the write-plugins. For example, this can be another
Triggering a notification on reaching a parameter threshold. You can set the notifications in the file
Possible notification methods:
- NSCA and NSCA-ng
- SNMP TRAP
- custom scripts
The NGINX-Wallarm module's unstable or failing operation might cause a complete or partial denial of service.
For monitoring purposes, NGINX must provide a statistics page for certain
types of requests. To set up the process, use the
in the NGINX configuration file.
If you have a custom setup, you might also need to change the file
Number of requests that can be analyzed. The
requests directive does not
count the requests that have already been analyzed. With the
directive set to
off, the requests are not analyzed.
Number of requests with detected attacks.
Number of requests considered abnormal for the application.
Number of requests blocked by the system.
Number of requests that were not analyzed in the post-analysis module or transferred to the API. For these requests, blocking parameters were applied (i.e. malicious requests were blocked if system was operating in blocking mode), however, data on these events is not visible in the UI and is not taken into consideration for the behavioral/statistical based analytics. This includes
Number of requests where the analysis concluded with an error in the post-analysis module. For these requests, blocking parameters were applied (i.e. malicious requests were blocked if system was operating in blocking mode), however, data on these events is not visible in the UI and is not taken into consideration for the behavioral/statistical based analytics.
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 system was operating in blocking mode), however, data on these events is not visible in the UI. This is only used when Wallarm Node works without a local post analytics module.
Number of issues that led to the emergency termination of the worker process. Normally it should be 0.
Number of cases when the virtual memory limit was reached.
curl_json-wallarm_nginx/derive-memfaults ### `time_detect` The total time it took to analyze the requests. **collectd**:
The total time it took to record the requests in the Tarantool memory.
Wallarm uses Tarantool to store the results of the requests analysis.
Tarantool's unstable or failing operation might lead to failure of the following functionality:
- Upload of attack data to the Wallarm cloud. As a result, the Wallarm interface will not display the attacks.
- Behavioral attack detection; for example, brute-force attacks
- Application structure learning.
The following functionality is independent and does not fail:
- Proxying of HTTP requests.
- Blocking of attacks in the blocking and aggressive modes.
When using a custom address and port of Tarantool, you must change the file
Tarantool has two background processes:
These processes are responsible for the cleanup of old requests on reaching the memory usage threshold. These processes' unstable or failing operation might cause reaching the upper limit of the allocated memory and inability to save new requests.
The time frame to keep the requests in Tarantool. The time frame size depends on the amount of memory allocated to Tarantool and on the size and nature of the HTTP requests. The smaller time frame size negatively affects the detection algorithms that need access to historical data. As a result, the attacker may execute the brute-force attacks faster and remain undetected. This will record a smaller amount of historical data on the attacker's behavior.
The delay between the time the request is saved in Tarantool and the time the detected attacks are uploaded to the Wallarm cloud.
The number of requests deleted before they were analyzed by the scripts
that upload the attacks. The
export_drops directive counts all
requests, regardless of whether the requests have attacks or not.
Since the time frame for the requests deletion and the time frame for the
requests count can be different, you are recommended to use
wallarm-tarantool/gauge-export_drops_flag for TRAP.
The flag indicates that the last iteration deleted the requests that were not analyzed by the scripts that upload the attacks.