| mapped_pages | applies_to | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
|
:::{include} _snippets/stack-monitoring-def.md :::
::::{admonition} Better monitoring with AutoOps :::{include} _snippets/autoops.md ::: ::::
Each monitored {{stack}} component is considered unique in the cluster based on its persistent UUID, which is written to the path.data directory when the node or instance starts.
Monitoring documents are just ordinary JSON documents built by monitoring each {{stack}} component at a specified collection interval. If you want to alter how these documents are structured or stored, refer to Configuring data streams/indices for monitoring.
You can use {{agent}} or {{metricbeat}} to collect monitoring data and to ship it directly to the monitoring cluster.
In {{ech}}, {{ece}}, and {{eck}}, Elastic manages the installation and configuration of the monitoring agent for you.
You can collect and ship data directly to your monitoring cluster rather than routing it through your production cluster.
The following diagram illustrates a typical monitoring architecture with separate production and monitoring clusters. This example shows {{metricbeat}}, but you can use {{agent}} instead.
:::{image} /deploy-manage/images/elasticsearch-reference-architecture.png :alt: A typical monitoring environment :::
If you have the appropriate license, you can route data from multiple production clusters to a single monitoring cluster. Learn about the differences between various subscription levels.
::::{important} In general, the monitoring cluster and the clusters being monitored should be running the same version of the stack. A monitoring cluster cannot monitor production clusters running newer versions of the stack. If necessary, the monitoring cluster can monitor production clusters running the latest release of the previous major version. ::::
Refer to the following topics to learn how to configure stack monitoring:
- {{es}}:
- (recommended): Uses a single agent to gather logs and metrics. Can be managed from a central location in {{fleet}}.
- : Uses a lightweight {{beats}} shipper to gather metrics. May be preferred if you have an existing investment in {{beats}} or are not yet ready to use {{agent}}.
- : Uses a lightweight {{beats}} shipper to gather logs.
- : Uses internal exporters to gather metrics. Not recommended. If you have previously configured legacy collection methods, you should migrate to using {{agent}} or {{metricbeat}}.
- {{kib}}:
- (recommended): Uses a single agent to gather logs and metrics. Can be managed from a central location in {{fleet}}.
- : Uses a lightweight {{beats}} shipper to gather metrics. May be preferred if you have an existing investment in {{beats}} or are not yet ready to use {{agent}}.
- : Uses internal exporters to gather metrics. Not recommended. If you have previously configured legacy collection methods, you should migrate to using {{agent}} or {{metricbeat}}.
:::{tip} Most of these methods require that you configure monitoring of {{es}} before monitoring other components. :::
-
Logstash:
- Monitoring {{ls}} with {{agent}} (recommended): Uses a single agent to gather logs and metrics. Can be managed from a central location in {{fleet}}.
- Monitoring {{ls}} with legacy collection methods: Use {{metricbeat}} or legacy methods to collect monitoring data from {{ls}}.
-
{{beats}}:
- Auditbeat
- Filebeat
- Heartbeat
- Metricbeat
- Packetbeat
- Winlogbeat
-
{{agent}}s:
- : After you collect monitoring data for one or more products in the {{stack}}, configure {{kib}} to retrieve that information and display it in on the Stack Monitoring page.
- : View health and performance data for {{stack}} components in real time, as well as analyze past performance.
- : Configure alerts that trigger based on stack monitoring metrics.
- : Adjust the data streams and indices used by stack monitoring.