[DOCS] Removed UI and Logstash settings & updated links to that info.
Original commit: elastic/x-pack-elasticsearch@2434e503dd
This commit is contained in:
Deb Adair
parent
f9f47d047d
commit
806b0bc710
|
|
@ -89,9 +89,9 @@ elasticsearch.password: kibanapassword
|
|||
-----------------------------------------------
|
||||
|
||||
The `logstash_system` user is used internally within Logstash when
|
||||
<<monitoring-logstash-settings, monitoring>> is enabled for logstash
|
||||
monitoring is enabled for Logstash.
|
||||
|
||||
If you wish to enable this feature in Logstash, then you need to update the Logstash
|
||||
To enable this feature in Logstash, you need to update the Logstash
|
||||
configuration with the new password by setting `xpack.monitoring.elasticsearch.password` in
|
||||
the `logstash.yml` configuration file:
|
||||
|
||||
|
|
|
|||
|
|
@ -413,4 +413,4 @@ NOTE: By default, when you configure {security} to connect to Active Directory
|
|||
configuration do not match, {security} does not allow a connection to the
|
||||
Active Directory server. This is done to protect against man-in-the-middle
|
||||
attacks. If necessary, you can disable this behavior by setting the
|
||||
<<ssl-tls-settings, `ssl.verification_mode`>> property to `none`.
|
||||
{ref}/security-settings.html#ssl-tls-settings[`ssl.verification_mode`] property to `none`.
|
||||
|
|
|
|||
|
|
@ -104,7 +104,7 @@ xpack:
|
|||
the username from the certificate DN. The first match
|
||||
group is used as the username. Defaults to `CN=(.*?)(?:,\|$)`.
|
||||
| `truststore.path` | no | The path to the truststore. Defaults to the path
|
||||
defined by <<ssl-tls-settings,SSL/TLS settings>>.
|
||||
defined by {ref}/security-settings.html#ssl-tls-settings[SSL/TLS settings].
|
||||
| `truststore.password` | no/yes | Specifies the password for the truststore. Must be
|
||||
provided if `truststore.path` is set.
|
||||
| `truststore.algorithm` | no | Specifies the algorithm used for the truststore.
|
||||
|
|
|
|||
|
|
@ -1,12 +1,10 @@
|
|||
[[security-reference]]
|
||||
== Reference
|
||||
* <<security-privileges, Security Privileges>>
|
||||
* <<security-settings, Security Settings>>
|
||||
* {ref}/security-settings.html[Security Settings]
|
||||
* <<security-files, Security Files>>
|
||||
* <<security-api, Security API>>
|
||||
|
||||
include::reference/privileges.asciidoc[]
|
||||
|
||||
// include::reference/settings.asciidoc[]
|
||||
|
||||
include::reference/files.asciidoc[]
|
||||
|
|
|
|||
|
|
@ -258,7 +258,7 @@ June 24, 2015
|
|||
* The {ref-17}/query-dsl-terms-filter.html#_caching_19[terms filter lookup cache] has been disabled to ensure all requests
|
||||
are properly authorized. This removes the need to manually disable the terms filter cache.
|
||||
* For LDAP client connections, only the protocols and ciphers specified in the `shield.ssl.supported_protocols` and
|
||||
`shield.ssl.ciphers` <<ssl-tls-settings,settings>> will be used.
|
||||
`shield.ssl.ciphers` {ref}/security-settings.html#ssl-tls-settings[settings] will be used.
|
||||
* The auditing mechanism now logs authentication failed events when a request contains an invalid authentication token.
|
||||
|
||||
[float]
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ encryption with key lengths greater than 128 bits, such as 256-bit AES encryptio
|
|||
|
||||
After installation, all cipher suites in the JCE are available for use. To enable
|
||||
the use of stronger cipher suites with {security}, configure the `cipher_suites`
|
||||
parameter. See the <<ssl-tls-settings, Configuration Parameters for TLS/SSL>>
|
||||
parameter. See the {ref}/security-settings.html#ssl-tls-settings[Configuration Parameters for TLS/SSL]
|
||||
section of this document for specific parameter information.
|
||||
|
||||
NOTE: The _JCE Unlimited Strength Jurisdiction Policy Files_ must be installed
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ To use cross cluster search with secured clusters:
|
|||
** Using the same certificate authority to generate certificates for all
|
||||
connected clusters, or
|
||||
** Adding the CA certificate from the local cluster as a trusted CA in
|
||||
each remote cluster (see <<transport-tls-ssl-settings>>).
|
||||
each remote cluster (see {ref}/security-settings.html#transport-tls-ssl-settings[Transport TLS settings]).
|
||||
|
||||
* Configure the local cluster to connect to remote clusters as described
|
||||
in {ref}/modules-cross-cluster-search.html#_configuring_cross_cluster_search[Configuring Cross Cluster Search].
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ The Logstash Elasticsearch plugins (
|
|||
{logstash-ref}/plugins-outputs-elasticsearch.html[output],
|
||||
{logstash-ref}/plugins-inputs-elasticsearch.html[input],
|
||||
{logstash-ref}/plugins-filters-elasticsearch.html[filter]
|
||||
and <<monitoring-logstash-settings, monitoring>>)
|
||||
and {logstash-ref}/monitoring-logstash.html[monitoring]
|
||||
support authentication and encryption over HTTP.
|
||||
|
||||
To use Logstash with a secured cluster, you need to configure authentication
|
||||
|
|
@ -179,7 +179,7 @@ output {
|
|||
[[ls-monitoring-user]]
|
||||
===== Configuring Logstash Monitoring
|
||||
|
||||
If you wish to ship Logstash <<monitoring-logstash-settings, monitoring>>
|
||||
If you wish to ship Logstash {logstash-ref}/logstash-monitoring.html[monitoring]
|
||||
data to a secure cluster, Logstash must be configured with a username and password.
|
||||
|
||||
X-Pack security comes preconfigured with a `logstash_system` user for this purpose.
|
||||
|
|
|
|||
|
|
@ -2,22 +2,9 @@
|
|||
[[settings-xpack]]
|
||||
== Configuring X-Pack
|
||||
|
||||
You can configure {es} settings for {xpack} features in the `elasticsearch.yml`
|
||||
file.
|
||||
|
||||
If you are using {kib}, there are also settings in the `kibana.yml` file. See
|
||||
{kibana}/settings.html[Configuring {kib}].
|
||||
|
||||
//TODO: Add link to "Configuring XPack" in Kibana Reference.
|
||||
|
||||
The following settings pertain to specific {xpack} features:
|
||||
|
||||
* <<ml-settings,Machine Learning Settings>>
|
||||
* {xpack-ref}/monitoring-settings.html[Monitoring Settings]
|
||||
* {xpack-ref}/security-settings.html[Security Settings]
|
||||
* {xpack-ref}/notification-settings.html[Watcher Settings]
|
||||
|
||||
For more information, see <<settings>> and
|
||||
{xpack-ref}/xpack-settings.html[{xpack} Settings].
|
||||
|
||||
include::x-pack-settings.asciidoc
|
||||
include::ml-settings.asciidoc[]
|
||||
include::monitoring-settings.asciidoc[]
|
||||
include::security-settings.asciidoc[]
|
||||
include::notification-settings.asciidoc[]
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
[[xpack-settings]]
|
||||
= X-Pack Settings
|
||||
|
||||
[partintro]
|
||||
--
|
||||
include::x-pack-settings.asciidoc
|
||||
--
|
||||
|
||||
include::ml-settings.asciidoc[]
|
||||
include::monitoring-settings.asciidoc[]
|
||||
include::security-settings.asciidoc[]
|
||||
include::notification-settings.asciidoc[]
|
||||
|
|
@ -1,20 +1,25 @@
|
|||
[[monitoring-settings]]
|
||||
== Monitoring Settings
|
||||
|
||||
You configure <<monitoring-collection-settings, `xpack.monitoring.collection`>>
|
||||
Monitoring is enabled by default when you install {xpack}. You configure
|
||||
<<monitoring-collection-settings, `xpack.monitoring.collection`>>
|
||||
settings in `elasticsearch.yml` to control how data is collected from your
|
||||
Elasticsearch nodes. You can adjust how monitoring data is displayed in the
|
||||
Monitoring UI by configuring <<monitoring-ui-settings, `xpack.monitoring`>>
|
||||
settings in `kibana.yml`.
|
||||
Elasticsearch nodes.
|
||||
|
||||
For more information, see <<configuring-monitoring, Configuring Monitoring>>.
|
||||
To adjust how monitoring data is displayed in the Monitoring UI, you configure
|
||||
{kibana-ref}/monitoring-settings-kb.html[`xpack.monitoring` settings] in
|
||||
`kibana.yml`. To control how monitoring data is collected from
|
||||
Logstash, you configure {logstash-ref}/settings-xpack.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 `false` to disable {monitoring}.
|
||||
Configure in both `elasticsearch.yml` and `kibana.yml`.
|
||||
Set to `false` to disable {es} {monitoring} for Elasticsearch.
|
||||
|
||||
[float]
|
||||
[[monitoring-collection-settings]]
|
||||
|
|
@ -82,269 +87,10 @@ IMPORTANT: This setting currently only impacts `local`-type exporters. Indices c
|
|||
the `http` exporter will not be deleted automatically.
|
||||
|
||||
|
||||
[float]
|
||||
[[monitoring-ui-settings]]
|
||||
=== Monitoring UI Settings
|
||||
|
||||
You can set the following `xpack.monitoring` settings in `kibana.yml` to adjust
|
||||
how the Monitoring UI displays monitoring data. However, the defaults work best
|
||||
in most circumstances. For more information about configuring Kibana, see
|
||||
{kibana-ref}/settings.html[Setting Kibana
|
||||
Server Properties] in the Kibana User Guide.
|
||||
|
||||
`xpack.monitoring.elasticsearch.url`::
|
||||
|
||||
The location of the Elasticsearch instance(s) where your monitoring data is
|
||||
stored. By default, this is the same as the `elasticsearch.url`. This setting
|
||||
enables you to use a single Kibana instance to search and visualize data in
|
||||
your production cluster as well as monitor data sent to a dedicated monitoring
|
||||
cluster.
|
||||
|
||||
`xpack.monitoring.kibana.collection.enabled`::
|
||||
|
||||
Whether or not to enable data collection from the Kibana NodeJS server for
|
||||
Kibana Dashboards to be featured in the Monitoring UI. Defaults to `true`.
|
||||
|
||||
`xpack.monitoring.kibana.collection.interval`::
|
||||
|
||||
Number of milliseconds to wait in between data sampling for Kibana's NodeJS
|
||||
server for the metrics that are displayed in the Kibana dashboards. Defaults to
|
||||
`10000` (10 seconds).
|
||||
|
||||
`xpack.monitoring.max_bucket_size`::
|
||||
|
||||
The number of term buckets to return out of the overall terms list when
|
||||
performing terms aggregations to retrieve index and node metrics. For more
|
||||
information about the `size` parameter, see {ref}/search-aggregations-bucket-terms-aggregation.html#_size[
|
||||
Terms Aggregation] in the Elasticsearch Reference. Defaults to 10000.
|
||||
|
||||
`xpack.monitoring.min_interval_seconds`::
|
||||
|
||||
The minimum number of seconds that a time bucket in a chart can represent.
|
||||
Defaults to 10. If you modify the `xpack.monitoring.collection.interval`
|
||||
in `elasticsearch.yml`, set this option to the same value.
|
||||
|
||||
`xpack.monitoring.node_resolver`::
|
||||
|
||||
The node resolver controls how nodes are considered unique. This can be set to either `uuid`,
|
||||
`transport_address`, or `name`. `uuid` controls uniqueness based on the node's persistent ID.
|
||||
`transport_address` controls uniqueness based on the node's published
|
||||
hostname/IP and port. `name` controls uniqueness based on the node's `node.name` setting. Defaults to
|
||||
`uuid`.
|
||||
|
||||
`xpack.monitoring.report_stats`::
|
||||
|
||||
Whether or not to send cluster statistics to Elastic. Reporting your cluster statistics
|
||||
helps us improve your user experience. Your data is never shared with anyone. Set to
|
||||
`false` to disable statistics reporting from any browser connected to the Kibana instance.
|
||||
You can also opt-out on a per-browser basis through the Monitoring user interface. Defaults to `true`.
|
||||
|
||||
`xpack.monitoring.ui.enabled`::
|
||||
|
||||
Set to `false` to hide the Monitoring UI in Kibana. The Monitoring back-end
|
||||
continues to run as an agent for sending Kibana stats to the Monitoring
|
||||
cluster. Defaults to `true`.
|
||||
|
||||
[float]
|
||||
[[monitoring-ui-cgroup-settings]]
|
||||
==== Monitoring UI Container Settings
|
||||
|
||||
The Monitoring UI exposes the Cgroup statistics that we collect for you to make better decisions
|
||||
about your container performance, rather than guessing based on the overall machine performance.
|
||||
If you are not running your applications in a container, then Cgroup statistics will not be useful.
|
||||
|
||||
`xpack.monitoring.ui.container.elasticsearch.enabled`::
|
||||
|
||||
For Elasticsearch clusters that are running in containers, this setting changes the Node Listing to
|
||||
display the CPU Utilization based on the reported Cgroup statistics. This will also add the calculated
|
||||
Cgroup CPU Utilization to the Node Overview page instead of the overall operating system's CPU
|
||||
Utilization. Defaults to `false`.
|
||||
+
|
||||
image::images/monitoring-es-cgroup-true.png["Elasticsearch Inside a Container",link="images/monitoring-es-cgroup-true.png"]
|
||||
|
||||
[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.
|
||||
|
||||
[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`::
|
||||
|
||||
The 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`::
|
||||
|
||||
The 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
|
||||
<<ssl-monitoring-settings, TLS / SSL section below>>.
|
||||
|
||||
`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.
|
||||
|
||||
[[ssl-monitoring-settings]]
|
||||
:ssl-prefix: xpack.monitoring.exporters.$NAME
|
||||
:component: {monitoring}
|
||||
:verifies:
|
||||
:server!:
|
||||
|
||||
include::ssl-settings.asciidoc[]
|
||||
|
||||
[float]
|
||||
[[monitoring-logstash-settings]]
|
||||
=== Monitoring Logstash Settings
|
||||
|
||||
You can set the following `xpack.monitoring` settings in `logstash.yml` to control how monitoring data is
|
||||
collected from your Logstash nodes. However, the defaults work best in most circumstances. For more
|
||||
information about configuring Logstash, see {logstash-ref}/logstash-settings-file.html[Settings File]
|
||||
section.
|
||||
|
||||
`xpack.monitoring.enabled`::
|
||||
|
||||
Set to `false` to disable X-Pack monitoring.
|
||||
|
||||
`xpack.monitoring.collection.interval`::
|
||||
|
||||
Controls how often data samples are collected and shipped on the Logstash side. Defaults to `10s`.
|
||||
|
||||
`xpack.monitoring.elasticsearch.url`::
|
||||
|
||||
The Elasticsearch instance(s) that you want to ship your Logstash metrics to.
|
||||
This might be the same Elasticsearch instance specified in the `outputs`
|
||||
section in your Logstash configuration, or a different one. This is *not*
|
||||
the URL of your dedicated monitoring cluster. Even if you are using a dedicated
|
||||
monitoring cluster, the Logstash metrics must be routed through your production
|
||||
cluster. You can specify a single host as a string, or specify multiple
|
||||
hosts as an array. Defaults to `http://localhost:9200`.
|
||||
|
||||
`xpack.monitoring.elasticsearch.username` and `xpack.monitoring.elasticsearch.password`::
|
||||
|
||||
If your Elasticsearch is protected with basic authentication, these settings provide the username and
|
||||
password that the Logstash instance uses to authenticate for shipping monitoring data.
|
||||
|
||||
`xpack.monitoring.elasticsearch.ssl.ca`::
|
||||
|
||||
Optional setting that enables you to specify a path to the `.pem` file for the certificate authority for your Elasticsearch instance.
|
||||
|
||||
`xpack.monitoring.elasticsearch.ssl.truststore.path`::
|
||||
|
||||
Optional settings that provide the paths to the Java keystore (JKS) to validate the server’s certificate.
|
||||
|
||||
`xpack.monitoring.elasticsearch.ssl.truststore.password`::
|
||||
|
||||
Optional settings that provide the password to the truststore.
|
||||
|
||||
`xpack.monitoring.elasticsearch.ssl.keystore.path`::
|
||||
|
||||
Optional settings that provide the paths to the Java keystore (JKS) to validate the client’s certificate.
|
||||
|
||||
`xpack.monitoring.elasticsearch.ssl.keystore.password`::
|
||||
|
||||
Optional settings that provide the password to the keystore.
|
||||
include::ssl-settings.asciidoc[]
|
||||
|
|
@ -6,7 +6,7 @@ You configure `xpack.security` settings to
|
|||
and perform message authentication,
|
||||
<<field-document-security-settings, set up document and field
|
||||
level security>>, <<realm-settings, configure realms>>,
|
||||
and <<ssl-tls-settings, encrypt communications with SSL>>.
|
||||
and {ref}/security-settings.html#ssl-tls-settings[encrypt communications with SSL].
|
||||
|
||||
[float]
|
||||
[[general-security-settings]]
|
||||
|
|
|
|||
|
|
@ -1,7 +1,8 @@
|
|||
[float]
|
||||
=== {component} TLS/SSL Settings
|
||||
You can configure the following TLS/SSL settings. If the settings are not configured,
|
||||
the <<ssl-tls-settings, {xpack} defaults>> will be used.
|
||||
the {xpack-ref}/security-settings.html#ssl-tls-settings[Default TLS/SSL Settings]
|
||||
are used.
|
||||
|
||||
ifdef::server[]
|
||||
+{ssl-prefix}.ssl.enabled+::
|
||||
|
|
|
|||
|
|
@ -426,7 +426,7 @@ You can control which HTML features are allowed or disallowed by configuring the
|
|||
`xpack.notification.email.html.sanitization.allow` and
|
||||
`xpack.notification.email.html.sanitization.disallow` settings in
|
||||
`elasticsearch.yml`. You can specify individual HTML elements and
|
||||
<<html-feature-groups, HTML feature groups>>. By default, {watcher} allows the following
|
||||
{ref}/notification-settings.html#html-feature-groups[HTML feature groups]. By default, {watcher} allows the following
|
||||
features: `body`, `head`, `_tables`, `_links`, `_blocks`, `_formatting` and
|
||||
`img:embedded`.
|
||||
|
||||
|
|
|
|||
|
|
@ -232,8 +232,8 @@ xpack.notification.hipchat:
|
|||
room: monitoring
|
||||
--------------------------------------------------
|
||||
|
||||
You can also specify defaults for the <<hipchat-account-attributes,
|
||||
message attributes>>:
|
||||
You can also specify defaults for the {ref}/notification-settings.html#hipchat-account-attributes[
|
||||
message attributes]:
|
||||
|
||||
[source,yaml]
|
||||
--------------------------------------------------
|
||||
|
|
@ -295,8 +295,8 @@ xpack.notification.hipchat:
|
|||
auth_token: 3eLB803Nyp7UBmegJwP1rMdUmzk5HqnzJCgflrhv
|
||||
--------------------------------------------------
|
||||
|
||||
You can also specify defaults for the <<hipchat-account-attributes,
|
||||
message attributes>>:
|
||||
You can also specify defaults for the <{ref}/notification-settings.html#hipchat-account-attributes[
|
||||
message attributes]:
|
||||
|
||||
[source,yaml]
|
||||
--------------------------------------------------
|
||||
|
|
@ -360,8 +360,8 @@ xpack.notification.hipchat:
|
|||
auth_token: 3eLB803Nyp7UBmegJwP1rMdUmzk5HqnzJCgflrhv
|
||||
--------------------------------------------------
|
||||
|
||||
You can also specify defaults for the <<hipchat-account-attributes,
|
||||
message attributes>>.
|
||||
You can also specify defaults for the {ref}/notification-settings.html#hipchat-account-attributes[
|
||||
message attributes].
|
||||
|
||||
[source,yaml]
|
||||
--------------------------------------------------
|
||||
|
|
|
|||
|
|
@ -137,7 +137,8 @@ xpack.notification.jira:
|
|||
WARNING: It is strongly advised to use Basic Authentication with secured HTTPS
|
||||
protocol only.
|
||||
|
||||
You can also specify defaults for the <<jira-account-attributes, Jira issues>>:
|
||||
You can also specify defaults for the
|
||||
{ref}/notification-settings.html#jira-account-attributes[Jira issues]:
|
||||
|
||||
[source,yaml]
|
||||
--------------------------------------------------
|
||||
|
|
|
|||
|
|
@ -203,8 +203,8 @@ xpack.notification.slack:
|
|||
url: https://hooks.slack.com/services/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
|
||||
--------------------------------------------------
|
||||
|
||||
You can also specify defaults for the <<slack-account-attributes, Slack
|
||||
notification attributes>>:
|
||||
You can also specify defaults for the {ref}/notification-settings.html#slack-account-attributes[Slack
|
||||
notification attributes]:
|
||||
|
||||
[source,yaml]
|
||||
--------------------------------------------------
|
||||
|
|
|
|||
|
|
@ -76,8 +76,8 @@ NOTE: By default, both the username and the password are stored in the `.watches
|
|||
You can also use PKI-based authentication when submitting requests to a cluster
|
||||
secured with {security}. When you use PKI-based authentication instead of HTTP
|
||||
basic auth, you don't need to store any authentication information in the watch
|
||||
itself. To use PKI-based authentication, you <<ssl-notification-settings,
|
||||
configure the SSL key settings>> for {watcher} in `elasticsearch.yml`.
|
||||
itself. To use PKI-based authentication, you {ref}/notification-settings.html#ssl-notification-settings
|
||||
[configure the SSL key settings] for {watcher} in `elasticsearch.yml`.
|
||||
|
||||
|
||||
[[webhook-query-parameters]]
|
||||
|
|
|
|||
|
|
@ -100,8 +100,7 @@ PUT _xpack/watcher/watch/cluster_health_watch
|
|||
|
||||
It would be a good idea to create a user with the minimum privileges required for use with such a watch configuration.
|
||||
|
||||
Depending on how your cluster is configured, there may be additional settings required before the watch can access your cluster such as keystores, truststores or certificates.
|
||||
See the <<notification-settings,[Notification Settings>> section of the X-Pack Settings documentation.
|
||||
Depending on how your cluster is configured, there may be additional settings required before the watch can access your cluster such as keystores, truststores or certificates. For more information, see {ref}/notification-settings.html[Notification Settings].
|
||||
|
||||
|
||||
If you check the watch history, you'll see that the cluster status is recorded
|
||||
|
|
|
|||
Loading…
Reference in New Issue