107 lines
4.5 KiB
Plaintext
107 lines
4.5 KiB
Plaintext
[role="xpack"]
|
|
[testenv="basic"]
|
|
[[http-exporter]]
|
|
=== HTTP exporters
|
|
|
|
[IMPORTANT]
|
|
=========================
|
|
{metricbeat} is the recommended method for collecting and shipping monitoring
|
|
data to a monitoring cluster.
|
|
|
|
If you have previously configured internal collection, you should migrate to
|
|
using {metricbeat} collection. Use either {metricbeat} collection or
|
|
internal collection; do not use both.
|
|
|
|
Learn more about <<configuring-metricbeat>>.
|
|
=========================
|
|
|
|
The `http` exporter is the preferred exporter in the {es} {monitor-features}
|
|
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 {es} REST Client, which enables it to
|
|
send its data to any {es} cluster it can access through the network. Its requests
|
|
make use of the <<common-options-response-filtering,`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>>.
|
|
|
|
[source,yaml]
|
|
----------------------------------
|
|
xpack.monitoring.exporters:
|
|
my_local: <1>
|
|
type: local
|
|
my_remote: <2>
|
|
type: http
|
|
host: [ "10.1.2.3:9200", ... ] <3>
|
|
auth: <4>
|
|
username: my_username
|
|
password: changeme
|
|
connection:
|
|
timeout: 6s
|
|
read_timeout: 60s
|
|
ssl: ... <5>
|
|
proxy:
|
|
base_path: /some/base/path <6>
|
|
headers: <7>
|
|
My-Proxy-Header: abc123
|
|
My-Other-Thing: [ def456, ... ]
|
|
index.name.time_format: YYYY-MM <8>
|
|
|
|
----------------------------------
|
|
<1> A `local` exporter defined explicitly whose arbitrary name is `my_local`.
|
|
<2> An `http` exporter defined whose arbitrary name is `my_remote`. This name
|
|
uniquely defines the exporter but is otherwise unused.
|
|
<3> `host` is a required setting for `http` exporters. It must specify the HTTP
|
|
port rather than the transport port. The default port value is `9200`.
|
|
<4> User authentication for those using {stack} {security-features} or some other
|
|
form of user authentication protecting the cluster.
|
|
<5> See <<http-exporter-settings>> for all TLS/SSL settings. If not supplied,
|
|
the default node-level TLS/SSL settings are used.
|
|
<6> Optional base path to prefix any outgoing request with in order to
|
|
work with proxies.
|
|
<7> Arbitrary key/value pairs to define as headers to send with every request.
|
|
The array-based key/value format sends one header per value.
|
|
<8> A mechanism for changing the date suffix used by default.
|
|
|
|
NOTE: 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:
|
|
|
|
* The production cluster's node restarts.
|
|
* A connection failure to the monitoring cluster.
|
|
* The license on the production cluster changes.
|
|
* The `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.
|
|
|
|
WARNING: 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).
|
|
|
|
IMPORTANT: 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>>.
|