IMPORTANT: No additional bug fixes or documentation updates will be released for this version. For the latest information, see the current release documentation.
« Monitoring Logstash Monitoring UI »
Elastic Docs ›Logstash Reference [7.2] ›Monitoring Logstash

X-Pack monitoring Overview

edit

X-Pack monitoring Overview

edit

This section deals with Logstash, including an explanation of its internal parts at a high level. X-Pack monitoring for Logstash represents a total of two pieces:

These pieces are created when X-Pack monitoring for Logstash is enabled, and they live outside of the default Logstash pipeline in a dedicated monitoring pipeline. This configuration means that all data and processing has a minimal impact on ordinary Logstash processing. As a secondary benefit of existing in a separate pipeline, existing Logstash features, such as the elasticsearch output, can be reused to benefit from its retry policies.

The elasticsearch output that is used by X-Pack monitoring for Logstash is configured exclusively via settings found in logstash.yml. It is not configured by using anything from the Logstash configurations that might also be using their own separate elasticsearch outputs.

The Elasticsearch cluster that is configured for use with X-Pack monitoring for Logstash is expected to be the production cluster. This configuration enables the production Elasticsearch cluster to add metadata (for example, its cluster UUID) to the Logstash monitoring data then route it to the monitoring clusters. For more information about typical monitoring architectures, see How monitoring works.

Collectors

edit

Collectors, as their name implies, collect things. In X-Pack monitoring for Logstash, collectors are just Inputs in the same way that ordinary Logstash configurations provide inputs.

Like X-Pack monitoring for Elasticsearch, each collector can create zero or more monitoring documents. As it is currently implemented, each Logstash node runs two types of collectors: one for node stats and one for pipeline stats.

Collector Data Types Description

Node Stats

logstash_stats

Gathers details about the running node, such as memory utilization and CPU usage (for example, GET /_stats).

This runs on every Logstash node with X-Pack monitoring enabled. One common failure is that Logstash directories are copied with their path.data directory included (./data by default), which copies the persistent UUID of the Logstash node along with it. As a result, it generally appears that one or more Logstash nodes are failing to collect monitoring data, when in fact they are all really misreporting as the same Logstash node. Re-use path.data directories only when upgrading Logstash, such that upgraded nodes replace the previous versions.

Pipeline Stats

logstash_state

Gathers details about the node’s running pipelines, which powers the Monitoring Pipeline UI.

Per collection interval, which defaults to 10 seconds (10s), each collector is run. The failure of an individual collector does not impact any other collector. Each collector, as an ordinary Logstash input, creates a separate Logstash event in its isolated monitoring pipeline. The Logstash output then sends the data.

The collection interval can be configured dynamically and you can also disable data collection. For more information about the configuration options for the collectors, see Monitoring Settings.

Unlike X-Pack monitoring for Elasticsearch and Kibana, there is no xpack.monitoring.collection.enabled setting on Logstash. You must use the xpack.monitoring.enabled setting to enable and disable data collection.

If gaps exist in the monitoring charts in Kibana, it is typically because either a collector failed or the monitoring cluster did not receive the data (for example, it was being restarted). In the event that a collector fails, a logged error should exist on the node that attempted to perform the collection.

Output

edit

Like all Logstash pipelines, the purpose of the dedicated monitoring pipeline is to send events to outputs. In the case of X-Pack monitoring for Logstash, the output is always an elasticsearch output. However, unlike ordinary Logstash pipelines, the output is configured within the logstash.yml settings file via the xpack.monitoring.elasticsearch.* settings.

Other than its unique manner of configuration, this elasticsearch output behaves like all elasticsearch outputs, including its ability to pause data collection when issues exist with the output.

It is critical that all Logstash nodes share the same setup. Otherwise, monitoring data might be routed in different ways or to different places.

Default Configuration

edit

If a Logstash node does not explicitly define an X-Pack monitoring output setting, the following default configuration is used:

xpack.monitoring.elasticsearch.hosts: [ "http://localhost:9200" ]

All data produced by X-Pack monitoring for Logstash is indexed in the monitoring cluster by using the .monitoring-logstash template, which is managed by the exporters within Elasticsearch.

If you are working with a cluster that has X-Pack security enabled, extra steps are necessary to properly configure Logstash. For more information, see X-Pack monitoring.

When discussing security relative to the elasticsearch output, it is critical to remember that all users are managed on the production cluster, which is identified in the xpack.monitoring.elasticsearch.hosts setting. This is particularly important to remember when you move from development environments to production environments, where you often have dedicated monitoring clusters.

For more information about the configuration options for the output, see Monitoring Settings.

« Monitoring Logstash Monitoring UI »