2017-11-02 12:25:10 -04:00
|
|
|
|
[role="xpack"]
|
2018-06-22 18:39:34 -04:00
|
|
|
|
[testenv="basic"]
|
2017-11-02 12:25:10 -04:00
|
|
|
|
[[es-monitoring]]
|
|
|
|
|
= Monitoring {es}
|
|
|
|
|
|
|
|
|
|
[partintro]
|
|
|
|
|
--
|
2018-11-08 16:53:09 -05:00
|
|
|
|
The Elastic {monitor-features} enable you to easily monitor the health of
|
|
|
|
|
your {es} cluster. The monitoring metrics are collected from each node and
|
|
|
|
|
stored in {es} indices.
|
|
|
|
|
|
|
|
|
|
TIP: In production environments, it is recommended to store the monitoring data
|
|
|
|
|
in a separate _monitoring cluster_. See
|
|
|
|
|
{stack-ov}/monitoring-production.html[Monitoring in a production environment].
|
2018-02-23 11:23:16 -05:00
|
|
|
|
|
|
|
|
|
Each {es} node is considered unique based on its persistent UUID, which is
|
|
|
|
|
written on first start to its <<path-settings,`path.data`>> directory, which
|
|
|
|
|
defaults to `./data`.
|
|
|
|
|
|
2018-11-08 16:53:09 -05:00
|
|
|
|
All settings associated with monitoring in {es} must be set in either the
|
2018-04-16 17:57:42 -04:00
|
|
|
|
`elasticsearch.yml` file for each node or, where possible, in the dynamic
|
|
|
|
|
cluster settings. For more information, see <<configuring-monitoring>>.
|
|
|
|
|
|
|
|
|
|
[[es-monitoring-overview]]
|
2018-11-08 16:53:09 -05:00
|
|
|
|
{es} is also at the core of monitoring across the {stack}. In all cases,
|
|
|
|
|
monitoring documents are just ordinary JSON documents built by monitoring each
|
|
|
|
|
{stack} component at some collection interval, then indexing those
|
|
|
|
|
documents into the monitoring cluster.
|
|
|
|
|
|
|
|
|
|
Each component in the stack is responsible for monitoring itself and then
|
|
|
|
|
forwarding those documents to the {es} production cluster for both routing and
|
|
|
|
|
indexing (storage). The routing and indexing processes in {es} are handled by
|
|
|
|
|
what are called <<es-monitoring-collectors,collectors>> and
|
|
|
|
|
<<es-monitoring-exporters,exporters>>.
|
|
|
|
|
|
|
|
|
|
beta[] Alternatively, in 6.4 and later, you can use {metricbeat} to collect
|
|
|
|
|
monitoring data about {kib} and ship it directly to the monitoring cluster,
|
|
|
|
|
rather than routing it through the production cluster. In 6.5 and later, you
|
|
|
|
|
can also use {metricbeat} to collect and ship data about {es}.
|
2018-04-16 17:57:42 -04:00
|
|
|
|
|
|
|
|
|
You can view monitoring data from {kib} where it’s easy to spot issues at a
|
2018-02-23 11:23:16 -05:00
|
|
|
|
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.
|
2017-11-02 12:25:10 -04:00
|
|
|
|
|
2018-11-08 16:53:09 -05:00
|
|
|
|
For an introduction to monitoring your {stack}, including Beats, {ls}, and {kib},
|
|
|
|
|
see {stack-ov}/xpack-monitoring.html[Monitoring the {stack}].
|
2017-11-02 12:25:10 -04:00
|
|
|
|
|
|
|
|
|
--
|
|
|
|
|
|
2018-04-16 17:57:42 -04:00
|
|
|
|
include::collectors.asciidoc[]
|
|
|
|
|
include::exporters.asciidoc[]
|
|
|
|
|
include::pause-export.asciidoc[]
|
|
|
|
|
|