Monitoring Filtering Node¶

You can monitor the state of the Wallarm filtering node (both NGINX and Native) using the node-provided metrics. This article describes how to operate with the metrics gathered by the collectd service that is installed on every filtering node. The collectd service provides several ways to transfer data and can serve as a source of metrics for many monitoring systems, offering you control over the state of the filtering nodes.

In addition to the collectd metrics, Wallarm provides you with the metric format compatible with Prometheus and basic JSON metrics. Read about these formats in the separate article.

Why monitoring is needed¶

Failure or unstable work in the Wallarm module can lead to complete or partial denial of service for user requests to an application protected by a filtering node.

Failure of or unstable work in the postanalytics module can lead to inaccessibility of the following functionalities:

Uploading attack data to the Wallarm cloud. As a result, the attacks will not be displayed on the Wallarm portal.
Detecting behavioral attacks (see brute-force attacks).
Getting information about the structure of the protected application.

You can monitor both the Wallarm module and the postanalytics module even if the latter is installed separately.

Terminology agreement

To monitor the Wallarm module and the postanalytics module, the same tools and methods are used; therefore both modules will be referred to as a “filtering node” throughout this guide, unless stated otherwise.

All documents describing how to set up monitoring of a filtering node are suitable for

separately deployed Wallarm modules,
separately deployed postanalytics modules, and
jointly deployed Wallarm and postanalytics modules.

Prerequisites¶

For monitoring to work, it is required that:

For Wallarm NGINX nodes, NGINX returns the statistics to the filtering node (wallarm_status on)
The filtration mode is in the monitoring/safe_blocking/block mode.

By default, this service is accessible at http://127.0.0.8/wallarm-status. The address may differ if you have changed it.

Metrics format¶

`collectd` metrics format¶

A collectd metric identifier has the following format:

host/plugin[-plugin_instance]/type[-type_instance]

Where

host: the host’s Fully Qualified Domain Name (FQDN) for which the metric is obtained
plugin: the name of the plugin with which the metric is obtained,
-plugin_instance: the instance of the plugin, if one exists,
type: the type of the metric value. Allowed types:
- counter
- derive
- gauge
Detailed information about value types is available here.
-type_instance: an instance of the type, if there is one. Instance type is equivalent to the value for which we want to get the metric.

A full description of metric formats is available here.

Wallarm-specific `collectd` metrics format¶

The filtering node uses collectd to collect Wallarm-specific metrics.

Metrics of NGINX with the Wallarm module have the following format:

host/curl_json-wallarm_nginx/type-type_instance

Metrics of the postanalytics module have the following format:

host/wallarm-tarantool/type-type_instance

Metric Examples

For a filtering node on the node.example.local host:

node.example.local/curl_json-wallarm_nginx/gauge-abnormal is the metric of the number of processed requests;
node.example.local/wallarm-tarantool/gauge-export_delay is the metric of the Tarantool export delay in seconds.

A complete list of metrics that can be monitored is available here.

Methods of fetching metrics¶

You can collect metrics from a filtering node in several ways:

By exporting data directly from the collectd service
- via the Network plugin for collectd.
  
  This plugin enables collectd to download metrics from a filtering node to the collectd server or to the InfluxDB database.
  
  InfluxDB
  
  InfluxDB can be used for the aggregation of metrics from collectd and other data sources with subsequent visualization (for example, a Grafana monitoring system to visualize the metrics stored in the InfluxDB).
- via one of the write plugins for collectd.
  
  For example, you can export collected data to Graphite using the write_graphite plugin.
  
  Graphite
  
  Graphite can be used as a data source for monitoring and visualization systems (for example, Grafana).
This method is suitable for the following filtering node deployment types:
- in the clouds: Amazon AWS, Google Cloud;
- on Linux for NGINX/NGINX Plus platforms.
By exporting data via collectd-nagios.

This utility receives the value of the given metric from collectd and presents it in a Nagios‑compatible format.

You can export metrics to Nagios or Zabbix monitoring systems by employing this utility.

This method is supported by any Wallarm filtering node, no matter how that node is deployed.
By sending notifications from collectd when a metric has achieved a predetermined threshold value.

This method is supported by any Wallarm filtering node, no matter how that node is deployed.