Skip to content

Introduction to the filtering node monitoring

You can monitor the state of a filter node using the node-provided metrics. These metrics are gathered by the collectd service that is installed on every Wallarm filter 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 filter nodes.

Support of the monitoring service on the CDN node

Please note that the collectd service is not supported by the Wallarm CDN nodes.

Need for Monitoring

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 filter 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 “filter node” throughout this guide, unless stated otherwise.

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

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

Prerequisites for Monitoring

For monitoring to work, it is required that:

  • NGINX returns the statistics to the filter node (wallarm_status on),

  • the filtration mode is in the monitoring/block mode.

By default, this service is accessible at http://127.0.0.8/wallarm-status.

If you configure the statistics service to be available at a non-standard address, you will need to correct the URL parameter accordingly in the collectd configuration file. The location of this file depends on the type of operating system distribution you have:

/etc/collectd/wallarm-collectd.conf.d/nginx-wallarm.conf

/etc/wallarm-collectd.d/nginx-wallarm.conf

If a non-standard IP address or port for Tarantool are used, you will need to correct the Tarantool configuration file accordingly. The location of this file depends on the type of operating system distribution you have:

/etc/collectd/collectd.conf.d/wallarm-tarantool.conf

/etc/collectd.d/wallarm-tarantool.conf

If SELinux is installed on the filter node host, make sure that SELinux is either configured or disabled. For simplicity, this document assumes that SELinux is disabled.

How Metrics Look

What the collectd Metrics Look Like

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.

What Wallarm-Specific collectd Metrics Look Like

The filter 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 filter node on the node.example.local host:

  • node.example.local/curl_json-wallarm_nginx/gauge-attacks is the metric of the number of recorded attacks;
  • 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 filter 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 filter 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 filter node deployment types:

    • in the clouds: Amazon AWS, Google Cloud;
    • on Linux for NGINX/NGINX Plus and Kong 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 filter 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 filter node, no matter how that node is deployed.