除了 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)。 要了解集成是否为 GA，请参阅集成快速参考表。
- 如果集成可用，请检查支持的输出以查看是否也支持所需的输出。
- 查看功能比较以确定是否支持你的部署所需的任何功能。 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 |  |
 仅适用于运行 Fleet 的同一集群 |
|
| 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 | 处理器可以在集成级别定义。 目前正在考虑在策略级别配置的全局处理器。 |
| 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 的同一 Elasticsearch 集群提供单个全局输出。 我们正在考虑支持远程监控集群。 独立的 Elastic Agent 和 Beats 可以发送到远程监控集群。 |
| 秘钥管理 | |
|
|
Elastic Agent 将凭据存储在代理策略中。 我们正在考虑添加 keystore 支持。 Beats 允许用户访问本地 keystore 中的凭据。 |
| 渐进式或金丝雀部署 | |
|
|
Fleet 没有逐步部署 Elastic Agent 策略更新的功能，但我们正在考虑改进支持。 借助独立的 Elastic Agent 和 Beats，你可以使用第三方解决方案逐步部署配置文件。 |
| 每个主机的多个配置 | |
改用输入条件 |
改用输入条件 |
Elastic Agent 使用单个 Elastic Agent 策略进行配置，并使用变量和输入条件根据每个主机进行调整。 Beats 支持每个主机有多个配置文件，使第三方解决方案能够分层或在多个组中部署文件，并对这些文件实现更细粒度的访问控制。 |
| 兼容版本控制和基础架构即代码解决方案 | |
仅通过 API |
|
Fleet 将代理策略存储在 Elasticsearch 中。 它不作为代码解决方案与外部版本控制或基础架构集成，但我们正在考虑改进支持。 但是，独立模式下的 Beats 和 Elastic Agent 使用与这些解决方案兼容的 YAML 文件。 |
Elastic Agent 监控支持
你在代理策略中配置代理指标的集合。 如果选择了指标收集（默认），所有在策略中注册的 Elastic Agent 都会将指标数据发送到 Elasticsearch（输出是全局配置的）。
下图显示了默认代理策略的代理监控设置：
还有用于代理指标的预构建仪表板，你可以在 Elastic Agent 集成中的 Assets 下访问它们：
[Elastic Agent] Agent metrics 仪表板显示代理指标的聚合视图：
转载：https://blog.csdn.net/UbuntuTouch/article/details/128311534