From 5add82519a108c017e1b6c3e55ddb739758a8d46 Mon Sep 17 00:00:00 2001 From: Colleen McGinnis Date: Fri, 29 Aug 2025 14:30:21 -0500 Subject: [PATCH 1/5] add beats agent comparison doc --- reference/fleet/beats-agent-comparison.md | 138 ++++++++++++++++++++++ reference/fleet/toc.yml | 1 + 2 files changed, 139 insertions(+) create mode 100644 reference/fleet/beats-agent-comparison.md diff --git a/reference/fleet/beats-agent-comparison.md b/reference/fleet/beats-agent-comparison.md new file mode 100644 index 0000000000..9f859d4d2a --- /dev/null +++ b/reference/fleet/beats-agent-comparison.md @@ -0,0 +1,138 @@ +# {{beats}} and {{agent}} capabilities [beats-agent-comparison] + +Elastic provides two main ways to send data to {{es}}: + +* **{{beats}}** are lightweight data shippers that send operational data to {{es}}. Elastic provides separate {{beats}} for different types of data, such as logs, metrics, and uptime. Depending on what data you want to collect, you may need to install multiple shippers on a single host. +* **{{agent}}** is a single agent for logs, metrics, security data, and threat prevention. The {{agent}} can be deployed in two different modes: + + * **Managed by {{fleet}}** — The {{agent}} policies and lifecycle are centrally managed by the {{fleet}} app in {{kib}}. The Integrations app also lets you centrally add integrations with other popular services and systems. This is the recommended option for most users. + * **Standalone mode** — All policies are applied to the {{agent}} manually as a YAML file. This is intended for more advanced users. See [Install standalone {{agent}}s](install-standalone-elastic-agent.md) for more information. + + +The method you use depends on your use case, which features you need, and whether you want to centrally manage your agents. + +{{beats}} and {{agent}} can both send data directly to {{es}} or via {{ls}}, where you can further process and enhance the data, before visualizing it in {{kib}}. + +This article summarizes the features and functionality you need to be aware of before adding new {{agent}}s or replacing your current {{beats}} with {{agent}}s. Starting in version 7.14.0, {{agent}} is generally available (GA). + + +## Choosing between {{agent}} and {{beats}} [choosing-between-agent-and-beats] + +{{agent}} is a single binary designed to provide the same functionality that the various {{beats}} provide today. However, some functionality gaps are being addressed as we strive to reach feature parity. + +The following steps will help you determine if {{agent}} can support your use case: + +1. Determine if the integrations you need are supported and Generally Available (GA) on {{agent}}. To find out if an integration is GA, see the [{{integrations}} quick reference table](integration-docs://reference/all_integrations.md). +2. If the integration is available, check [Supported outputs](#supported-outputs-beats-and-agent) to see whether the required output is also supported. +3. Review [Capabilities comparison](#additional-capabilities-beats-and-agent) to determine if any features required by your deployment are supported. {{agent}} should support most of the features available on {{beats}} and is updated for each release. + +If you are satisfied with all three steps, then {{agent}} is suitable for your deployment. However, if any steps fail your assessment, you should continue using {{beats}}, and review future updates or contact us in the [discuss forum](https://discuss.elastic.co/). + + +## Supported inputs [supported-inputs-beats-and-agent] + +For {{agent}}s that are centrally managed by {{fleet}}, data collection is further simplified and defined by integrations. In this model, the decision on the inputs is driven by the integration you want to collect data from. The complexity of configuration details of various inputs is driven centrally by {{fleet}} and specifically by the integrations. + +To find out if an integration is GA, see the [{{integrations}} quick reference table](integration-docs://reference/all_integrations.md). + + +## Supported outputs [supported-outputs-beats-and-agent] + +The following table shows the outputs supported by the {{agent}} in 9.0.0-beta1: + +::::{note} +{{elastic-defend}} and APM Server have a different output matrix. +:::: + + +| Output | {{beats}} | {{fleet}}-managed {{agent}} | Standalone {{agent}} | +| --- | --- | --- | --- | +| {{es}} Service | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | +| {{es}} | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | +| {{ls}} | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | +| Kafka | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | +| Remote {{es}} | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | +| Redis | ![yes](images/green-check.svg "") | ![no](images/red-x.svg "") | ![no](images/red-x.svg "") | +| File | ![yes](images/green-check.svg "") | ![no](images/red-x.svg "") | ![no](images/red-x.svg "") | +| Console | ![yes](images/green-check.svg "") | ![no](images/red-x.svg "") | ![no](images/red-x.svg "") | + + +## Supported configurations [supported-configurations] + +| {{beats}} configuration | {{agent}} support | +| --- | --- | +| [Modules](beats://reference/filebeat/configuration-filebeat-modules.md) | Supported via integrations. | +| [Input setting overrides](beats://reference/filebeat/advanced-settings.md) | Not configurable. Set to default values. | +| [General settings](beats://reference/filebeat/configuration-general-options.md) | Many of these global settings are now internal to the agent and for properoperations should not be modified. | +| [Project paths](beats://reference/filebeat/configuration-path.md) | {{agent}} configures these paths to provide a simpler and more streamlinedconfiguration experience. | +| [External configuration file loading](beats://reference/filebeat/filebeat-configuration-reloading.md) | Config is distributed via policy. | +| [Live reloading](beats://reference/filebeat/_live_reloading.md) | Related to the config file reload. | +| [Outputs](beats://reference/filebeat/configuring-output.md) | Configured through {{fleet}}. See [Supported outputs](#supported-outputs-beats-and-agent). | +| [SSL](beats://reference/filebeat/configuration-ssl.md) | Supported | +| [{{ilm-cap}}](beats://reference/filebeat/ilm.md) | Enabled by default although the Agent uses [data streams](data-streams.md). | +| [{{es}} index template loading](beats://reference/filebeat/configuration-template.md) | No longer applicable | +| [{{kib}} endpoint](beats://reference/filebeat/setup-kibana-endpoint.md) | New {{agent}} workflow doesn’t need this. | +| [{{kib}} dashboard loading](beats://reference/filebeat/configuration-dashboards.md) | New {{agent}} workflow doesn’t need this. | +| [Processors](beats://reference/filebeat/defining-processors.md) | Processors can be defined at the integration level. Global processors, configured at the policy level, are currently under consideration. | +| [Autodiscover](beats://reference/filebeat/configuration-autodiscover.md) | Autodiscover is facilitated through [dynamic inputs](dynamic-input-configuration.md). {{agent}} does not support hints-based autodiscovery. | +| [Internal queues](beats://reference/filebeat/configuring-internal-queue.md) | {{fleet}}-managed {{agent}} and Standalone {{agent}} both support configuration of the internal memoryqueues by an end user. Neither support configuration of the internal disk queues by an end user. | +| [Load balance output hosts](beats://reference/filebeat/elasticsearch-output.md#_loadbalance) | Within the {{fleet}} UI, you can add YAML settings to configure multiple hostsper output type, which enables load balancing. | +| [Logging](beats://reference/filebeat/configuration-logging.md) | Supported | +| [HTTP Endpoint](beats://reference/filebeat/http-endpoint.md) | Supported | +| [Regular expressions](beats://reference/filebeat/regexp-support.md) | Supported | + + +## Capabilities comparison [additional-capabilities-beats-and-agent] + +The following table shows a comparison of capabilities supported by {{beats}} and the {{agent}} in 9.0.0-beta1: + +| Item | {{beats}} | {{fleet}}-managed {{agent}} | Standalone {{agent}} | Description | +| --- | --- | --- | --- | --- | +| Single agent for all use cases | ![no](images/red-x.svg "") | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | {{agent}} provides logs, metrics, and more. You’d need to install multiple {{beats}} for these use cases. | +| Install integrations from web UI or API | ![no](images/red-x.svg "") | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | {{agent}} integrations are installed with a convenient web UI or API, but {{beats}} modules are installed with a CLI. This installs {{es}} assets such as index templates and ingest pipelines, and {{kib}} assets such as dashboards. | +| Configure from web UI or API | ![no](images/red-x.svg "") | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") (optional) | {{fleet}}-managed {{agent}} integrations can be configured in the web UI or API. Standalone {{agent}} can use the web UI, API, or YAML. {{beats}} can only be configured via YAML files. | +| Central, remote agent policy management | ![no](images/red-x.svg "") | ![yes](images/green-check.svg "") | ![no](images/red-x.svg "") | {{agent}} policies can be centrally managed through {{fleet}}. You have to manage {{beats}} configuration yourself or with a third-party solution. | +| Central, remote agent binary upgrades | ![no](images/red-x.svg "") | ![yes](images/green-check.svg "") | ![no](images/red-x.svg "") | {{agent}}s can be remotely upgraded through {{fleet}}. You have to upgrade {{beats}} yourself or with a third-party solution. | +| Add {{kib}} and {{es}} assets for a single integration or module | ![no](images/red-x.svg "") | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | {{agent}} integrations allow you to add {{kib}} and {{es}} assets for a single integration at a time. {{beats}} installs hundreds of assets for all modules at once. | +| Auto-generated {{es}} API keys | ![no](images/red-x.svg "") | ![yes](images/green-check.svg "") | ![no](images/red-x.svg "") | {{fleet}} can automatically generate API keys with limited permissions for each {{agent}}, which can be individually revoked. Standalone {{agent}} and {{beats}} require you to create and manage credentials, and users often share them across hosts. | +| Auto-generate minimal {{es}} permissions | ![no](images/red-x.svg "") | ![yes](images/green-check.svg "") | ![no](images/red-x.svg "") | {{fleet}} can automatically give {{agent}}s minimal output permissions based on the inputs running. With standalone {{agent}} and {{beats}}, users often give overly broad permissions because it’s more convenient. | +| Data streams support | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | Both {{beats}} (default as of version 8.0) and {{agent}}s use [data streams](data-streams.md) with easier index life cycle management and the [data stream naming scheme](https://www.elastic.co/blog/an-introduction-to-the-elastic-data-stream-naming-scheme). | +| Variables and input conditions | ![no](images/red-x.svg "") | ![yes](images/green-check.svg "") (limited) | ![yes](images/green-check.svg "") | {{agent}} offers [variables and input conditions](dynamic-input-configuration.md) to dynamically adjust based on the local host environment. Users can configure these directly in YAML for standalone {{agent}} or using the {{fleet}} API for {{fleet}}-managed {{agent}}. The Integrations app allows users to enter variables, and we are considering a [UI to edit conditions](https://github.com/elastic/kibana/issues/108525). {{beats}} only offers static configuration. | +| Allow non-superusers to manage assets and agents | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") (it’s optional) | Starting with version 8.1.0, a superuser role is no longer required to use the {{fleet}} and Integrations apps and corresponding APIs. These apps are optional for standalone {{agent}}. {{beats}} offers [finer grained](beats://reference/filebeat/feature-roles.md) roles. | +| Air-gapped network support | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") (with Limits) | ![yes](images/green-check.svg "") | The {{integrations}} and {{fleet}} apps can be deployed in an air-gapped environment [self-managed deployment of the {{package-registry}}](air-gapped.md#air-gapped-diy-epr). {{fleet}}-managed {{agent}}s require a connection to our artifact repository for agent binary upgrades. However the policy can be modified to have agents point to a local server in order to fetch the agent binary. | +| Run without root on host | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | {{fleet}}-managed {{agent}}s, Standalone {{agent}}s, and {{beats}} require root permission only if they’re configured to capture data that requires that level of permission. | +| Multiple outputs | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | The policy for a single {{fleet}}-managed {{agent}} can specify multiple outputs. | +| Separate monitoring cluster | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | {{fleet}}-managed {{agent}}s, Standalone {{agent}} and {{beats}} can send to a remote monitoring cluster. | +| Secret management | ![yes](images/green-check.svg "") | ![no](images/red-x.svg "") | ![no](images/red-x.svg "") | {{agent}} stores credentials in the agent policy. We are considering adding [keystore support](https://github.com/elastic/integrations/issues/244). {{beats}} allows users to access credentials in a local [keystore](beats://reference/filebeat/keystore.md). | +| Progressive or canary deployments | ![yes](images/green-check.svg "") | ![no](images/red-x.svg "") | ![yes](images/green-check.svg "") | {{fleet}} does not have a feature to deploy an {{agent}} policy update progressively but we are considering [improved support](https://github.com/elastic/kibana/issues/108267). With standalone {{agent}} and {{beats}} you can deploy configuration files progressively using third party solutions. | +| Multiple configurations per host | ![yes](images/green-check.svg "") | ![no](images/red-x.svg "") (uses input conditions instead) | ![no](images/red-x.svg "") (uses input conditions instead) | {{agent}} uses a single {{agent}} policy for configuration, and uses [variables and input conditions](dynamic-input-configuration.md) to adapt on a per-host basis. {{beats}} supports multiple configuration files per host, enabling third party solutions to deploy files hierarchically or in multiple groups, and enabling finer-grained access control to those files. | +| Compatible with version control and infrastructure as code solutions | ![yes](images/green-check.svg "") | ![no](images/red-x.svg "") (only via API) | ![yes](images/green-check.svg "") | {{fleet}} stores the agent policy in {{es}}. It does not integrate with external version control or infrastructure as code solutions, but we are considering [improved support](https://github.com/elastic/kibana/issues/108524). However, {{beats}} and {{agent}} in standalone mode use a YAML file that is compatible with these solutions. | +| Spooling data to local disk | ![yes](images/green-check.svg "") | ![no](images/red-x.svg "") | ![no](images/red-x.svg "") | This feature is currently being [considered for development](https://github.com/elastic/elastic-agent/issues/3490). | + + +## {{agent}} monitoring support [agent-monitoring-support] + +You configure the collection of agent metrics in the agent policy. If metrics collection is selected (the default), all {{agent}}s enrolled in the policy will send metrics data to {{es}} (the output is configured globally). + +The following image shows the **Agent monitoring** settings for the default agent policy: + +:::{image} images/agent-monitoring-settings.png +:alt: Screen capture of agent monitoring settings in the default agent policy +:screenshot: +::: + +There are also pre-built dashboards for agent metrics that you can access under **Assets** in the {{agent}} integration: + +:::{image} images/agent-monitoring-assets.png +:alt: Screen capture of {{agent}} monitoring assets +:screenshot: +::: + +The **[{{agent}}] Agent metrics** dashboard shows an aggregated view of agent metrics: + +:::{image} images/agent-metrics-dashboard.png +:alt: Screen capture showing {{agent}} metrics +:screenshot: +::: + +For more information, refer to [Monitor {{agent}}s](monitor-elastic-agent.md). diff --git a/reference/fleet/toc.yml b/reference/fleet/toc.yml index 32c2b0d456..35bf978861 100644 --- a/reference/fleet/toc.yml +++ b/reference/fleet/toc.yml @@ -1,6 +1,7 @@ toc: - file: index.md - file: fleet-agent-serverless-restrictions.md + - file: beats-agent-comparison.md - file: migrate-from-beats-to-elastic-agent.md children: - file: migrate-auditbeat-to-agent.md From 76eb0eb4f0fefe27f5fff4ca2627f9a8f41a1783 Mon Sep 17 00:00:00 2001 From: Colleen McGinnis Date: Fri, 29 Aug 2025 14:33:57 -0500 Subject: [PATCH 2/5] update links --- manage-data/ingest/tools.md | 3 +-- reference/fleet/beats-agent-comparison.md | 7 ++++++- reference/fleet/migrate-from-beats-to-elastic-agent.md | 4 ++-- 3 files changed, 9 insertions(+), 5 deletions(-) diff --git a/manage-data/ingest/tools.md b/manage-data/ingest/tools.md index fc1656f252..764f489d19 100644 --- a/manage-data/ingest/tools.md +++ b/manage-data/ingest/tools.md @@ -1,7 +1,6 @@ --- mapped_pages: - https://www.elastic.co/guide/en/cloud/current/ec-cloud-ingest-data.html - - https://www.elastic.co/guide/en/fleet/current/beats-agent-comparison.html - https://www.elastic.co/guide/en/kibana/current/connect-to-elasticsearch.html - https://www.elastic.co/guide/en/serverless/current/project-setting-data.html - https://www.elastic.co/customer-success/data-ingestion @@ -52,7 +51,7 @@ Refer to our [Ingestion](/manage-data/ingest.md) overview for some guidelines to | File upload | Upload data from a file and inspect it before importing it into {{es}}. | [Upload data files](/manage-data/ingest/upload-data-files.md) | | APIs | Ingest data through code by using the APIs of one of the language clients or the {{es}} HTTP APIs. | [Document APIs](https://www.elastic.co/docs/api/doc/elasticsearch/group/endpoint-document) | | OpenTelemetry | Collect and send your telemetry data to Elastic Observability | [Elastic Distributions of OpenTelemetry](opentelemetry://reference/index.md). | -| Fleet and Elastic Agent | Add monitoring for logs, metrics, and other types of data to a host using Elastic Agent, and centrally manage it using Fleet. | [Fleet and {{agent}} overview](/reference/fleet/index.md)
[{{fleet}} and {{agent}} restrictions (Serverless)](/reference/fleet/fleet-agent-serverless-restrictions.md)
[{{beats}} and {{agent}} capabilities](/manage-data/ingest/tools.md)|| +| Fleet and Elastic Agent | Add monitoring for logs, metrics, and other types of data to a host using Elastic Agent, and centrally manage it using Fleet. | [Fleet and {{agent}} overview](/reference/fleet/index.md)
[{{fleet}} and {{agent}} restrictions (Serverless)](/reference/fleet/fleet-agent-serverless-restrictions.md)
[{{beats}} and {{agent}} capabilities](/reference/fleet/beats-agent-comparison.md)|| | {{elastic-defend}} | {{elastic-defend}} provides organizations with prevention, detection, and response capabilities with deep visibility for EPP, EDR, SIEM, and Security Analytics use cases across Windows, macOS, and Linux operating systems running on both traditional endpoints and public cloud environments. | [Configure endpoint protection with {{elastic-defend}}](/solutions/security/configure-elastic-defend.md) | | {{ls}} | Dynamically unify data from a wide variety of data sources and normalize it into destinations of your choice with {{ls}}. | [Logstash](logstash://reference/index.md) | | {{beats}} | Use {{beats}} data shippers to send operational data to Elasticsearch directly or through Logstash. | [{{beats}}](beats://reference/index.md) | diff --git a/reference/fleet/beats-agent-comparison.md b/reference/fleet/beats-agent-comparison.md index 9f859d4d2a..11d5b2c453 100644 --- a/reference/fleet/beats-agent-comparison.md +++ b/reference/fleet/beats-agent-comparison.md @@ -1,4 +1,9 @@ -# {{beats}} and {{agent}} capabilities [beats-agent-comparison] +--- +mapped_pages: + - https://www.elastic.co/guide/en/fleet/current/beats-agent-comparison.html +--- + +# {{beats}} and {{agent}} capabilities Elastic provides two main ways to send data to {{es}}: diff --git a/reference/fleet/migrate-from-beats-to-elastic-agent.md b/reference/fleet/migrate-from-beats-to-elastic-agent.md index eb5fd9fbc8..72bc0a0f1f 100644 --- a/reference/fleet/migrate-from-beats-to-elastic-agent.md +++ b/reference/fleet/migrate-from-beats-to-elastic-agent.md @@ -27,7 +27,7 @@ There are currently some limitations and requirements to be aware of before migr * **No support for configuring the {{beats}} internal queue.** Each Beat has an internal queue that stores events before batching and publishing them to the output. To improve data throughput, {{beats}} users can set [configuration options](beats://reference/filebeat/configuring-internal-queue.md) to tune the performance of the internal queue. However, the endless fine tuning required to configure the queue is cumbersome and not always fruitful. Instead of expecting users to configure the internal queue, {{agent}} uses sensible defaults. This means you won’t be able to migrate internal queue configurations to {{agent}}. -For more information about {{agent}} limitations, see [*{{beats}} and {{agent}} capabilities*](/reference/fleet/index.md). +For more information about {{agent}} limitations, see [*{{beats}} and {{agent}} capabilities*](beats-agent-comparison.md). ## Prepare for the migration [prepare-for-migration] @@ -36,7 +36,7 @@ Before you begin: 1. Review your existing {{beats}} configurations and make a list of the integrations that are required. For example, if your existing implementation collects logs and metrics from Nginx, add Nginx to your list. 2. Make a note of any processors or custom configurations you want to migrate. Some of these customizations may no longer be needed or possible in {{agent}}. -3. Decide if it’s the right time to migrate to {{agent}}. Review the information under [*{{beats}} and {{agent}} capabilities*](/reference/fleet/index.md). Make sure the integrations you need are supported and Generally Available, and that the output and features you require are also supported. +3. Decide if it’s the right time to migrate to {{agent}}. Review the information under [*{{beats}} and {{agent}} capabilities*](beats-agent-comparison.md). Make sure the integrations you need are supported and Generally Available, and that the output and features you require are also supported. If everything checks out, proceed to the next step. Otherwise, you might want to continue using {{beats}} and possibly deploy {{agent}} alongside {{beats}} to use features like endpoint protection. From c47bae50c1c573616651ffd8cbcbae65c2ddb56f Mon Sep 17 00:00:00 2001 From: Colleen McGinnis Date: Fri, 29 Aug 2025 14:37:23 -0500 Subject: [PATCH 3/5] update another link --- manage-data/ingest/ingesting-timeseries-data.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/manage-data/ingest/ingesting-timeseries-data.md b/manage-data/ingest/ingesting-timeseries-data.md index c254545d9e..174fe56696 100644 --- a/manage-data/ingest/ingesting-timeseries-data.md +++ b/manage-data/ingest/ingesting-timeseries-data.md @@ -36,7 +36,7 @@ Ready to try [{{agent}}](/reference/fleet/index.md)? Check out the [installation Beats require that you install a separate Beat for each type of data you want to collect. A single Elastic Agent installed on a host can collect and transport multiple types of data. -**Best practice:** Use [{{agent}}](/reference/fleet/index.md) whenever possible. If your data source is not yet supported by {{agent}}, use {{beats}}. Check out the {{beats}} and {{agent}} [comparison](/manage-data/ingest/tools.md#additional-capabilities-beats-and-agent) for more info. When you are ready to upgrade, check out [Migrate from {{beats}} to {{agent}}](/reference/fleet/migrate-from-beats-to-elastic-agent.md). +**Best practice:** Use [{{agent}}](/reference/fleet/index.md) whenever possible. If your data source is not yet supported by {{agent}}, use {{beats}}. Check out the {{beats}} and {{agent}} [comparison](/reference/fleet/beats-agent-comparison.md) for more info. When you are ready to upgrade, check out [Migrate from {{beats}} to {{agent}}](/reference/fleet/migrate-from-beats-to-elastic-agent.md). ## OpenTelemetry (OTel) collectors [ingest-otel] From cef48b9e3582e18c2d6f42515b00104e9dc17e43 Mon Sep 17 00:00:00 2001 From: Colleen McGinnis Date: Tue, 2 Sep 2025 11:30:02 -0500 Subject: [PATCH 4/5] apply suggestions from code review Co-authored-by: Visha Angelova <91186315+vishaangelova@users.noreply.github.com> --- reference/fleet/beats-agent-comparison.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/reference/fleet/beats-agent-comparison.md b/reference/fleet/beats-agent-comparison.md index 11d5b2c453..0ee6ced1e8 100644 --- a/reference/fleet/beats-agent-comparison.md +++ b/reference/fleet/beats-agent-comparison.md @@ -68,8 +68,8 @@ The following table shows the outputs supported by the {{agent}} in 9.0.0-beta1: | --- | --- | | [Modules](beats://reference/filebeat/configuration-filebeat-modules.md) | Supported via integrations. | | [Input setting overrides](beats://reference/filebeat/advanced-settings.md) | Not configurable. Set to default values. | -| [General settings](beats://reference/filebeat/configuration-general-options.md) | Many of these global settings are now internal to the agent and for properoperations should not be modified. | -| [Project paths](beats://reference/filebeat/configuration-path.md) | {{agent}} configures these paths to provide a simpler and more streamlinedconfiguration experience. | +| [General settings](beats://reference/filebeat/configuration-general-options.md) | Many of these global settings are now internal to the agent and should not be modified. | +| [Project paths](beats://reference/filebeat/configuration-path.md) | {{agent}} configures these paths to provide a simpler and more streamlined configuration experience. | | [External configuration file loading](beats://reference/filebeat/filebeat-configuration-reloading.md) | Config is distributed via policy. | | [Live reloading](beats://reference/filebeat/_live_reloading.md) | Related to the config file reload. | | [Outputs](beats://reference/filebeat/configuring-output.md) | Configured through {{fleet}}. See [Supported outputs](#supported-outputs-beats-and-agent). | @@ -80,10 +80,10 @@ The following table shows the outputs supported by the {{agent}} in 9.0.0-beta1: | [{{kib}} dashboard loading](beats://reference/filebeat/configuration-dashboards.md) | New {{agent}} workflow doesn’t need this. | | [Processors](beats://reference/filebeat/defining-processors.md) | Processors can be defined at the integration level. Global processors, configured at the policy level, are currently under consideration. | | [Autodiscover](beats://reference/filebeat/configuration-autodiscover.md) | Autodiscover is facilitated through [dynamic inputs](dynamic-input-configuration.md). {{agent}} does not support hints-based autodiscovery. | -| [Internal queues](beats://reference/filebeat/configuring-internal-queue.md) | {{fleet}}-managed {{agent}} and Standalone {{agent}} both support configuration of the internal memoryqueues by an end user. Neither support configuration of the internal disk queues by an end user. | -| [Load balance output hosts](beats://reference/filebeat/elasticsearch-output.md#_loadbalance) | Within the {{fleet}} UI, you can add YAML settings to configure multiple hostsper output type, which enables load balancing. | +| [Internal queues](beats://reference/filebeat/configuring-internal-queue.md) | {{fleet}}-managed {{agent}} and Standalone {{agent}} both support configuration of the internal memory queues by an end user. Neither support configuration of the internal disk queues by an end user. | +| [Load balance output hosts](beats://reference/filebeat/elasticsearch-output.md#_loadbalance) | Within the {{fleet}} UI, you can add YAML settings to configure multiple hosts per output type, which enables load balancing. | | [Logging](beats://reference/filebeat/configuration-logging.md) | Supported | -| [HTTP Endpoint](beats://reference/filebeat/http-endpoint.md) | Supported | +| [HTTP endpoint](beats://reference/filebeat/http-endpoint.md) | Supported | | [Regular expressions](beats://reference/filebeat/regexp-support.md) | Supported | @@ -103,13 +103,13 @@ The following table shows a comparison of capabilities supported by {{beats}} an | Auto-generate minimal {{es}} permissions | ![no](images/red-x.svg "") | ![yes](images/green-check.svg "") | ![no](images/red-x.svg "") | {{fleet}} can automatically give {{agent}}s minimal output permissions based on the inputs running. With standalone {{agent}} and {{beats}}, users often give overly broad permissions because it’s more convenient. | | Data streams support | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | Both {{beats}} (default as of version 8.0) and {{agent}}s use [data streams](data-streams.md) with easier index life cycle management and the [data stream naming scheme](https://www.elastic.co/blog/an-introduction-to-the-elastic-data-stream-naming-scheme). | | Variables and input conditions | ![no](images/red-x.svg "") | ![yes](images/green-check.svg "") (limited) | ![yes](images/green-check.svg "") | {{agent}} offers [variables and input conditions](dynamic-input-configuration.md) to dynamically adjust based on the local host environment. Users can configure these directly in YAML for standalone {{agent}} or using the {{fleet}} API for {{fleet}}-managed {{agent}}. The Integrations app allows users to enter variables, and we are considering a [UI to edit conditions](https://github.com/elastic/kibana/issues/108525). {{beats}} only offers static configuration. | -| Allow non-superusers to manage assets and agents | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") (it’s optional) | Starting with version 8.1.0, a superuser role is no longer required to use the {{fleet}} and Integrations apps and corresponding APIs. These apps are optional for standalone {{agent}}. {{beats}} offers [finer grained](beats://reference/filebeat/feature-roles.md) roles. | -| Air-gapped network support | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") (with Limits) | ![yes](images/green-check.svg "") | The {{integrations}} and {{fleet}} apps can be deployed in an air-gapped environment [self-managed deployment of the {{package-registry}}](air-gapped.md#air-gapped-diy-epr). {{fleet}}-managed {{agent}}s require a connection to our artifact repository for agent binary upgrades. However the policy can be modified to have agents point to a local server in order to fetch the agent binary. | +| Allow non-superusers to manage assets and agents | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") (optional) | Starting with version 8.1.0, a superuser role is no longer required to use the {{fleet}} and Integrations apps and corresponding APIs. These apps are optional for standalone {{agent}}. {{beats}} offers [finer grained](beats://reference/filebeat/feature-roles.md) roles. | +| Air-gapped network support | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") (limited) | ![yes](images/green-check.svg "") | The {{integrations}} and {{fleet}} apps can be deployed in an air-gapped environment [self-managed deployment of the {{package-registry}}](air-gapped.md#air-gapped-diy-epr). {{fleet}}-managed {{agent}}s require a connection to our artifact repository for agent binary upgrades. However the policy can be modified to have agents point to a local server in order to fetch the agent binary. | | Run without root on host | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | {{fleet}}-managed {{agent}}s, Standalone {{agent}}s, and {{beats}} require root permission only if they’re configured to capture data that requires that level of permission. | | Multiple outputs | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | The policy for a single {{fleet}}-managed {{agent}} can specify multiple outputs. | | Separate monitoring cluster | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | {{fleet}}-managed {{agent}}s, Standalone {{agent}} and {{beats}} can send to a remote monitoring cluster. | | Secret management | ![yes](images/green-check.svg "") | ![no](images/red-x.svg "") | ![no](images/red-x.svg "") | {{agent}} stores credentials in the agent policy. We are considering adding [keystore support](https://github.com/elastic/integrations/issues/244). {{beats}} allows users to access credentials in a local [keystore](beats://reference/filebeat/keystore.md). | -| Progressive or canary deployments | ![yes](images/green-check.svg "") | ![no](images/red-x.svg "") | ![yes](images/green-check.svg "") | {{fleet}} does not have a feature to deploy an {{agent}} policy update progressively but we are considering [improved support](https://github.com/elastic/kibana/issues/108267). With standalone {{agent}} and {{beats}} you can deploy configuration files progressively using third party solutions. | +| Progressive or canary deployments | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "" {applies_to}`stack: ga 9.1.0` | ![yes](images/green-check.svg "") | To upgrade {{fleet}}-managed {{agents}} progressively, you can [configure an automatic upgrade](upgrade-elastic-agent.md#auto-upgrade-agents) in the {{agent}} policy. {applies_to}`stack: ga 9.1.0`
With standalone {{agent}} and {{beats}} you can deploy configuration files progressively using third party solutions. | | Multiple configurations per host | ![yes](images/green-check.svg "") | ![no](images/red-x.svg "") (uses input conditions instead) | ![no](images/red-x.svg "") (uses input conditions instead) | {{agent}} uses a single {{agent}} policy for configuration, and uses [variables and input conditions](dynamic-input-configuration.md) to adapt on a per-host basis. {{beats}} supports multiple configuration files per host, enabling third party solutions to deploy files hierarchically or in multiple groups, and enabling finer-grained access control to those files. | | Compatible with version control and infrastructure as code solutions | ![yes](images/green-check.svg "") | ![no](images/red-x.svg "") (only via API) | ![yes](images/green-check.svg "") | {{fleet}} stores the agent policy in {{es}}. It does not integrate with external version control or infrastructure as code solutions, but we are considering [improved support](https://github.com/elastic/kibana/issues/108524). However, {{beats}} and {{agent}} in standalone mode use a YAML file that is compatible with these solutions. | | Spooling data to local disk | ![yes](images/green-check.svg "") | ![no](images/red-x.svg "") | ![no](images/red-x.svg "") | This feature is currently being [considered for development](https://github.com/elastic/elastic-agent/issues/3490). | From ca3dd897deb3290ea4d89b4209f9367d17e00cac Mon Sep 17 00:00:00 2001 From: Colleen McGinnis Date: Tue, 2 Sep 2025 15:42:23 -0500 Subject: [PATCH 5/5] address comments, fix formatting --- reference/fleet/beats-agent-comparison.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/reference/fleet/beats-agent-comparison.md b/reference/fleet/beats-agent-comparison.md index 0ee6ced1e8..4f9e7b49fb 100644 --- a/reference/fleet/beats-agent-comparison.md +++ b/reference/fleet/beats-agent-comparison.md @@ -51,7 +51,7 @@ The following table shows the outputs supported by the {{agent}} in 9.0.0-beta1: | Output | {{beats}} | {{fleet}}-managed {{agent}} | Standalone {{agent}} | -| --- | --- | --- | --- | +| --- |:---:|:---:|:---:| | {{es}} Service | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | | {{es}} | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | | {{ls}} | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | @@ -92,26 +92,26 @@ The following table shows the outputs supported by the {{agent}} in 9.0.0-beta1: The following table shows a comparison of capabilities supported by {{beats}} and the {{agent}} in 9.0.0-beta1: | Item | {{beats}} | {{fleet}}-managed {{agent}} | Standalone {{agent}} | Description | -| --- | --- | --- | --- | --- | +| --- |:---:|:---:|:---:| --- | | Single agent for all use cases | ![no](images/red-x.svg "") | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | {{agent}} provides logs, metrics, and more. You’d need to install multiple {{beats}} for these use cases. | | Install integrations from web UI or API | ![no](images/red-x.svg "") | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | {{agent}} integrations are installed with a convenient web UI or API, but {{beats}} modules are installed with a CLI. This installs {{es}} assets such as index templates and ingest pipelines, and {{kib}} assets such as dashboards. | -| Configure from web UI or API | ![no](images/red-x.svg "") | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") (optional) | {{fleet}}-managed {{agent}} integrations can be configured in the web UI or API. Standalone {{agent}} can use the web UI, API, or YAML. {{beats}} can only be configured via YAML files. | +| Configure from web UI or API | ![no](images/red-x.svg "") | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "")
(optional) | {{fleet}}-managed {{agent}} integrations can be configured in the web UI or API. Standalone {{agent}} can use the web UI, API, or YAML. {{beats}} can only be configured via YAML files. | | Central, remote agent policy management | ![no](images/red-x.svg "") | ![yes](images/green-check.svg "") | ![no](images/red-x.svg "") | {{agent}} policies can be centrally managed through {{fleet}}. You have to manage {{beats}} configuration yourself or with a third-party solution. | | Central, remote agent binary upgrades | ![no](images/red-x.svg "") | ![yes](images/green-check.svg "") | ![no](images/red-x.svg "") | {{agent}}s can be remotely upgraded through {{fleet}}. You have to upgrade {{beats}} yourself or with a third-party solution. | | Add {{kib}} and {{es}} assets for a single integration or module | ![no](images/red-x.svg "") | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | {{agent}} integrations allow you to add {{kib}} and {{es}} assets for a single integration at a time. {{beats}} installs hundreds of assets for all modules at once. | | Auto-generated {{es}} API keys | ![no](images/red-x.svg "") | ![yes](images/green-check.svg "") | ![no](images/red-x.svg "") | {{fleet}} can automatically generate API keys with limited permissions for each {{agent}}, which can be individually revoked. Standalone {{agent}} and {{beats}} require you to create and manage credentials, and users often share them across hosts. | | Auto-generate minimal {{es}} permissions | ![no](images/red-x.svg "") | ![yes](images/green-check.svg "") | ![no](images/red-x.svg "") | {{fleet}} can automatically give {{agent}}s minimal output permissions based on the inputs running. With standalone {{agent}} and {{beats}}, users often give overly broad permissions because it’s more convenient. | | Data streams support | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | Both {{beats}} (default as of version 8.0) and {{agent}}s use [data streams](data-streams.md) with easier index life cycle management and the [data stream naming scheme](https://www.elastic.co/blog/an-introduction-to-the-elastic-data-stream-naming-scheme). | -| Variables and input conditions | ![no](images/red-x.svg "") | ![yes](images/green-check.svg "") (limited) | ![yes](images/green-check.svg "") | {{agent}} offers [variables and input conditions](dynamic-input-configuration.md) to dynamically adjust based on the local host environment. Users can configure these directly in YAML for standalone {{agent}} or using the {{fleet}} API for {{fleet}}-managed {{agent}}. The Integrations app allows users to enter variables, and we are considering a [UI to edit conditions](https://github.com/elastic/kibana/issues/108525). {{beats}} only offers static configuration. | +| Variables and input conditions | ![no](images/red-x.svg "") | ![yes](images/green-check.svg "")
(limited) | ![yes](images/green-check.svg "") | {{agent}} offers [variables and input conditions](dynamic-input-configuration.md) to dynamically adjust based on the local host environment. Users can configure these directly in YAML for standalone {{agent}} or using the {{fleet}} API for {{fleet}}-managed {{agent}}. The Integrations app allows users to enter variables, and we are considering a [UI to edit conditions](https://github.com/elastic/kibana/issues/108525). {{beats}} only offers static configuration. | | Allow non-superusers to manage assets and agents | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") (optional) | Starting with version 8.1.0, a superuser role is no longer required to use the {{fleet}} and Integrations apps and corresponding APIs. These apps are optional for standalone {{agent}}. {{beats}} offers [finer grained](beats://reference/filebeat/feature-roles.md) roles. | -| Air-gapped network support | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") (limited) | ![yes](images/green-check.svg "") | The {{integrations}} and {{fleet}} apps can be deployed in an air-gapped environment [self-managed deployment of the {{package-registry}}](air-gapped.md#air-gapped-diy-epr). {{fleet}}-managed {{agent}}s require a connection to our artifact repository for agent binary upgrades. However the policy can be modified to have agents point to a local server in order to fetch the agent binary. | +| Air-gapped network support | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "")
(limited) | ![yes](images/green-check.svg "") | The {{integrations}} and {{fleet}} apps can be deployed in an air-gapped environment [self-managed deployment of the {{package-registry}}](air-gapped.md#air-gapped-diy-epr). {{fleet}}-managed {{agent}}s require a connection to our artifact repository for agent binary upgrades. However the policy can be modified to have agents point to a local server in order to fetch the agent binary. | | Run without root on host | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | {{fleet}}-managed {{agent}}s, Standalone {{agent}}s, and {{beats}} require root permission only if they’re configured to capture data that requires that level of permission. | | Multiple outputs | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | The policy for a single {{fleet}}-managed {{agent}} can specify multiple outputs. | | Separate monitoring cluster | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "") | {{fleet}}-managed {{agent}}s, Standalone {{agent}} and {{beats}} can send to a remote monitoring cluster. | -| Secret management | ![yes](images/green-check.svg "") | ![no](images/red-x.svg "") | ![no](images/red-x.svg "") | {{agent}} stores credentials in the agent policy. We are considering adding [keystore support](https://github.com/elastic/integrations/issues/244). {{beats}} allows users to access credentials in a local [keystore](beats://reference/filebeat/keystore.md). | -| Progressive or canary deployments | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "" {applies_to}`stack: ga 9.1.0` | ![yes](images/green-check.svg "") | To upgrade {{fleet}}-managed {{agents}} progressively, you can [configure an automatic upgrade](upgrade-elastic-agent.md#auto-upgrade-agents) in the {{agent}} policy. {applies_to}`stack: ga 9.1.0`
With standalone {{agent}} and {{beats}} you can deploy configuration files progressively using third party solutions. | -| Multiple configurations per host | ![yes](images/green-check.svg "") | ![no](images/red-x.svg "") (uses input conditions instead) | ![no](images/red-x.svg "") (uses input conditions instead) | {{agent}} uses a single {{agent}} policy for configuration, and uses [variables and input conditions](dynamic-input-configuration.md) to adapt on a per-host basis. {{beats}} supports multiple configuration files per host, enabling third party solutions to deploy files hierarchically or in multiple groups, and enabling finer-grained access control to those files. | -| Compatible with version control and infrastructure as code solutions | ![yes](images/green-check.svg "") | ![no](images/red-x.svg "") (only via API) | ![yes](images/green-check.svg "") | {{fleet}} stores the agent policy in {{es}}. It does not integrate with external version control or infrastructure as code solutions, but we are considering [improved support](https://github.com/elastic/kibana/issues/108524). However, {{beats}} and {{agent}} in standalone mode use a YAML file that is compatible with these solutions. | +| Secret management | ![yes](images/green-check.svg "") | ![no](images/red-x.svg "") | ![no](images/red-x.svg "") | {{agent}} stores credentials in the agent policy. {{beats}} allows users to access credentials in a local [keystore](beats://reference/filebeat/keystore.md). | +| Progressive or canary deployments | ![yes](images/green-check.svg "") | ![yes](images/green-check.svg "")
{applies_to}`stack: ga 9.1.0` | ![yes](images/green-check.svg "") | To upgrade {{fleet}}-managed {{agents}} progressively, you can [configure an automatic upgrade](upgrade-elastic-agent.md#auto-upgrade-agents) in the {{agent}} policy. {applies_to}`stack: ga 9.1.0`

With standalone {{agent}} and {{beats}} you can deploy configuration files progressively using third party solutions. | +| Multiple configurations per host | ![yes](images/green-check.svg "") | ![no](images/red-x.svg "")
(uses input conditions instead) | ![no](images/red-x.svg "")
(uses input conditions instead) | {{agent}} uses a single {{agent}} policy for configuration, and uses [variables and input conditions](dynamic-input-configuration.md) to adapt on a per-host basis. {{beats}} supports multiple configuration files per host, enabling third party solutions to deploy files hierarchically or in multiple groups, and enabling finer-grained access control to those files. | +| Compatible with version control and infrastructure as code solutions | ![yes](images/green-check.svg "") | ![no](images/red-x.svg "")
(only via API) | ![yes](images/green-check.svg "") | Agent policies created in the {{fleet}} UI can't be managed with external version control or infrastructure as code solutions. However, you could develop a solution that [uses the {{fleet}} API or adds a preconfigured policy to Kibana](/reference/fleet/create-policy-no-ui.md). {{beats}} and {{agent}} in standalone mode use a YAML file that is compatible with these solutions. | | Spooling data to local disk | ![yes](images/green-check.svg "") | ![no](images/red-x.svg "") | ![no](images/red-x.svg "") | This feature is currently being [considered for development](https://github.com/elastic/elastic-agent/issues/3490). |