› › ›

收集器

收集器编辑

建议使用 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 数量很多时非常有用。

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

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