Skip to content

Introduction to the filtering node monitoring

You can monitor the state of a filter node using the node-provided metrics. This article describes how to operate with the metrics 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.

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.

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/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.

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-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 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 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.