› › ›

收集器

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 时，这非常有用。

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

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