OpenSearch/docs/reference/monitoring/http-export.asciidoc

[role="xpack"]
[testenv="basic"]
[[http-exporter]]
=== HTTP Exporters

The `http` exporter is the preferred exporter in {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 {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 {security} 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>>.

[float]
[[http-exporter-dns]]
==== Using DNS Hosts in HTTP Exporters

{monitoring} runs inside of the JVM security manager. When the JVM has the
security manager enabled, the JVM changes the duration so that it caches DNS
lookups indefinitely (for example, the mapping of a DNS hostname to an IP 
address). For this reason, if you are in an environment where the DNS response 
might change from time-to-time (for example, talking to any load balanced cloud 
provider), you are strongly discouraged from using DNS hostnames. 

Alternatively, you can set the JVM security property `networkaddress.cache.ttl`, 
which accepts values in seconds. This property must be set for the node's JVM that 
uses {monitoring} for {es} when using DNS that can change IP addresses. If you 
do not apply this setting, the connection consistently fails after the IP 
address changes.

IMPORTANT: JVM security properties are different than system properties. They
cannot be set at startup via `-D` system property settings and instead they must 
be set in code before the security manager has been setup _or_, more 
appropriately, in the `$JAVA_HOME/lib/security/java.security` file.

Restarting the node (and therefore the JVM) results in its cache being flushed.