IMPORTANT: No additional bug fixes or documentation updates will be released for this version. For the latest information, see the current release documentation.
Elastic Docs ›Elasticsearch Guide [6.4] ›Monitor a cluster ›Exporters
« Local Exporters Troubleshooting monitoring »

HTTP exportersedit

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 local exporter defined explicitly whose arbitrary name is my_local.

An http exporter defined whose arbitrary name is my_remote. This name uniquely defines the exporter but is otherwise unused.

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.

User authentication for those using X-Pack security 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:

  • 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.

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.

Using DNS Hosts in HTTP Exportersedit

X-Pack 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 X-Pack monitoring for Elasticsearch when using DNS that can change IP addresses. If you do not apply this setting, the connection consistently fails after the IP address changes.

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.

« Local Exporters Troubleshooting monitoring »