The http
exporter is the preferred exporter in X-Pack monitoring because it enables
the use of a separate monitoring cluster. As a secondary benefit, it avoids
using a production cluster node as a coordinating node for indexing monitoring
data because all requests are HTTP requests to the monitoring cluster.
The http
exporter uses the low-level Elasticsearch REST Client, which enables it to
send its data to any Elasticsearch cluster it can access through the network. Its requests
make use of the filter_path
parameter to
reduce bandwidth whenever possible, which helps to ensure that communications
between the production and monitoring clusters are as lightweight as possible.
The http
exporter supports a number of settings that control how it
communicates over HTTP to remote clusters. In most cases, it is not
necessary to explicitly configure these settings. For detailed
descriptions, see Monitoring settings.
xpack.monitoring.exporters: my_local: type: local my_remote: type: http host: [ "10.1.2.3:9200", ... ] auth: username: my_username password: changeme connection: timeout: 6s read_timeout: 60s ssl: ... proxy: base_path: /some/base/path headers: My-Proxy-Header: abc123 My-Other-Thing: [ def456, ... ] index.name.time_format: YYYY-MM
A | |
An | |
| |
User authentication for those using Elastic Stack security features or some other form of user authentication protecting the cluster. | |
See HTTP Exporter Settings for all TLS/SSL settings. If not supplied, the default node-level TLS/SSL settings are used. | |
Optional base path to prefix any outgoing request with in order to work with proxies. | |
Arbitrary key/value pairs to define as headers to send with every request. The array-based key/value format sends one header per value. | |
A mechanism for changing the date suffix used by default. |
The http
exporter accepts an array of hosts
and it will round robin
through the list. It is a good idea to take advantage of that feature when the
monitoring cluster contains more than one node.
Unlike the local
exporter, every node that uses the http
exporter attempts
to check and create the resources that it needs. The http
exporter avoids
re-checking the resources unless something triggers it to perform the checks
again. These triggers include:
http
exporter is dynamically updated (and it is therefore replaced).
The easiest way to trigger a check is to disable, then re-enable the exporter.
This resource management behavior can create a hole for users that
delete monitoring resources. Since the http
exporter does not re-check its
resources unless one of the triggers occurs, this can result in malformed index
mappings.
Unlike the local
exporter, the http
exporter is inherently routing requests
outside of the cluster. This situation means that the exporter must provide a
username and password when the monitoring cluster requires one (or other
appropriate security configurations, such as TLS/SSL settings).
When discussing security relative to the http
exporter, it is
critical to remember that all users are managed on the monitoring cluster. 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 http
exporter,
see HTTP Exporter Settings.