[DOCS] Added exporter details (elastic/x-pack-elasticsearch#4171)
Original commit: elastic/x-pack-elasticsearch@791d9d6a45
This commit is contained in:
Lisa Cawley
GitHub
parent
3e4ceec0c2
commit
3ae8c71f16
|
|
@ -2,8 +2,12 @@
|
|||
[[es-monitoring-collectors]]
|
||||
=== Collectors
|
||||
|
||||
Collectors, as their name implies, collect things. In {monitoring} for {es},
|
||||
collectors have a few rules that define them.
|
||||
Collectors, as their name implies, collect things. Each collector runs once for
|
||||
each collection interval to obtain data from the public APIs in {es} and {xpack}
|
||||
that it chooses to monitor. When the data collection is finished, the data is
|
||||
handed in bulk to the <<es-monitoring-exporters,exporters>> to be sent to the
|
||||
monitoring clusters. Regardless of the number of exporters, each collector only
|
||||
runs once per collection interval.
|
||||
|
||||
There is only one collector per data type gathered. In other words, for any
|
||||
monitoring document that is created, it comes from a single collector rather
|
||||
|
|
@ -67,7 +71,7 @@ Each shard is represented by a separate monitoring document.
|
|||
This information only needs to be collected once, so it is collected on the
|
||||
_elected_ master node. However, for the master node to be able to perform the
|
||||
collection, the master node must have `xpack.ml.enabled` set to true (default)
|
||||
and a license level that supports {ml}.
|
||||
and a license level that supports {ml}.
|
||||
| Node Stats | `node_stats`
|
||||
| Gathers details about the running node, such as memory utilization and CPU
|
||||
usage (for example, `GET /_nodes/_local/stats`).
|
||||
|
|
@ -105,5 +109,38 @@ NOTE: Collection is currently done serially, rather than in parallel, to avoid
|
|||
significant difference and running the collectors in parallel would not
|
||||
prevent such a possibility.
|
||||
|
||||
For more infomration about the configuration options for the collectors, see
|
||||
For more information about the configuration options for the collectors, see
|
||||
<<monitoring-collection-settings>>.
|
||||
|
||||
[[es-monitoring-stack]]
|
||||
==== Collecting data from across the Elastic Stack
|
||||
|
||||
{monitoring} in {es} also receives monitoring data from other parts of the
|
||||
Elastic Stack. In this way, it serves as an unscheduled monitoring data
|
||||
collector for the stack.
|
||||
|
||||
By default, data collection is disabled. {es} monitoring data is not
|
||||
collected and all monitoring data from other sources such as {kib}, Beats, and
|
||||
Logstash is ignored. You must set `xpack.monitoring.collection.enabled` to `true`
|
||||
to enable the collection of monitoring data. See <<monitoring-settings>>.
|
||||
|
||||
Once data is received, it is forwarded to the exporters
|
||||
to be routed to the monitoring cluster like all monitoring data.
|
||||
|
||||
WARNING: Because this stack-level "collector" lives outside of the collection
|
||||
interval of {monitoring} for {es}, it is not impacted by the
|
||||
`xpack.monitoring.collection.interval` setting. Therefore, data is passed to the
|
||||
exporters whenever it is received. This behavior can result in indices for {kib},
|
||||
Logstash, or Beats being created somewhat unexpectedly.
|
||||
|
||||
While the monitoring data is collected and processed, some production cluster
|
||||
metadata is added to incoming documents. This metadata enables {kib} to link the
|
||||
monitoring data to the appropriate cluster. If this linkage is unimportant to
|
||||
the infrastructure that you're monitoring, it might be simpler to configure
|
||||
Logstash and Beats to report monitoring data directly to the monitoring cluster.
|
||||
This scenario also prevents the production cluster from adding extra overhead
|
||||
related to monitoring data, which can be very useful when there are a large
|
||||
number of Logstash nodes or Beats.
|
||||
|
||||
For more information about typical monitoring architectures, see
|
||||
{xpack-ref}/how-monitoring-works.html[How Monitoring Works].
|
||||
|
|
|
|||
|
|
@ -0,0 +1,126 @@
|
|||
[role="xpack"]
|
||||
[[es-monitoring-exporters]]
|
||||
=== Exporters
|
||||
|
||||
The purpose of exporters is to take data collected from any Elastic Stack
|
||||
source and route it to the monitoring cluster. It is possible to configure
|
||||
more than one exporter, but the general and default setup is to use a single
|
||||
exporter.
|
||||
|
||||
There are two types of exporters in {es}:
|
||||
|
||||
`local`::
|
||||
The default exporter used by {monitoring} for {es}. This exporter routes data
|
||||
back into the _same_ cluster.
|
||||
|
||||
`http`::
|
||||
The preferred exporter, which you can use to route data into any supported
|
||||
{es} cluster accessible via HTTP. Production environments should always use a
|
||||
separate monitoring cluster. For more information, see
|
||||
{xpack-ref}/monitoring-production.html[Monitoring in a production environment].
|
||||
|
||||
Both exporters serve the same purpose: to set up the monitoring cluster and route
|
||||
monitoring data. However, they perform these tasks in very different ways. Even
|
||||
though things happen differently, both exporters are capable of sending all of
|
||||
the same data.
|
||||
|
||||
Exporters are configurable at both the node and cluster level. Cluster-wide
|
||||
settings, which are updated with the
|
||||
<<cluster-update-settings,`_cluster/settings` API>>, take precedence over
|
||||
settings in the `elasticsearch.yml` file on each node. When you update an
|
||||
exporter, it is completely replaced by the updated version of the exporter.
|
||||
|
||||
IMPORTANT: It is critical that all nodes share the same setup. Otherwise,
|
||||
monitoring data might be routed in different ways or to different places.
|
||||
|
||||
When the exporters route monitoring data into the monitoring cluster, they use
|
||||
`_bulk` indexing for optimal performance. There is no queuing--in memory or
|
||||
persisted to disk--so any failure during the export results in the loss of
|
||||
that batch of monitoring data. This design limits the impact on {es} and the
|
||||
assumption is that the next pass will succeed.
|
||||
|
||||
[[es-monitoring-default-exporter]]
|
||||
==== Default exporters
|
||||
|
||||
If a node or cluster does not explicitly define an {monitoring} exporter, the
|
||||
following default exporter is used:
|
||||
|
||||
[source,yaml]
|
||||
---------------------------------------------------
|
||||
xpack.monitoring.exporters.default_local: <1>
|
||||
type: local
|
||||
---------------------------------------------------
|
||||
<1> The exporter name uniquely defines the exporter, but it is otherwise unused.
|
||||
When you specify your own exporters, you do not need to explicitly overwrite
|
||||
or reference `default_local`.
|
||||
|
||||
If another exporter is already defined, the default exporter is _not_ created.
|
||||
When you define a new exporter, if the default exporter exists, it is
|
||||
automatically removed.
|
||||
|
||||
[[es-monitoring-templates]]
|
||||
==== Exporter templates and ingest pipelines
|
||||
|
||||
Before exporters can route monitoring data, they must set up certain {es}
|
||||
resources. These resources include templates and ingest pipelines. The
|
||||
following table lists the templates that are required before an exporter can
|
||||
route monitoring data:
|
||||
|
||||
[options="header"]
|
||||
|=======================
|
||||
| Template | Purpose
|
||||
| `.monitoring-alerts` | All cluster alerts for monitoring data.
|
||||
| `.monitoring-beats` | All Beats monitoring data.
|
||||
| `.monitoring-es` | All {es} monitoring data.
|
||||
| `.monitoring-kibana` | All {kib} monitoring data.
|
||||
| `.monitoring-logstash` | All Logstash monitoring data.
|
||||
|=======================
|
||||
|
||||
The templates are ordinary {es} templates that control the default settings and
|
||||
mappings for the monitoring indices.
|
||||
|
||||
By default, monitoring indices are created daily (for example,
|
||||
`.monitoring-es-6-2017.08.26`). You can change the default date suffix for
|
||||
monitoring indices with the `index.name.time_format` setting. You can use this
|
||||
setting to control how frequently monitoring indices are created by a specific
|
||||
`http` exporter. You cannot use this setting with `local` exporters. For more
|
||||
information, see <<http-exporter-settings>>.
|
||||
|
||||
WARNING: Some users create their own templates that match _all_ index patterns,
|
||||
which therefore impact the monitoring indices that get created. It is critical
|
||||
that you do not disable `_source` storage for the monitoring indices. If you do,
|
||||
{monitoring} for {kib} does not work and you cannot visualize monitoring data
|
||||
for your cluster.
|
||||
|
||||
The following table lists the ingest pipelines that are required before an
|
||||
exporter can route monitoring data:
|
||||
|
||||
[options="header"]
|
||||
|=======================
|
||||
| Pipeline | Purpose
|
||||
| `xpack_monitoring_2` | Upgrades X-Pack monitoring data coming from X-Pack
|
||||
5.0 - 5.4 to be compatible with the format used in {monitoring} 5.5.
|
||||
| `xpack_monitoring_6` | A placeholder pipeline that is empty.
|
||||
|=======================
|
||||
|
||||
Exporters handle the setup of these resources before ever sending data. If
|
||||
resource setup fails (for example, due to security permissions), no data is sent
|
||||
and warnings are logged.
|
||||
|
||||
NOTE: Empty pipelines are evaluated on the coordinating node during indexing and
|
||||
they are ignored without any extra effort. This inherently makes them a safe,
|
||||
no-op operation.
|
||||
|
||||
For monitoring clusters that have disabled `node.ingest` on all nodes, it is
|
||||
possible to disable the use of the ingest pipeline feature. However, doing so
|
||||
blocks its purpose, which is to upgrade older monitoring data as our mappings
|
||||
improve over time. Beginning in 6.0, the ingest pipeline feature is a
|
||||
requirement on the monitoring cluster; you must have `node.ingest` enabled on at
|
||||
least one node.
|
||||
|
||||
WARNING: Once any node running 5.5 or later has set up the templates and ingest
|
||||
pipeline on a monitoring cluster, you must use {kib} 5.5 or later to view all
|
||||
subsequent data on the monitoring cluster. The easiest way to determine
|
||||
whether this update has occurred is by checking for the presence of indices
|
||||
matching `.monitoring-es-6-*` (or more concretely the existence of the
|
||||
new pipeline). Versions prior to 5.5 used `.monitoring-es-2-*`.
|
||||
|
|
@ -7,65 +7,20 @@
|
|||
|
||||
{es} is at the core of the {monitoring}. In all cases, {monitoring} documents
|
||||
are just ordinary JSON documents built by monitoring each Elastic Stack
|
||||
component at some polling interval (`10s` by default), then indexing those
|
||||
component at some collection interval (`10s` by default), then indexing those
|
||||
documents into the monitoring cluster. Each component in the stack is
|
||||
responsible for monitoring itself and then forwarding those documents to {es}
|
||||
for both routing and indexing (storage).
|
||||
|
||||
For {es}, this process is handled by what are called _collectors_ and
|
||||
_exporters_. In the past, collectors and exporters were considered to be part of
|
||||
a monitoring "agent", but that term is generally not used anymore.
|
||||
For {es}, this process is handled by what are called
|
||||
<<es-monitoring-collectors,collectors>> and
|
||||
<<es-monitoring-exporters,exporters>>. In the past, collectors and exporters
|
||||
were considered to be part of a monitoring "agent", but that term is generally
|
||||
not used anymore.
|
||||
|
||||
Each collector runs once for each collection interval to obtain data from the
|
||||
public APIs in {es} and {xpack} that it chooses to monitor. When the data
|
||||
collection is finished, the data is handed in bulk to the exporters to be sent
|
||||
to the monitoring clusters.
|
||||
|
||||
{monitoring} in {es} also receives monitoring data from other parts of the
|
||||
Elastic Stack. In this way, it serves as an unscheduled monitoring data
|
||||
collector for the stack. Once data is received, it is forwarded to the exporters
|
||||
to be routed to the monitoring cluster like all monitoring data.
|
||||
|
||||
WARNING: Because this stack-level "collector" lives outside of the collection
|
||||
interval of {monitoring} for {es}, it is not impacted by the
|
||||
`xpack.monitoring.collection.interval` setting. Therefore, data is passed to the
|
||||
exporters whenever it is received. This behavior can result in indices for {kib},
|
||||
Logstash, or Beats being created somewhat unexpectedly.
|
||||
|
||||
While the monitoring data is collected and processed, some production cluster
|
||||
metadata is added to incoming documents. This metadata enables {kib} to link the
|
||||
monitoring data to the appropriate cluster.
|
||||
|
||||
NOTE: If this linkage is unimportant to the infrastructure that you're
|
||||
monitoring, it might be simpler to configure Logstash to report its monitoring
|
||||
data directly to the monitoring cluster. This scenario also prevents the
|
||||
production cluster from adding extra overhead related to monitoring data, which
|
||||
can be very useful when there are a large number of Logstash nodes.
|
||||
|
||||
Regardless of the number of exporters, each collector only runs once per
|
||||
monitoring interval.
|
||||
|
||||
NOTE: It is possible to configure more than one exporter, but the general and
|
||||
default setup is to use a single exporter.
|
||||
|
||||
There are two types of exporters in {es}: `local` and `http`. It is the
|
||||
responsibility of the exporters to send documents to the monitoring cluster
|
||||
that they communicate with. How that happens depends on the exporter, but the
|
||||
end result is the same: documents are indexed in what the exporter deems to be
|
||||
the monitoring cluster.
|
||||
|
||||
Before {monitoring} can actually be used, it is necessary for it to set up
|
||||
certain {es} resources. These include templates and ingest pipelines. Exporters
|
||||
handle the setup of these resources before ever sending data. If resource setup
|
||||
fails (for example, due to security permissions), no data is sent and
|
||||
warnings are logged.
|
||||
|
||||
IMPORTANT: It is critical that all {es} nodes have their exporters configured in
|
||||
the same way. If they do not, some monitoring data might be missing from the
|
||||
monitoring cluster.
|
||||
|
||||
All settings associated with X-Pack monitoring in {es} must be set in either the
|
||||
All settings associated with {monitoring} in {es} must be set in either the
|
||||
`elasticsearch.yml` file for each node or, where possible, in the dynamic
|
||||
cluster settings. For more information, see <<monitoring-settings>>.
|
||||
|
||||
include::collectors.asciidoc[]
|
||||
include::exporters.asciidoc[]
|
||||
|
|
|
|||
Loading…
Reference in New Issue