[role="xpack"] [[monitoring-settings]] === Monitoring settings in Elasticsearch ++++ Monitoring settings ++++ By default, monitoring is enabled but data collection is disabled. To enable data collection, use the `xpack.monitoring.collection.enabled` setting. You can configure these monitoring settings in the `elasticsearch.yml` file. You can also dynamically set some of these settings using the <>. TIP: Cluster settings take precedence over settings in the `elasticsearch.yml` file. To adjust how monitoring data is displayed in the monitoring UI, configure {kibana-ref}/monitoring-settings-kb.html[`xpack.monitoring` settings] in `kibana.yml`. To control how monitoring data is collected from Logstash, configure {logstash-ref}/configuring-logstash.html#monitoring-settings[`xpack.monitoring` settings] in `logstash.yml`. For more information, see {xpack-ref}/xpack-monitoring.html[Monitoring the Elastic Stack]. [float] [[general-monitoring-settings]] ==== General Monitoring Settings `xpack.monitoring.enabled`:: Set to `true` (default) to enable {es} {monitoring} for {es} on the node. + -- NOTE: To enable data collection, you must also set `xpack.monitoring.collection.enabled` to `true`. Its default value is `false`. -- [float] [[monitoring-collection-settings]] ==== Monitoring Collection Settings The `xpack.monitoring.collection` settings control how data is collected from your Elasticsearch nodes. You can dynamically change all monitoring collection settings using the <>. `xpack.monitoring.collection.enabled` (<>):: added[6.3.0] Set to `true` to enable the collection of monitoring data. When this setting is `false` (default), {es} monitoring data is not collected and all monitoring data from other sources such as {kib}, Beats, and Logstash is ignored. `xpack.monitoring.collection.interval` (<>):: Setting to `-1` to disable data collection is no longer supported beginning with 7.0.0. deprecated[6.3.0, Use `xpack.monitoring.collection.enabled` set to `false` instead.] + Controls how often data samples are collected. Defaults to `10s`. If you modify the collection interval, set the `xpack.monitoring.min_interval_seconds` option in `kibana.yml` to the same value. `xpack.monitoring.elasticsearch.collection.enabled` (<>):: Controls whether statistics about your {es} cluster should be collected. Defaults to `true`. This is different from xpack.monitoring.collection.enabled, which allows you to enable or disable all monitoring collection. However, this setting simply disables the collection of Elasticsearch data while still allowing other data (e.g., Kibana, Logstash, Beats, or APM Server monitoring data) to pass through this cluster. `xpack.monitoring.collection.cluster.stats.timeout` (<>):: (<>) Timeout for collecting the cluster statistics. Defaults to `10s`. `xpack.monitoring.collection.node.stats.timeout` (<>):: (<>) Timeout for collecting the node statistics. Defaults to `10s`. `xpack.monitoring.collection.indices` (<>):: Controls which indices Monitoring collects data from. Defaults to all indices. Specify the index names as a comma-separated list, for example `test1,test2,test3`. Names can include wildcards, for example `test*`. You can explicitly exclude indices by prepending `-`. For example `test*,-test3` will monitor all indexes that start with `test` except for `test3`. System indices like .security* or .kibana* always start with a `.`, and generally should be monitored. Consider adding `.*` to the list of indices ensure monitoring of system indices. For example `.*,test*,-test3` `xpack.monitoring.collection.index.stats.timeout` (<>):: (<>) Timeout for collecting index statistics. Defaults to `10s`. `xpack.monitoring.collection.index.recovery.active_only` (<>):: Controls whether or not all recoveries are collected. Set to `true` to collect only active recoveries. Defaults to `false`. `xpack.monitoring.collection.index.recovery.timeout` (<>):: (<>) Timeout for collecting the recovery information. Defaults to `10s`. `xpack.monitoring.history.duration` (<>):: (<>) Retention duration beyond which the indices created by a Monitoring exporter are automatically deleted. Defaults to `7d` (7 days). + -- This setting has a minimum value of `1d` (1 day) to ensure that something is being monitored, and it cannot be disabled. IMPORTANT: This setting currently only impacts `local`-type exporters. Indices created using the `http` exporter will not be deleted automatically. -- `xpack.monitoring.exporters`:: Configures where the agent stores monitoring data. By default, the agent uses a local exporter that indexes monitoring data on the cluster where it is installed. Use an HTTP exporter to send data to a separate monitoring cluster. For more information, see <>, <>, and {xpack-ref}/how-monitoring-works.html[How Monitoring Works]. [float] [[local-exporter-settings]] ==== Local Exporter Settings The `local` exporter is the default exporter used by Monitoring. As the name is meant to imply, it exports data to the _local_ cluster, which means that there is not much needed to be configured. If you do not supply _any_ exporters, then Monitoring will automatically create one for you. If any exporter is provided, then no default is added. [source,yaml] ---------------------------------- xpack.monitoring.exporters.my_local: type: local ---------------------------------- `type`:: The value for a Local exporter must always be `local` and it is required. `use_ingest`:: Whether to supply a placeholder pipeline to the cluster and a pipeline processor with every bulk request. The default value is `true`. If disabled, then it means that it will not use pipelines, which means that a future release cannot automatically upgrade bulk requests to future-proof them. `cluster_alerts.management.enabled`:: Whether to create cluster alerts for this cluster. The default value is `true`. To use this feature, {watcher} must be enabled. If you have a basic license, cluster alerts are not displayed. [float] [[http-exporter-settings]] ==== HTTP Exporter Settings The following lists settings that can be supplied with the `http` exporter. All settings are shown as what follows the name you select for your exporter: [source,yaml] ---------------------------------- xpack.monitoring.exporters.my_remote: type: http host: ["host:port", ...] ---------------------------------- `type`:: The value for an HTTP exporter must always be `http` and it is required. `host`:: Host supports multiple formats, both as an array or as a single value. Supported formats include `hostname`, `hostname:port`, `http://hostname` `http://hostname:port`, `https://hostname`, and `https://hostname:port`. Hosts cannot be assumed. The default scheme is always `http` and the default port is always `9200` if not supplied as part of the `host` string. + [source,yaml] ---------------------------------- xpack.monitoring.exporters: example1: type: http host: "10.1.2.3" example2: type: http host: ["http://10.1.2.4"] example3: type: http host: ["10.1.2.5", "10.1.2.6"] example4: type: http host: ["https://10.1.2.3:9200"] ---------------------------------- `auth.username`:: The username is required if a `auth.password` is supplied. `auth.password`:: The password for the `auth.username`. `connection.timeout`:: (<>) Amount of time that the HTTP connection is supposed to wait for a socket to open for the request. The default value is `6s`. `connection.read_timeout`:: (<>) Amount of time that the HTTP connection is supposed to wait for a socket to send back a response. The default value is `10 * connection.timeout` (`60s` if neither are set). `ssl`:: Each HTTP exporter can define its own TLS / SSL settings or inherit them. See the <>. `proxy.base_path`:: The base path to prefix any outgoing request, such as `/base/path` (e.g., bulk requests would then be sent as `/base/path/_bulk`). There is no default value. `headers`:: Optional headers that are added to every request, which can assist with routing requests through proxies. + [source,yaml] ---------------------------------- xpack.monitoring.exporters.my_remote: headers: X-My-Array: [abc, def, xyz] X-My-Header: abc123 ---------------------------------- + Array-based headers are sent `n` times where `n` is the size of the array. `Content-Type` and `Content-Length` cannot be set. Any headers created by the Monitoring agent will override anything defined here. `index.name.time_format`:: A mechanism for changing the default date suffix for the, by default, daily Monitoring indices. The default value is `YYYY.MM.DD`, which is why the indices are created daily. `use_ingest`:: Whether to supply a placeholder pipeline to the monitoring cluster and a pipeline processor with every bulk request. The default value is `true`. If disabled, then it means that it will not use pipelines, which means that a future release cannot automatically upgrade bulk requests to future-proof them. `cluster_alerts.management.enabled`:: Whether to create cluster alerts for this cluster. The default value is `true`. To use this feature, {watcher} must be enabled. If you have a basic license, cluster alerts are not displayed. `cluster_alerts.management.blacklist`:: Prevents the creation of specific cluster alerts. It also removes any applicable watches that already exist in the current cluster. + + -- You can add any of the following watch identifiers to the blacklist: * `elasticsearch_cluster_status` * `elasticsearch_version_mismatch` * `elasticsearch_nodes` * `kibana_version_mismatch` * `logstash_version_mismatch` * `xpack_license_expiration` For example: `["elasticsearch_version_mismatch","xpack_license_expiration"]`. -- [[ssl-monitoring-settings]] :ssl-prefix: xpack.monitoring.exporters.$NAME :component: {monitoring} :verifies: :server!: include::ssl-settings.asciidoc[]