Observability:我们该选 Beats 还是 Elastic Agents 来采集数据?
2022年12月17日 | by mebius
除了 Logstash 之外,Elastic 提供了两种主要的方式来向 Elasticsearch 发送数据:
我们可以选择直接把数据从 Beats 发送至 Elasticsearch。当然我们也可以通过 Logstash 更进一步处理再发送至 Elasticsearch。
另外一种方式是使用 Elastic Agents 来发送数据至 Elasticsearch:
如上图所示,我们可以直接从 Elastic Agent 来把数据发送至 Elasticsearch 中。
你们这两种方法各有什么优缺点呢?
1)Beats是将操作数据发送到 Elasticsearch 的轻量级数据发送器。 Elastic 为不同类型的数据(例如日志、指标和正常运行时间)提供单独的 Beats。 根据你要收集的数据,你可能需要在单个主机上安装多个发送器。
2)Elastic Agent是日志、指标、安全数据和威胁预防的单一代理。 Elastic Agent 可以以两种不同的模式部署:
- Managed by Fleet —Elastic Agent 策略和生命周期由 Kibana 中的 Fleet 应用集中管理。 Integrations 应用程序还允许你集中添加与其他流行服务和系统的集成。 这是大多数用户的推荐选项。
- Standalone mode —所有策略都作为 YAML 文件手动应用于 Elastic Agent。 这是为更高级的用户准备的。 有关详细信息,请参阅 “安装独立的 Elastic Agents 并采集数据 – Elastic Stack 8.0”。
注意:在独立模式下运行 Elastic Agent 是一个高级用例。 文档不完整,还不成熟。 如果可能,我们建议使用 Fleet 管理的代理而不是独立模式。
你使用的方法取决于你的用例、你需要哪些功能以及你是否要集中管理你的 Agent。
Beats 和 Elastic Agent 都可以将数据直接发送到 Elasticsearch 或通过 Logstash,你可以在其中进一步处理和增强数据,然后在 Kibana 中将其可视化。
本文总结了在添加新的 Elastic Agents 或用 Elastic Agents 替换当前 Beats 之前需要了解的特性和功能。 从版本 7.14.0 开始,Elastic Agent 正式发布 (GA)。
在 Elastic Agent 和 Beats 之间进行选择
Elastic Agent 是一个单一的二进制文件,旨在提供当今各种 Beats 提供的相同功能。 但是,随着我们努力实现功能对等,一些功能差距正在得到解决。
以下步骤将帮助你确定 Elastic Agent 是否可以支持你的用例:
- 确定你需要的集成是否在 Elastic Agent 上受支持和正式发布(GA)。 要了解集成是否为 GtgcodeA,请参阅集成快速参考表。
- 如果集成可用,请检查支持的输出以查看是否也支持所需的输出。
- 查看功能比较以确定是否支持你的部署所需的任何功能。 Elastic Agent 应该支持 Beats 上的大部分可用功能,并且会针对每个版本进行更新。
如果你对所有三个步骤都满意,那么 Elastic Agent 适合你的部署。 但是,如果任何步骤未通过你的评估,你应该继续使用 Beats,并查看未来的更新或在讨论论坛中联系我们
支持的输入
对于由 Fleet 集中管理的 Elastic Agents,数据收集通过集成(integration)进一步简化和定义。 在此模型中,关于输入的决定是由你要从中收集数据的集成驱动的。 各种输入的配置细节的复杂性由 Fleet 集中驱动,特别是由集成驱动。
要了解集成是否为正式发布版GA,请参阅集成快速参考表。
支持的输出
下表显示了 8.5.3 中 Elastic Agent 支持的输出:
注意:Elastic Defend 有不同的输出矩阵。
输出 | Beats | 由 Fleet 管理的 Elastic Agent | Standalone Elastic Agent |
---|---|---|---|
Elasticsearch Service |
|
||
Elasticsearch |
|
||
Logstash | |||
Kafka | 正在考虑之中 | 正在考虑之中 | |
Redis | |||
File | |||
Console |
目前,Fleet 管理的 Elastic Agent 只能输出到运行 Fleet 的同一个 Elasticsearch 集群。 未来版本正在考虑支持输出到远程 Elasticsearch 集群。
支持的配置
Beats 配置 | Elastic Agent 支持 |
---|---|
Modules | 由 integration 来支持 |
Input setting overrides | 不可配置。 设置为默认值。 |
General settings | 许多这些全局设置现在是代理内部的,并且为了正常操作不应修改。 |
Project paths | Elastic Agent 配置这些路径以提供更简单、更精简的配置体验。 |
External configuration file loading | 配置通过策略(policy)分发。 |
Live reloading | 与配置文件重新加载相关。 |
Outputs | 通过 fleet 配置。参见上面定义的支持输出部分 |
SSL | 支持 |
Index lifecycle management | 尽管代理使用数据流,但默认情况下启用。 |
Elasticsearch index template loading | 不再适用 |
Kibana endpoint | 新的 Elastic Agent 工作流不需要这个。 |
Kibana dashboard loading | 新的 Elastic Agent 工作流不需要这个。 |
Processors | 处理器可以在集成级别定义。 目前正在考虑在策略级别配置的全局tgcode处理器。 |
Autodiscover | 通过动态输入(dynamic inputs)促进 Autodiscover。 Elastic Agent 不支持基于提示的自动发现。 |
Internal queues | Elastic Agent 不会向最终用户公开内部内存队列。 你可以配置输出队列参数来调整你的环境,agent 负责配置内部队列以实现你的调整目的。 |
Load balance output hosts | 在 Fleet UI 中,你可以添加 YAML 设置来为每个输出类型配置多个主机,从而实现负载平衡。 |
Logging | 支持 |
HTTP Endpoint | 支持 |
Regular expressions | 支持 |
能力比较
下表是 Beats 和 Elastic Agent 在 8.5.3 中支持的能力对比:
条目 | Beats | 由 Fleet 管理的 Elastic Agent | Standalone Elastic Agent | 描述 |
---|---|---|---|---|
适用于所有用例的单一代理 | Elastic Agent 提供日志、指标等。 你需要为这些用例安装多个 Beats。 | |||
从 Web UI 或 API 安装集成 | Elastic Agent 集成使用方便的 Web UI 或 API 安装,但 Beats 模块使用 CLI 安装。 这将安装 Elasticsearch 资产(例如索引模板和摄取管道)以及 Kibana 资产(例如仪表板)。 | |||
从 Web UI 或 API 配置 |
|
可以在 Web UI 或 API 中配置 Fleet-managed Elastic Agent 集成。 独立 Elastic Agent 可以使用 Web UI、API 或 YAML。 Beats 只能通过 YAML 文件进行配置。 | ||
中央、远程代理策略管理 | Elastic Agent 策略可以通过 Fleet 集中管理。你必须自己或使用第三方解决方案管理 Beats 配置。 | |||
中央、远程代理二进制升级 | 可以通过 Fleet 远程升级 Elastic Agent。 你必须自己升级 Beats 或使用第三方解决方案。 | |||
为单个集成或模块添加 Kibana 和 Elasticsearch 资产 | Elastic Agent 集成允许你一次为单个集成添加 Kibana 和 Elasticsearch 资产。 Beats 一次为所有模块安装数百个资产。 | |||
自动生成的 Elasticsearch API 密钥 | Fleet 可以为每个 Elastic Agent 自动生成具有有限权限的 API 密钥,这些密钥可以单独撤销。 独立的 Elastic Agent 和 Beats 需要你创建和管理凭据,并且用户通常会跨主机共享它们。 | |||
自动生成最小 Elasticsearch 权限 | Fleet 可以根据正在运行的输入自动为 Elastic Agent 提供最小的输出权限。 使用独立的 Elastic Agent 和 Beats,用户通常会授予过于广泛的权限,因为这样更方便。 | |||
数据流支持 | Beats(从 8.0 版开始默认)和 Elastic Agents 使用数据流,索引生命周期管理和数据流命名方案更容易。 | |||
变量和输入条件 |
|
Elastic Agent 提供变量和输入条件以根据本地主机环境动态调整。 用户可以直接在 YAML 中为独立的 Elastic Agent 配置这些,或者使用 Fleet API 为 Fleet-managed Elastic Agent 配置这些。 Integrations 应用程序允许用户输入变量,我们正在考虑使用UI 来编辑条件。 Beats 仅提供静态配置。 | ||
允许非超级用户管理资产和代理 |
|
从版本 8.1.0 开始,不再需要超级用户角色即可使用 Fleet 和 Integrations 应用程序以及相应的 API。 这些应用程序对于独立的 Elastic Agent 是可选的。 Beats 提供更细粒度的角色。 | ||
气隙网络支持 |
|
Integrations 和 Fleet 应用程序可以部署在 Elastic Package Registry 的气隙环境自我管理部署中。Fleet 管理的Elastic Agents 需要连接到我们的工件存储库以进行代理二进制升级。 但是,可以修改策略以使代理指向本地服务器以获取代理二进制文件。 | ||
在主机上使用 root 运行 | Fleet-managed Elastic Agents 需要 root 权限,特别是对于 Elastic Defend。 独立的 Elastic Agents 和 Beats 则没有。 | |||
多个输出 | 单个 Fleet 管理的 Elastic Agent 的策略可以指定多个输出。 | |||
独立监控集群 | Fleet 管理的 Elastic Agent 仅向运行 Fleet 的同一 Elasticsetgcodearch 集群提供单个全局输出。 我们正在考虑支持远程监控集群。 独立的 Elastic Agent 和 Beats 可以发送到远程监控集群。 | |||
秘钥管理 | Elastic Agent 将凭据存储在代理策略中。 我们正在考虑添加 keystore 支持。 Beats 允许用户访问本地 keystore 中的凭据。 | |||
渐进式或金丝雀部署 | Fleet 没有逐步部署 Elastic Agent 策略更新的功能,但我们正在考虑改进支持。 借助独立的 Elastic Agent 和 Beats,你可以使用第三方解决方案逐步部署配置文件。 | |||
每个主机的多个配置 |
|
|
Elastic Agent 使用单个 Elastic Agent 策略进行配置,并使用变量和输入条件根据每个主机进行调整。 Beats 支持每个主机有多个配置文件,使第三方解决方案能够分层或在多个组中部署文件,并对这些文件实现更细粒度的访问控制。 | |
兼容版本控制和基础架构即代码解决方案 |
|
Fleet 将代理策略存储在 Elasticsearch 中。 它不作为代码解决方案与外部版本控制或基础架构集成,但我们正在考虑改进支持。 但是,独立模式下的 Beats 和 Elastic Agent 使用与这些解决方案兼容的 YAML 文件。 |
Elastic Agent 监控支持
你在代理策略中配置代理指标的集合。 如果选择了指标收集(默认),所有在策略中注册的 Elastic Agent 都会将指标数据发送到 Elasticsearch(输出是全局配置的)。
下图显示了默认代理策略的代理监控设置:
还有用于代理指标的预构建仪表板,你可以在 Elastic Agent 集成中的 Assets 下访问它们:
[Elastic Agent] Agent metrics 仪表板显示代理指标的聚合视图: