# Monitoring Filtering Node

You can monitor the state of the Wallarm filtering node (both [NGINX and Native](https://docs.wallarm.com/5.x/installation/nginx-native-node-internals.md)) using the node-provided metrics. This article describes how to operate with the metrics gathered by the [`collectd`](https://collectd.org/) 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](https://docs.wallarm.com/5.x/admin-en/configure-statistics-service.md).

##  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](https://docs.wallarm.com/5.x/attacks-vulns-list.md#brute-force-attack)).
*   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](https://docs.wallarm.com/5.x/admin-en/installation-postanalytics-en.md).

!!! info "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](https://docs.wallarm.com/5.x/installation/nginx-native-node-internals.md#nginx-node), NGINX returns the statistics to the filtering node (`wallarm_status on`)
* The filtration mode is in the `monitoring`/`safe_blocking`/`block` [mode](https://docs.wallarm.com/5.x/admin-en/configure-wallarm-mode.md#available-filtration-modes).
  
By default, this service is accessible at `http://127.0.0.8/wallarm-status`. The address may differ if you have [changed](https://docs.wallarm.com/5.x/admin-en/configure-statistics-service.md#changing-an-ip-address-andor-port-of-the-statistics-service) 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](https://collectd.org/wiki/index.php/Data_source).

*   `-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](https://collectd.org/wiki/index.php/Naming_schema).

### 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/wallarm_nginx/type-type_instance
```

Metrics of the postanalytics module have the following format:

```
host/wallarm-tarantool/type-type_instance
```

!!! info "Metric Examples"
    For a filtering node on the `node.example.local` host:

    * `node.example.local/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](https://docs.wallarm.com/5.x/admin-en/monitoring/available-metrics.md).

##  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`](https://docs.wallarm.com/5.x/admin-en/monitoring/fetching-metrics.md#exporting-metrics-via-the-collectd-network-plugin).
    
        This [plugin](https://collectd.org/wiki/index.php/Plugin:Network) enables `collectd` to download metrics from a filtering node to the [`collectd`](https://collectd.org/wiki/index.php/Networking_introduction) server or to the [InfluxDB](https://www.influxdata.com/products/influxdb-overview/) database.
        
        
        !!! info "InfluxDB"
            InfluxDB can be used for the aggregation of metrics from `collectd` and other data sources with subsequent visualization (for example, a [Grafana](https://grafana.com/) monitoring system to visualize the metrics stored in the InfluxDB).
        
    *   [via one of the write plugins for `collectd`](https://docs.wallarm.com/5.x/admin-en/monitoring/fetching-metrics.md#exporting-metrics-via-the-collectd-write-plugins).
  
        For example, you can export collected data to [Graphite](https://github.com/graphite-project/graphite-web) using the `write_graphite` plugin.
  
        
        !!! info "Graphite"
            Graphite can be used as a data source for monitoring and visualization systems (for example, [Grafana](https://grafana.com/)).
        
  
    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`](https://docs.wallarm.com/5.x/admin-en/monitoring/fetching-metrics.md#exporting-metrics-using-the-collectd-nagios-utility).
  
    This [utility](https://collectd.org/wiki/index.php/Collectd-nagios) receives the value of the given metric from `collectd` and presents it in a [Nagios‑compatible format](https://nagios-plugins.org/doc/guidelines.html#AEN200).
  
    You can export metrics to [Nagios](https://www.nagios.org/) or [Zabbix](https://www.zabbix.com/) 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`](https://docs.wallarm.com/5.x/admin-en/monitoring/fetching-metrics.md#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.