› › ›

收集器

Elastic Agent 和 Metricbeat 是将监控数据收集并发送到监控集群的推荐方法。

如果您之前配置了旧版收集方法，则应迁移到使用 Elastic Agent 或 Metricbeat 收集。不要将旧版收集与其他收集方法一起使用。

收集器，顾名思义，收集事物。每个收集器在每个收集间隔运行一次，以从 Elasticsearch 和 X-Pack 中选择要监控的公共 API 获取数据。当数据收集完成后，数据会批量移交给导出器，以便发送到监控集群。无论导出器的数量如何，每个收集器在每个收集间隔仅运行一次。

每种数据类型只有一个收集器。换句话说，对于创建的任何监控文档，它都来自单个收集器，而不是从多个收集器合并而来。Elasticsearch 监控功能目前只有几个收集器，因为目标是尽量减少它们之间的重叠以获得最佳性能。

每个收集器可以创建零个或多个监控文档。例如，index_stats 收集器会同时收集所有索引统计信息，以避免多次不必要的调用。

收集器	数据类型	描述
集群统计	`cluster_stats`	收集有关集群状态的详细信息，包括实际集群状态的部分信息（例如 `GET /_cluster/state`）及其统计信息（例如，`GET /_cluster/stats`）。这将生成一个单一的文档类型。在 X-Pack 5.5 之前的版本中，这实际上是三个独立的收集器，导致三个独立的类型：`cluster_stats`、`cluster_state` 和 `cluster_info`。在 5.5 及更高版本中，所有三个都合并到 `cluster_stats` 中。这仅在选定的主节点上运行，并且收集的数据（`cluster_stats`）在很大程度上控制着 UI。当此数据不存在时，表示选定的主节点配置错误、与数据收集相关的超时或存储数据出现问题。每次收集仅生成一个文档。
索引统计	`indices_stats`, `index_stats`	收集有关集群中索引的详细信息，包括摘要和单独的索引。这将创建许多文档，这些文档表示索引统计信息输出的部分内容（例如，`GET /_stats`）。此信息只需要收集一次，因此在选定的主节点上收集。此收集器最常见的故障与大量的索引有关，因此收集它们需要时间，从而导致超时。每次收集生成一个摘要 `indices_stats` 文档，每个索引每次收集生成一个 `index_stats` 文档。
索引恢复	`index_recovery`	收集有关集群中索引恢复的详细信息。索引恢复表示在集群级别分配分片。如果索引未恢复，则不可用。这也对应于通过快照进行的碎片恢复。此信息只需要收集一次，因此在选定的主节点上收集。此收集器最常见的故障与大量分片有关，因此收集它们需要时间，从而导致超时。默认情况下，这将创建一个包含所有恢复的单个文档，该文档可能非常大，但它可以最准确地描述生产集群中的恢复情况。
分片	`shards`	收集有关所有索引的所有已分配分片的详细信息，特别是包括分片分配给哪个节点。此信息只需要收集一次，因此在选定的主节点上收集。收集器使用本地集群状态来获取路由表，而不会像大多数其他收集器那样出现任何网络超时问题。每个分片由单独的监控文档表示。
作业	`job_stats`	收集有关所有机器学习作业统计信息的详细信息（例如，`GET /_ml/anomaly_detectors/_stats`）。此信息只需要收集一次，因此在选定的主节点上收集。但是，为了使主节点能够执行收集，主节点必须将 `xpack.ml.enabled` 设置为 true（默认值），并且许可证级别支持机器学习。
节点统计	`node_stats`	收集有关正在运行的节点的详细信息，例如内存利用率和 CPU 使用率（例如，`GET /_nodes/_local/stats`）。这会在启用监控功能的每个节点上运行。一个常见的失败是由于段文件过多导致节点统计请求超时。因此，收集器会花费太多时间等待文件系统统计信息的计算，直到最终超时。每次收集都会创建一个 `node_stats` 文档。这是按节点收集的，以帮助发现节点之间相互通信的问题，而不是与监控集群通信的问题（例如，间歇性网络问题或内存压力）。

Elasticsearch 监控功能使用单线程调度器在每个节点上运行所有适当收集器对 Elasticsearch 监控数据的收集。此调度器由每个节点在本地管理，其间隔由 xpack.monitoring.collection.interval 控制，该间隔默认为 10 秒（10s），可以在节点或集群级别指定。

从根本上讲，每个收集器都遵循相同的原则。在每个收集间隔，都会检查每个收集器以查看是否应运行，然后运行相应的收集器。单个收集器的故障不会影响任何其他收集器。

收集完成后，所有监控数据都将传递给导出器，以将监控数据路由到监控集群。

如果 Kibana 中的监控图表中存在空白，通常是因为收集器失败或监控集群未收到数据（例如，正在重新启动）。如果收集器失败，则在尝试执行收集的节点上应该存在已记录的错误。

目前，收集是串行而不是并行完成的，以避免选定的主节点上产生额外的开销。这种方法的缺点是，收集器可能会在同一收集期间观察到不同版本的集群状态。实际上，这不会产生重大差异，并且并行运行收集器也无法避免这种可能性。

有关收集器的配置选项的详细信息，请参阅监控收集设置。

从整个 Elastic Stack 收集数据

编辑

Elasticsearch 监控功能还会从 Elastic Stack 的其他部分接收监控数据。这样，它就充当堆栈的非计划监控数据收集器。

默认情况下，数据收集处于禁用状态。不收集 Elasticsearch 监控数据，并且忽略来自 Kibana、Beats 和 Logstash 等其他来源的所有监控数据。您必须将 xpack.monitoring.collection.enabled 设置为 true 才能启用监控数据的收集。请参阅监控设置。

收到数据后，它将像所有监控数据一样转发给导出器，以便路由到监控集群。

由于此堆栈级“收集器”存在于 Elasticsearch 监控功能的收集间隔之外，因此它不受 xpack.monitoring.collection.interval 设置的影响。因此，数据会在收到时立即传递给导出器。这种行为可能导致 Kibana、Logstash 或 Beats 的索引以某种意想不到的方式创建。

虽然收集和处理监控数据，但一些生产集群元数据会添加到传入的文档中。此元数据使 Kibana 能够将监控数据链接到相应的集群。如果此链接对您正在监控的基础设施不重要，则配置 Logstash 和 Beats 将监控数据直接报告给监控集群可能会更简单。当存在大量 Logstash 节点或 Beats 时，这种情况还可以防止生产集群添加与监控数据相关的额外开销，这非常有用。

有关典型监控体系结构的更多信息，请参阅工作原理。

« 使用旧版收集器收集监控数据导出器 »