[DOCS] Added X-Pack monitoring to Elasticsearch Reference (elastic/x-pack-elasticsearch#2831)

Original commit: elastic/x-pack-elasticsearch@123738556e
This commit is contained in:
Lisa Cawley 2017-11-02 09:25:10 -07:00 committed by GitHub
parent 2acd0afdd5
commit aa41f27d93
5 changed files with 136 additions and 0 deletions

View File

@ -23,6 +23,9 @@ include::release-notes/xpack-breaking.asciidoc[]
:edit_url:
include::{es-repo-dir}/reference/index-shared3.asciidoc[]
:edit_url!:
include::monitoring/index.asciidoc[]
:edit_url!:
include::rest-api/index.asciidoc[]

View File

@ -0,0 +1,52 @@
[role="xpack"]
[[http-exporter]]
== HTTP Exporter
When you configure
an exporter in `elasticsearch.yml`, the default `local` exporter is disabled.
The `http` exporter uses the low-level {es} REST Client. This allows
the `http` exporter to send its data to any {es} cluster it can access
through the network.
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 {ref}/monitoring-settings.html[Monitoring Settings].
[source,yaml]
----------------------------------
xpack.monitoring.exporters:
my_local: <1>
type: local
my_remote: <2>
type: http
host: [ "10.1.2.3", ... ] <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`.
<3> `host` is a required setting for `http` exporters, which can take a few
different forms as described in the table below.
<4> User authentication for those using {security} or some other
form of user authentication protecting the cluster.
<5> See below for all TLS / SSL settings. If not supplied, the default
node-level TLS / SSL settings will be 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.

View File

@ -0,0 +1,23 @@
[role="xpack"]
[[es-monitoring]]
= Monitoring {es}
[partintro]
--
{monitoring} enables you to easily monitor the health of your {es} cluster. The
monitoring metrics are collected from each node and stored in {es} indices. You
can then view the data from {kib} where its easy to spot issues at a glance or
delve into the system behavior over time to diagnose operational issues. In
addition to the built-in status warnings, you can also set up custom alerts
based on the data in the monitoring indices.
This section focuses on the {es} monitoring infrastructure and setup. For an
introduction to monitoring your Elastic stack, including Logstash and {kib}, see
{xpack-ref}/xpack-monitoring.html[Monitoring the Elastic Stack].
//For information about using the Monitoring UI, see Monitoring in the Kibana guide.
--
include::stats-export.asciidoc[]
include::http-export.asciidoc[]
include::tribe.asciidoc[]

View File

@ -0,0 +1,18 @@
[role="xpack"]
[[stats-export]]
== Collecting Data from Particular Indices
By default, the monitoring agent collects data from all {es} indices.
To collect data from particular indices, configure the
`xpack.monitoring.collection.indices` setting in `elasticsearch.yml`.
You can specify multiple indices as a comma-separated list or
use an index pattern to match multiple indices:
[source,yaml]
----------------------------------
xpack.monitoring.collection.indices: logstash-*, index1, test2
----------------------------------
You can prepend `+` or `-` to explicitly include or exclude index
names or patterns. For example, to include all indices that
start with `test` except `test3`, you could specify `+test*,-test3`.

View File

@ -0,0 +1,40 @@
[role="xpack"]
[[monitoring-tribe]]
== Configuring a Tribe Node to Work with Monitoring
If you connect to a cluster through a <<modules-tribe,tribe node>>,
and you want to monitor the tribe node, then you will need to install {xpack} on
that node as well.
With this configuration, the tribe node is included in the node count displayed
in the Monitoring UI, but is not included in the node list because it does not
export any data to the monitoring cluster.
To include the tribe node in the monitoring data, enable Monitoring data
collection at the tribe level:
[source,yaml]
----------------------------------
node.name: my-tribe-node1
tribe:
on_conflict: prefer_cluster1
c1:
cluster.name: cluster1
discovery.zen.ping.unicast.hosts: [ "cluster1-node1:9300", "cluster1-node2:9300", "cluster1-node2:9300" ]
xpack.monitoring.enabled: true <1>
c2:
cluster.name: cluster2
discovery.zen.ping.unicast.hosts: [ "cluster2-node3:9300", "cluster2-node3:9300", "cluster2-node3:9300" ]
xpack.monitoring: <2>
enabled: true
exporters:
id1:
type: http
host: [ "monitoring-cluster:9200" ]
----------------------------------
<1> Enable data collection from the tribe node using a Local Exporter.
<2> Enable data collection from the tribe node using an HTTP Exporter.
When you enable data collection from the tribe node, it is included in both the
node count and node list.