diff --git a/reference/fleet/add-fleet-server-kubernetes.md b/reference/fleet/add-fleet-server-kubernetes.md index 1386b96a8b..c6e9f0dcd3 100644 --- a/reference/fleet/add-fleet-server-kubernetes.md +++ b/reference/fleet/add-fleet-server-kubernetes.md @@ -138,7 +138,7 @@ A {{fleet-server}} is an {{agent}} that is enrolled in a {{fleet-server}} policy ::::{tip} If you already have a {{fleet}} policy with the {{fleet-server}} integration, you know its ID, and you know how to generate an [{{es}} service token](elasticsearch://reference/elasticsearch/command-line-tools/service-tokens-command.md) for the {{fleet-server}}, skip directly to [{{fleet-server}} installation](#add-fleet-server-kubernetes-install). -Also note that the `service token` required by the {{fleet-server}} is different from the `enrollment tokens` used by {{agent}}s to enroll to {{fleet}}. +The `service token` required by the {{fleet-server}} is different from the `enrollment tokens` used by {{agent}}s to enroll to {{fleet}}. :::: diff --git a/reference/fleet/add-fleet-server-on-prem.md b/reference/fleet/add-fleet-server-on-prem.md index eaec79e59e..ea8186d2ce 100644 --- a/reference/fleet/add-fleet-server-on-prem.md +++ b/reference/fleet/add-fleet-server-on-prem.md @@ -116,7 +116,7 @@ To add a {{fleet-server}}: If you are providing your own certificates: * Before running the `install` command, make sure you replace the values in angle brackets. - * Note that the URL specified by `--url` must match the DNS name used to generate the certificate specified by `--fleet-server-cert`. + * The URL specified by `--url` must match the DNS name used to generate the certificate specified by `--fleet-server-cert`. :::: diff --git a/reference/fleet/advanced-kubernetes-managed-by-fleet.md b/reference/fleet/advanced-kubernetes-managed-by-fleet.md index ec4ecb9352..96919fb8e1 100644 --- a/reference/fleet/advanced-kubernetes-managed-by-fleet.md +++ b/reference/fleet/advanced-kubernetes-managed-by-fleet.md @@ -83,7 +83,7 @@ containers: ``` Notes -: The is just a placeholder for the elastic-agent image version that you will download in your manifest: eg. `image: docker.elastic.co/elastic-agent/elastic-agent: 8.11.0` Important thing is to update your manifest with args details +: The is a placeholder for the elastic-agent image version that you will download in your manifest: eg. `image: docker.elastic.co/elastic-agent/elastic-agent: 8.11.0` Important thing is to update your manifest with args details ```yaml volumeMounts: diff --git a/reference/fleet/agent-command-reference.md b/reference/fleet/agent-command-reference.md index 5a76eeacd4..115c1dd032 100644 --- a/reference/fleet/agent-command-reference.md +++ b/reference/fleet/agent-command-reference.md @@ -501,7 +501,7 @@ elastic-agent privileged Install {{agent}} permanently on the system and manage it by using the system’s service manager. The agent will start automatically after installation is complete. On Linux (tar package), this command requires a system and service manager like systemd. ::::{important} -If you installed {{agent}} from a DEB or RPM package, the `install` command will skip the installation itself and function as an alias of the [`enroll` command](#elastic-agent-enroll-command) instead. Note that after an upgrade of the {{agent}} using DEB or RPM the {{agent}} service needs to be restarted. +If you installed {{agent}} from a DEB or RPM package, the `install` command will skip the installation itself and function as an alias of the [`enroll` command](#elastic-agent-enroll-command) instead. After an upgrade of the {{agent}} using DEB or RPM the {{agent}} service needs to be restarted. :::: @@ -734,7 +734,7 @@ See the `--unprivileged` option and [Run {{agent}} without administrative privil `--unprivileged` : Run {{agent}} without full superuser privileges. This option is useful in organizations that limit `root` access on Linux or macOS systems, or `admin` access on Windows systems. For details and limitations for running {{agent}} in this mode, refer to [Run {{agent}} without administrative privileges](/reference/fleet/elastic-agent-unprivileged.md). - Note that changing to `unprivileged` mode is prevented if the agent is currently enrolled in a policy that includes an integration that requires administrative access, such as the {{elastic-defend}} integration. + Changing to `unprivileged` mode is prevented if the agent is currently enrolled in a policy that includes an integration that requires administrative access, such as the {{elastic-defend}} integration. {applies_to}`stack: preview` {applies_to}`serverless: preview` To run {{agent}} without superuser privileges as a pre-existing user or group, for instance under an Active Directory account, you can specify the user or group, and the password to use. @@ -827,7 +827,7 @@ You can also run the `./otelcol` command, which calls `./elastic-agent otel` and ### Flags [_flags] `--config=file:/path/to/first --config=file:path/to/second` -: Locations to the config file(s). Note that only a single location can be set per flag entry, for example `--config=file:/path/to/first --config=file:path/to/second`. +: Locations to the config file(s). Only a single location can be set per flag entry, for example `--config=file:/path/to/first --config=file:path/to/second`. `--feature-gates flag` : Comma-delimited list of feature gate identifiers. Prefix with `-` to disable the feature. Prefixing with `+` or no prefix will enable the feature. @@ -1062,7 +1062,7 @@ elastic-agent uninstall Run {{agent}} without full superuser privileges. This is useful in organizations that limit `root` access on Linux or macOS systems, or `admin` access on Windows systems. For details and limitations for running {{agent}} in this mode, refer to [Run {{agent}} without administrative privileges](/reference/fleet/elastic-agent-unprivileged.md). -Note that changing a running {{agent}} to `unprivileged` mode is prevented if the agent is currently enrolled with a policy that contains the {{elastic-defend}} integration. +Changing a running {{agent}} to `unprivileged` mode is prevented if the agent is currently enrolled with a policy that contains the {{elastic-defend}} integration. {applies_to}`stack: preview` {applies_to}`serverless: preview` To run {{agent}} without superuser privileges as a pre-existing user or group, for instance under an Active Directory account, add either a `--user` or `--group` parameter together with a `--password` parameter. diff --git a/reference/fleet/agent-policy.md b/reference/fleet/agent-policy.md index d44f6ba6e1..4175ec471d 100644 --- a/reference/fleet/agent-policy.md +++ b/reference/fleet/agent-policy.md @@ -30,7 +30,7 @@ Within an {{agent}} policy is a set of individual integration policies. These in * Maintain flexibility in large-scale deployments by quickly testing changes before rolling them out. * Provide a way to group and manage larger swaths of your infrastructure landscape. -For example, it might make sense to create a policy per operating system type: Windows, macOS, and Linux hosts. Or, organize policies by functional groupings of how the hosts are used: IT email servers, Linux servers, user work-stations, etc. Or perhaps by user categories: engineering department, marketing department, etc. +For example, it might make sense to create a policy per operating system type: Windows, macOS, and Linux hosts. Or, organize policies by functional groupings of how the hosts are used: IT email servers, Linux servers, user work-stations, and so on. Or perhaps by user categories: engineering department, marketing department, and so on. ## Policy types [agent-policy-types] @@ -100,7 +100,7 @@ To add a new integration to one or more {{agent}} policies: 6. In Step 2 on the page, you have two options: 1. If you’d like to create a new policy for your {{agent}}s, on the **New hosts** tab specify a name for the new agent policy and choose whether or not to collect system logs and metrics. Collecting logs and metrics will add the System integration to the new agent policy. - 2. If you already have an {{agent}} policy created, on the **Existing hosts** tab use the drop-down menu to specify one or more agent policies that you’d like to add the integration to. Note that this feature, known as **reusable integration policies**, is available only for certain subscription levels. For more information, refer to [Elastic subscriptions](https://www.elastic.co/subscriptions). + 2. If you already have an {{agent}} policy created, on the **Existing hosts** tab use the drop-down menu to specify one or more agent policies that you'd like to add the integration to. This feature, known as **reusable integration policies**, is available only for certain subscription levels. For more information, refer to [Elastic subscriptions](https://www.elastic.co/subscriptions). 7. Click **Save and continue** to confirm your settings. @@ -200,7 +200,7 @@ To edit a custom field: 2. Click the **Settings** tab and scroll to **Custom fields**. Any custom fields that have been configured are shown. 3. Click the edit icon to update a field or click the delete icon to remove it. -Note that adding custom tags is not supported for a small set of inputs: +Adding custom tags is not supported for a small set of inputs: * `apm` * `cloudbeat` and all `cloudbeat/*` inputs diff --git a/reference/fleet/agent-processors.md b/reference/fleet/agent-processors.md index d562ee3fa1..5206407075 100644 --- a/reference/fleet/agent-processors.md +++ b/reference/fleet/agent-processors.md @@ -86,7 +86,7 @@ Processors have the following limitations. * Cannot enrich events with data from {{es}} or other custom data sources. * Cannot process data after it’s been converted to the Elastic Common Schema (ECS) because the conversion is performed by {{es}} ingest pipelines. This means that your processor configuration cannot refer to fields that are created by ingest pipelines or {{ls}} because those fields are created *after* the processor runs, not before. * May break integration ingest pipelines in {{es}} if the user-defined processing removes or alters fields expected by ingest pipelines. -* If you create new fields via processors, you are responsible for setting up field mappings in the `*-@custom` component template and making sure the new mappings are aligned with ECS. +* If you create new fields using processors, you are responsible for setting up field mappings in the `*-@custom` component template and making sure the new mappings are aligned with ECS. ## What other options are available for processing data? [processing-options] diff --git a/reference/fleet/air-gapped.md b/reference/fleet/air-gapped.md index ecf4ab640f..6e0f7c72aa 100644 --- a/reference/fleet/air-gapped.md +++ b/reference/fleet/air-gapped.md @@ -13,9 +13,9 @@ When running {{agent}}s in a restricted or closed network, you need to take extr * {{kib}} is able to reach the {{package-registry}} to download package metadata and content. * {{agent}}s are able to download binaries during upgrades from the {{artifact-registry}}. -The {{package-registry}} must therefore be accessible from {{kib}} via an HTTP Proxy and/or self-hosted. +The {{package-registry}} must therefore be accessible from {{kib}} through an HTTP Proxy or self-hosted. -The {{artifact-registry}} must therefore be accessible from {{kib}} via an HTTP Proxy and/or self-hosted. +The {{artifact-registry}} must therefore be accessible from {{kib}} through an HTTP Proxy or self-hosted. ::::{tip} See the {{elastic-sec}} Solution documentation for air-gapped [offline endpoints](/solutions/security/configure-elastic-defend/configure-offline-endpoints-air-gapped-environments.md). @@ -110,8 +110,8 @@ There are different distributions available: * {{version.stack}} (recommended): *docker.elastic.co/package-registry/distribution:{{version.stack}}* - Selection of packages from the production repository released with {{stack}} {{version.stack}}. * lite-{{version.stack}}: *docker.elastic.co/package-registry/distribution:lite-{{version.stack}}* - Subset of the most commonly used packages from the production repository released with {{stack}} {{version.stack}}. This image is a good candidate to start using {{fleet}} in air-gapped environments. -* production: *docker.elastic.co/package-registry/distribution:production* - Packages available in the production registry ([https://epr.elastic.co](https://epr.elastic.co)). Note that this image is updated every time a new version of a package gets published. -* lite: *docker.elastic.co/package-registry/distribution:lite* - Subset of the most commonly used packages available in the production registry ([https://epr.elastic.co](https://epr.elastic.co)). Note that this image is updated every time a new version of a package gets published. +* production: *docker.elastic.co/package-registry/distribution:production* - Packages available in the production registry ([https://epr.elastic.co](https://epr.elastic.co)). This image is updated every time a new version of a package gets published. +* lite: *docker.elastic.co/package-registry/distribution:lite* - Subset of the most commonly used packages available in the production registry ([https://epr.elastic.co](https://epr.elastic.co)). This image is updated every time a new version of a package gets published. To update the distribution image, re-pull the image and then restart the docker container. diff --git a/reference/fleet/automatic-integrations-synchronization.md b/reference/fleet/automatic-integrations-synchronization.md index 8df1c631f1..d2dfdf2be5 100644 --- a/reference/fleet/automatic-integrations-synchronization.md +++ b/reference/fleet/automatic-integrations-synchronization.md @@ -147,7 +147,7 @@ If the integration syncing reports connection errors or fails to report the sync 2. In the **Outputs** section, check that the remote {{es}} output is healthy. In particular, check that the remote {{es}} output's host URL matches the host URL of an {{es}} output on the remote cluster. 3. Edit the remote {{es}} output, and check if the remote {{kib}} URL is correct, as well as the validity and privileges of the remote {{kib}} API key. - Note that an incorrect value in either of these fields does not cause the output to become unhealthy, but it affects the integration synchronization. + An incorrect value in either of these fields does not cause the output to become unhealthy, but it affects the integration synchronization. :::: ### Integrations are not installed on the remote cluster diff --git a/reference/fleet/beats-agent-comparison.md b/reference/fleet/beats-agent-comparison.md index 4f9e7b49fb..90a773459f 100644 --- a/reference/fleet/beats-agent-comparison.md +++ b/reference/fleet/beats-agent-comparison.md @@ -16,7 +16,7 @@ Elastic provides two main ways to send data to {{es}}: 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}}. +{{beats}} and {{agent}} can both send data directly to {{es}} or through {{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). @@ -66,11 +66,11 @@ The following table shows the outputs supported by the {{agent}} in 9.0.0-beta1: | {{beats}} configuration | {{agent}} support | | --- | --- | -| [Modules](beats://reference/filebeat/configuration-filebeat-modules.md) | Supported via integrations. | +| [Modules](beats://reference/filebeat/configuration-filebeat-modules.md) | Supported through 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 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. | +| [External configuration file loading](beats://reference/filebeat/filebeat-configuration-reloading.md) | Config is distributed through 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 | @@ -95,7 +95,7 @@ The following table shows a comparison of capabilities supported by {{beats}} an | --- |:---:|:---:|:---:| --- | | 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 through 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. | @@ -111,7 +111,7 @@ The following table shows a comparison of capabilities supported by {{beats}} an | 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. | +| Compatible with version control and infrastructure as code solutions | ![yes](images/green-check.svg "") | ![no](images/red-x.svg "")
(only using 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). | diff --git a/reference/fleet/certificates-rotation.md b/reference/fleet/certificates-rotation.md index b9f40ee5c1..9fe8dc0467 100644 --- a/reference/fleet/certificates-rotation.md +++ b/reference/fleet/certificates-rotation.md @@ -59,7 +59,7 @@ Using this method, the {{agent}} with an old or expiring CA configured will be r The new CA (`new_CA`) on the agent installed in Step 1 will be used to authenticate the certificates used by {{fleet-server}}. - Note that if the original CA (`original CA`) was compromised, then it may need to be removed from the agent’s CA list. To achieve this you need to enroll the agent again: + If the original CA (`original CA`) was compromised, then it may need to be removed from the agent's CA list. To achieve this you need to enroll the agent again: ```shell elastic-agent enroll ... @@ -107,7 +107,7 @@ To update the {{agent}} and {{fleet-server}} configurations: cat new_ca.pem >> CA.pem ``` -2. Restart the {{agents}}. Note that this is not a re-enrollment. Restarting will force the {{agents}} to reload the CAs. +2. Restart the {{agents}}. This is not a re-enrollment–restarting will force the {{agents}} to reload the CAs. ```shell elastic-agent restart @@ -167,7 +167,7 @@ To rotate a CA certificate on {{es}} for connections from {{fleet-server}}: {{es}} will use new certificates based on the new {{es}} CA. Since the {{fleet-server}} has the original and the new {{es}} CAs in a chain, it will accept original and new certificates from {{es}}. - Note that if the original {{es}} CA (`original_ES CA`) was compromised, then it may need to be removed from the {{fleet-server}}'s CA list. To achieve this you need to enroll the {{fleet-server}} agent again (if re-enrollment is a concern then use a file to hold the certificates and certificate-authority): + If the original {{es}} CA (`original_ES CA`) was compromised, then it may need to be removed from the {{fleet-server}}'s CA list. To achieve this you need to enroll the {{fleet-server}} agent again (if re-enrollment is a concern then use a file to hold the certificates and certificate-authority): ```shell elastic-agent enroll \ diff --git a/reference/fleet/configuring-kubernetes-metadata.md b/reference/fleet/configuring-kubernetes-metadata.md index 637823f6fc..b1973a538b 100644 --- a/reference/fleet/configuring-kubernetes-metadata.md +++ b/reference/fleet/configuring-kubernetes-metadata.md @@ -20,7 +20,7 @@ In case the {{agent}}'s policy does not include the Kubernetes integration, but ## Kubernetes Logs [_kubernetes_logs] -When it comes to container logs collection, the [Kubernetes Provider](/reference/fleet/kubernetes-provider.md) is used. It monitors for pod resources in the cluster and associates each container log file with a corresponding pod’s container object. That way, when a log file is parsed and an event is ready to be published to {{es}}, the internal mechanism knows to which actual container this log file belongs. The linkage is established by the container’s ID, which forms an integral part of the filename for the log. The Kubernetes autodiscover provider has already collected all the metadata for that container, leveraging pod, namespace and node watchers. Thus, the events are enriched with the relevant metadata. +When it comes to container logs collection, the [Kubernetes Provider](/reference/fleet/kubernetes-provider.md) is used. It monitors for pod resources in the cluster and associates each container log file with a corresponding pod's container object. That way, when a log file is parsed and an event is ready to be published to {{es}}, the internal mechanism knows to which actual container this log file belongs. The linkage is established by the container's ID, which forms an integral part of the filename for the log. The Kubernetes autodiscover provider has already collected all the metadata for that container, leveraging pod, namespace and node watchers. As a result, the events are enriched with the relevant metadata. In order to configure the metadata collection, the Kubernetes provider needs to be configured. All the available configuration options of the **Kubernetes provider** can be found in the [Kubernetes Provider](/reference/fleet/kubernetes-provider.md) documentation. @@ -62,7 +62,7 @@ The Kubernetes provider can be configured following the steps in [Advanced {{age ## Kubernetes metrics [_kubernetes_metrics] -The {{agent}} metrics collection implements metadata enrichment based on watchers, a mechanism used to continuously monitor Kubernetes resources for changes and updates. Specifically, the different datasets share a set of resource watchers. Those watchers (pod, node, namespace, deployment, daemonset etc.) are responsible for watching for all different resource events (creation, update and deletion) by subscribing to the Kubernetes watch API. This enables real-time synchronization of application state with the state of the Kubernetes cluster. So, they keep an up-to-date shared cache store of all the resources' information and metadata. Whenever metrics are collected by the different sources (kubelet, kube-state-metrics), before they get published to {{es}} as events, they are enriched with needed metadata. +The {{agent}} metrics collection implements metadata enrichment based on watchers, a mechanism used to continuously monitor Kubernetes resources for changes and updates. Specifically, the different datasets share a set of resource watchers. Those watchers (pod, node, namespace, deployment, daemonset, and so on) are responsible for watching for all different resource events (creation, update and deletion) by subscribing to the Kubernetes watch API. This enables real-time synchronization of application state with the state of the Kubernetes cluster. So, they keep an up-to-date shared cache store of all the resources' information and metadata. Whenever metrics are collected by the different sources (kubelet, kube-state-metrics), before they get published to {{es}} as events, they are enriched with needed metadata. The metadata enrichment can be configured by editing the Kubernetes integration. **Only in metrics collection**, metadata enrichment can be disabled by switching off the `Add Metadata` toggle in every dataset. Extra resource metadata such as node, namespace labels and annotations, as well as deployment and cronjob information can be configured per dataset. diff --git a/reference/fleet/data-streams-advanced-features.md b/reference/fleet/data-streams-advanced-features.md index e32cc577ee..a4e5456ed9 100644 --- a/reference/fleet/data-streams-advanced-features.md +++ b/reference/fleet/data-streams-advanced-features.md @@ -15,7 +15,7 @@ products: * [Time series data streams (TSDS)](/manage-data/data-store/data-streams/time-series-data-stream-tsds.md) * [Synthetic `_source`](elasticsearch://reference/elasticsearch/mapping-reference/mapping-source-field.md#synthetic-source) -These features can be enabled and disabled for {{fleet}}-managed data streams by using the index template API and a few key settings. Note that in versions 8.17.0 and later, synthetic `_source` is available only for certain [Elastic subscription levels](https://www.elastic.co/subscriptions). +These features can be enabled and disabled for {{fleet}}-managed data streams by using the index template API and a few key settings. In versions 8.17.0 and later, synthetic `_source` is available only for certain [Elastic subscription levels](https://www.elastic.co/subscriptions). ::::{note} If you are already making use of `@custom` component templates for ingest or retention customization (as shown for example in [Tutorial: Customize data retention policies](/reference/fleet/data-streams-ilm-tutorial.md)), exercise care to ensure you don’t overwrite your customizations when making these requests. diff --git a/reference/fleet/decode-json-fields.md b/reference/fleet/decode-json-fields.md index e2b2defc08..dea7bb13bb 100644 --- a/reference/fleet/decode-json-fields.md +++ b/reference/fleet/decode-json-fields.md @@ -38,7 +38,7 @@ The `decode_json_fields` processor decodes fields containing JSON strings and re | `fields` | Yes | | Fields containing JSON strings to decode. | | `process_array` | No | `false` | Whether to process arrays. | | `max_depth` | No | `1` | Maximum parsing depth. A value of `1` decodes the JSON objects in fields indicated in `fields`. A value of `2` also decodes the objects embedded in the fields of these parsed documents. | -| `target` | No | | Field under which the decoded JSON will be written. By default, the decoded JSON object replaces the string field from which it was read. To merge the decoded JSON fields into the root of the event, specify `target` with an empty string (`target: ""`). Note that the `null` value (`target:`) is treated as if the field was not set. | +| `target` | No | | Field under which the decoded JSON will be written. By default, the decoded JSON object replaces the string field from which it was read. To merge the decoded JSON fields into the root of the event, specify `target` with an empty string (`target: ""`). The `null` value (`target:`) is treated as if the field was not set. | | `overwrite_keys` | No | `false` | Whether existing keys in the event are overwritten by keys from the decoded JSON object. | | `expand_keys` | No | | Whether keys in the decoded JSON should be recursively de-dotted and expanded into a hierarchical object structure. For example, `{"a.b.c": 123}` would be expanded into `{"a":{"b":{"c":123}}}`. | | `add_error_key` | No | `false` | If `true` and an error occurs while decoding JSON keys, the `error` field will become a part of the event with the error message. If `false`, there will not be any error in the event’s field. | diff --git a/reference/fleet/decode_xml-processor.md b/reference/fleet/decode_xml-processor.md index 61d4241d1a..b1fe4a3124 100644 --- a/reference/fleet/decode_xml-processor.md +++ b/reference/fleet/decode_xml-processor.md @@ -83,7 +83,7 @@ Will produce the following output: | Name | Required | Default | Description | | --- | --- | --- | --- | | `field` | Yes | `message` | Source field containing the XML. | -| `target_field` | No | | The field under which the decoded XML will be written. By default the decoded XML object replaces the field from which it was read. To merge the decoded XML fields into the root of the event, specify `target_field` with an empty string (`target_field: ""`). Note that the `null` value (`target_field:`) is treated as if the field was not set at all. | +| `target_field` | No | | The field under which the decoded XML will be written. By default the decoded XML object replaces the field from which it was read. To merge the decoded XML fields into the root of the event, specify `target_field` with an empty string (`target_field: ""`). The `null` value (`target_field:`) is treated as if the field was not set at all. | | `overwrite_keys` | No | `true` | Whether keys that already exist in the event are overwritten by keys from the decoded XML object. | | `to_lower` | No | `true` | Whether to convert all keys to lowercase. | | `document_id` | No | | XML key to use as the document ID. If configured, the field will be removed from the original XML document and stored in `@metadata._id`. | diff --git a/reference/fleet/decode_xml_wineventlog-processor.md b/reference/fleet/decode_xml_wineventlog-processor.md index 068ac5d3ad..a8758e5fa1 100644 --- a/reference/fleet/decode_xml_wineventlog-processor.md +++ b/reference/fleet/decode_xml_wineventlog-processor.md @@ -101,7 +101,7 @@ See [Conditions](/reference/fleet/dynamic-input-configuration.md#conditions) for | `field` | Yes | `message` | Source field containing the XML. | | `target_field` | Yes | `winlog` | The field under which the decoded XML will be written. To merge the decoded XML fields into the root of the event, specify `target_field` with an empty string (`target_field: ""`). | | `overwrite_keys` | No | `true` | Whether keys that already exist in the event are overwritten by keys from the decoded XML object. | -| `map_ecs_fields` | No | `true` | Whether to map additional ECS fields when possible. Note that ECS field keys are placed outside of `target_field`. | +| `map_ecs_fields` | No | `true` | Whether to map additional ECS fields when possible. ECS field keys are placed outside of `target_field`. | | `ignore_missing` | No | `false` | Whether to return an error if a specified field does not exist. | | `ignore_failure` | No | `false` | Whether to ignore all errors produced by the processor. | diff --git a/reference/fleet/elastic-agent-container.md b/reference/fleet/elastic-agent-container.md index fd37fd8ddb..0c4eed8ec0 100644 --- a/reference/fleet/elastic-agent-container.md +++ b/reference/fleet/elastic-agent-container.md @@ -10,7 +10,7 @@ products: You can run {{agent}} inside a container — either with {{fleet-server}} or standalone. Docker images for all versions of {{agent}} are available from the [Elastic Docker registry](https://www.docker.elastic.co/r/elastic-agent/elastic-agent). If you are running in Kubernetes, refer to [run {{agent}} on ECK](/deploy-manage/deploy/cloud-on-k8s/standalone-elastic-agent.md). -Note that running {{elastic-agent}} in a container is supported only in Linux environments. For this reason we don’t currently provide {{agent}} container images for Windows. +Running {{elastic-agent}} in a container is supported only in Linux environments. For this reason we don't currently provide {{agent}} container images for Windows. In version 9.0.0, the default Ubuntu-based Docker images used for {{agent}} have been changed to Red Hat UBI (Universal Base Image) minimal based images, to reduce the overall footprint of the agent Docker images and to improve compliance with enterprise standards. Refer to [#6427]({{agent-pull}}6427) for details. diff --git a/reference/fleet/elastic-agent-inputs-list.md b/reference/fleet/elastic-agent-inputs-list.md index ac26e70dbd..01ed71ed28 100644 --- a/reference/fleet/elastic-agent-inputs-list.md +++ b/reference/fleet/elastic-agent-inputs-list.md @@ -19,7 +19,7 @@ When you [configure inputs](/reference/fleet/elastic-agent-input-configuration.m | --- | --- | --- | | `audit/auditd` | Receives audit events from the Linux Audit Framework that is a part of the Linux kernel. | [Auditd Module](beats://reference/auditbeat/auditbeat-module-auditd.md) ({{auditbeat}} docs) | | `audit/file_integrity` | Sends events when a file is changed (created, updated, or deleted) on disk. The events contain file metadata and hashes. | [File Integrity Module](beats://reference/auditbeat/auditbeat-module-file_integrity.md) ({{auditbeat}} docs) | -| `audit/system` | {applies_to}`stack: beta` {applies_to}`serverless: beta` Collects various security related information about a system. All datasets send both periodic state information (e.g. all currently running processes) and real-time changes (e.g. when a new process starts or stops). | [System Module](beats://reference/auditbeat/auditbeat-module-system.md) ({{auditbeat}} docs) | +| `audit/system` | {applies_to}`stack: beta` {applies_to}`serverless: beta` Collects various security related information about a system. All datasets send both periodic state information (for example, all currently running processes) and real-time changes (for example, when a new process starts or stops). | [System Module](beats://reference/auditbeat/auditbeat-module-system.md) ({{auditbeat}} docs) | :::: diff --git a/reference/fleet/elastic-agent-ssl-configuration.md b/reference/fleet/elastic-agent-ssl-configuration.md index b9be9b7b73..89c3498505 100644 --- a/reference/fleet/elastic-agent-ssl-configuration.md +++ b/reference/fleet/elastic-agent-ssl-configuration.md @@ -33,7 +33,7 @@ $$$common-ssl-options$$$ `ssl.cipher_suites` $$$ssl.cipher_suites-common-setting$$$ -: (list) The list of cipher suites to use. The first entry has the highest priority. If this option is omitted, the Go crypto library’s [default suites](https://golang.org/pkg/crypto/tls/) are used (recommended). Note that TLS 1.3 cipher suites are not individually configurable in Go, so they are not included in this list. +: (list) The list of cipher suites to use. The first entry has the highest priority. If this option is omitted, the Go crypto library's [default suites](https://golang.org/pkg/crypto/tls/) are used (recommended). TLS 1.3 cipher suites are not individually configurable in Go, so they are not included in this list. The following cipher suites are available: diff --git a/reference/fleet/elastic-agent-unprivileged.md b/reference/fleet/elastic-agent-unprivileged.md index 3885fb4a14..0cfc2febf2 100644 --- a/reference/fleet/elastic-agent-unprivileged.md +++ b/reference/fleet/elastic-agent-unprivileged.md @@ -8,7 +8,7 @@ products: # Run Elastic Agent without administrative privileges [elastic-agent-unprivileged] -Beginning with {{stack}} version 8.15, {{agent}} is no longer required to be run by a user with superuser privileges. You can now run agents in an `unprivileged` mode that does not require `root` access on Linux or macOS, or `admin` access on Windows. Being able to run agents without full administrative privileges is often a requirement in organizations where this kind of access is often very limited. +Beginning with {{stack}} version 8.15, {{agent}} is no longer required to be run by a user with superuser privileges. You can now run agents in an `unprivileged` mode that does not require `root` access on Linux or macOS, or `admin` access on Windows. Being able to run agents without full administrative privileges is often a requirement in organizations where this kind of access is often limited. In general, agents running without full administrative privileges will perform and behave exactly as those run by a superuser. There are certain integrations and datastreams that are not available, however. If an integration requires root access, this is [indicated on the integration main page](#unprivileged-integrations). @@ -65,15 +65,15 @@ In addition to the [integrations that are not available](#unprivileged-integrati | --- | --- | --- | | Run {{agent}} with the System integration | Log file error: `Unexpected file opening error: Failed opening /var/log/system.log: open /var/log/system.log: permission denied`. | Give read permission to the `elastic-agent` group for the `/var/log/system.log` file to fix this error. | | Run {{agent}} with the System integration | On the `[Logs System] Syslog` dashboard, the `Syslog events by hostname`, `Syslog hostnames and processes` and `Syslog logs` visualizations are are missing data. | Give read permission to the `elastic-agent` group for the `/var/log/system.log` file to fix the missing visualizations. | -| Run {{agent}} with the System integration | On the `[Metrics System] Host overview` dashboard, only the processes run by the `elastic-agent-user` user are shown in the CPU and memory usage lists. | To fix the missing processes in the visualization lists you can add add the `elastic-agent-user` user to the system `admin` group. Note that while this mitigates the issue, it also grants `elastic-agent user` with more permissions than may be desired. | -| Run {{agent}} and access the {{agent}} dashboards | On the `[Elastic Agent] Agents info` dashboard, visualizations including `Most Active Agents` and `Integrations per Agent` are missing data. | To fix the missing data in the visualizations you can add add the `elastic-agent-user` user to the system `admin` group. Note that while this mitigates the issue it also grants `elastic-agent user` with more permissions than may be desired. | -| Run {{agent}} and access the {{agent}} dashboards | On the `[Elastic Agent] Integrations` dashboard, visualizations including `Integration Errors Table`, `Events per integration` and `Integration Errors` are missing data. | To fix the missing data in the visualizations you can add add the `elastic-agent-user` user to the system `admin` group. Note that while this mitigates the issue it also grants `elastic-agent user` with more permissions than may be desired. | +| Run {{agent}} with the System integration | On the `[Metrics System] Host overview` dashboard, only the processes run by the `elastic-agent-user` user are shown in the CPU and memory usage lists. | To fix the missing processes in the visualization lists you can add add the `elastic-agent-user` user to the system `admin` group. While this mitigates the issue, it also grants `elastic-agent user` with more permissions than may be desired. | +| Run {{agent}} and access the {{agent}} dashboards | On the `[Elastic Agent] Agents info` dashboard, visualizations including `Most Active Agents` and `Integrations per Agent` are missing data. | To fix the missing data in the visualizations you can add add the `elastic-agent-user` user to the system `admin` group. While this mitigates the issue it also grants `elastic-agent user` with more permissions than may be desired. | +| Run {{agent}} and access the {{agent}} dashboards | On the `[Elastic Agent] Integrations` dashboard, visualizations including `Integration Errors Table`, `Events per integration` and `Integration Errors` are missing data. | To fix the missing data in the visualizations you can add add the `elastic-agent-user` user to the system `admin` group. While this mitigates the issue it also grants `elastic-agent user` with more permissions than may be desired. | | Action | Behavior in unprivileged mode | Resolution | | --- | --- | --- | -| Run {{agent}} with the System integration | Log file error: `[elastic_agent.filebeat][error] Harvester could not be started on new file: /var/log/auth.log.1, Err: error setting up harvester: Harvester setup failed. Unexpected file opening error: Failed opening /var/log/auth.log.1: open /var/log/auth.log.1: permission denied` | To avoid the error you can add add the `elastic-agent-user` user to the `adm` group. Note that while this mitigates the issue it also grants `elastic-agent user` with more permissions than may be desired. | -| Run {{agent}} with the System integration | Log file error: `[elastic_agent.metricbeat][error] error getting filesystem usage for /run/user/1000/gvfs: error in Statfs syscall: permission denied` | To avoid the error you can add add the `elastic-agent-user` user to the `adm` group. Note that while this mitigates the issue it also grants `elastic-agent user` with more permissions than may be desired. | -| Run {{agent}} with the System integration | On the `[Logs System] Syslog` dashboard, the `Syslog events by hostname`, `Syslog hostnames and processes` and `Syslog logs` visualizations are are missing data. | To fix the missing data in the visualizations you can add add the `elastic-agent-user` user to the `adm` group. Note that while this mitigates the issue it also grants `elastic-agent user` with more permissions than may be desired. | +| Run {{agent}} with the System integration | Log file error: `[elastic_agent.filebeat][error] Harvester could not be started on new file: /var/log/auth.log.1, Err: error setting up harvester: Harvester setup failed. Unexpected file opening error: Failed opening /var/log/auth.log.1: open /var/log/auth.log.1: permission denied` | To avoid the error you can add add the `elastic-agent-user` user to the `adm` group. While this mitigates the issue it also grants `elastic-agent user` with more permissions than may be desired. | +| Run {{agent}} with the System integration | Log file error: `[elastic_agent.metricbeat][error] error getting filesystem usage for /run/user/1000/gvfs: error in Statfs syscall: permission denied` | To avoid the error you can add add the `elastic-agent-user` user to the `adm` group. While this mitigates the issue it also grants `elastic-agent user` with more permissions than may be desired. | +| Run {{agent}} with the System integration | On the `[Logs System] Syslog` dashboard, the `Syslog events by hostname`, `Syslog hostnames and processes` and `Syslog logs` visualizations are are missing data. | To fix the missing data in the visualizations you can add add the `elastic-agent-user` user to the `adm` group. While this mitigates the issue it also grants `elastic-agent user` with more permissions than may be desired. | | Run {{agent}} and access the {{agent}} dashboards | On the `[Elastic Agent] Agents info` dashboard, visualizations including `Most Active Agents` and `Integrations per Agent` are missing data. | Giving read permission to the `elastic-agent` group for the `/var/log/system.log` file will partially fix the visualizations, but errors may still occur because the `elastic-agent-user` does not have read access to files in the `/run/user/1000/` directory. | | Run {{agent}} and access the {{agent}} dashboards | On the `[Elastic Agent] Integrations` dashboard, visualizations including `Integration Errors Table`, `Events per integration` and `Integration Errors` are missing data. | Give read permission to the `elastic-agent` group for the `/var/log/system.log` file to fix the missing visualizations. | @@ -81,7 +81,7 @@ In addition to the [integrations that are not available](#unprivileged-integrati | --- | --- | --- | | Run {{agent}} with the System integration | Log file error: `failed to open Windows Event Log channel "Security": Access is denied` | Add the `elastic-agent-user` user to the `Event Log Users` group to fix this error. | | Run {{agent}} with the System integration | Log file error: `cannot open new key in the registry in order to enable the performance counters: Access is denied` | Update the permissions for the `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PartMgr` registry to fix this error. | -| Run {{agent}} with the System integration | Most of the System and {{agent}} dashboard visualizations are missing all data. | Add the `elastic-agent-user` user to the `Event Log Users` group and update the permissions for the `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PartMgr` registry to fix the missing visualizations.
Note that the `elastic-agent-user` user may still not have access to all processes, so the lists in the `Top processes by CPU usage` and `Top processes by memory usage` visualizations may be incomplete. | +| Run {{agent}} with the System integration | Most of the System and {{agent}} dashboard visualizations are missing all data. | Add the `elastic-agent-user` user to the `Event Log Users` group and update the permissions for the `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PartMgr` registry to fix the missing visualizations.
The `elastic-agent-user` user may still not have access to all processes, so the lists in the `Top processes by CPU usage` and `Top processes by memory usage` visualizations may be incomplete. | | Run {{agent}} with the System integration | On the `[Metrics System] Host overview` dashboard, the `Disk usage` visualizations are missing data. | This occurs because direct access to the disk or a volume is restricted and not available to users without administrative privileges. Refer to [Running with Special Privileges](https://learn.microsoft.com/en-us/windows/win32/secbp/running-with-special-privileges) in the Microsoft documentation for details. | @@ -157,7 +157,7 @@ Change mode from privileged to unprivileged: sudo elastic-agent unprivileged ``` -Note that changing to `unprivileged` mode is prevented if the agent is currently enrolled in a policy that includes an integration that requires administrative access, such as the {{elastic-defend}} integration. +Changing to `unprivileged` mode is prevented if the agent is currently enrolled in a policy that includes an integration that requires administrative access, such as the {{elastic-defend}} integration. Change mode from unprivileged to privileged: diff --git a/reference/fleet/enrollment-handling-containerized-agent.md b/reference/fleet/enrollment-handling-containerized-agent.md index cdbd40e56d..6d9e7a8b06 100644 --- a/reference/fleet/enrollment-handling-containerized-agent.md +++ b/reference/fleet/enrollment-handling-containerized-agent.md @@ -3,7 +3,7 @@ For {{fleet}}-managed {{agents}} that run in a containerized environment (including Docker, Kubernetes, and others), enrollment handling is managed as follows: * **Enrollment Verification:** {{agent}} checks the stored enrollment conditions within its container environment and re-enrolls only when necessary. -* **Unenrollment Handling:** If an {{agent}} is unenrolled via the {{fleet}} UI but still references a valid enrollment token provided through environment variables, it will automatically re-enroll on the next container restart. +* **Unenrollment Handling:** If an {{agent}} is unenrolled through the {{fleet}} UI but still references a valid enrollment token provided through environment variables, it will automatically re-enroll on the next container restart. In versions lower than 8.18, an unenrolled agent remains unenrolled and does not re-enroll, even if a valid enrollment token is still available. diff --git a/reference/fleet/es-output-settings.md b/reference/fleet/es-output-settings.md index 774ffc7003..2fa2451afe 100644 --- a/reference/fleet/es-output-settings.md +++ b/reference/fleet/es-output-settings.md @@ -75,7 +75,7 @@ Specify these settings to send data over a secure connection to {{es}}. In the { `allow_older_versions` $$$output-elasticsearch-fleet-settings-allow_older_versions-setting$$$ : Allow {{agent}} to connect and send output to an {{es}} instance that is running an earlier version than the agent version. - Note that this setting does not affect {{agent}}'s ability to connect to {{fleet-server}}. {{fleet-server}} will not accept a connection from an agent at a later major or minor version. It will accept a connection from an agent at a later patch version. For example, an {{agent}} at version 8.14.3 can connect to a {{fleet-server}} on version 8.14.0, but an agent at version 8.15.0 or later is not able to connect. + This setting does not affect {{agent}}'s ability to connect to {{fleet-server}}. {{fleet-server}} will not accept a connection from an agent at a later major or minor version. It will accept a connection from an agent at a later patch version. For example, an {{agent}} at version 8.14.3 can connect to a {{fleet-server}} on version 8.14.0, but an agent at version 8.15.0 or later is not able to connect. **Default:** `true` diff --git a/reference/fleet/example-kubernetes-fleet-managed-agent-helm.md b/reference/fleet/example-kubernetes-fleet-managed-agent-helm.md index 8bda3e54e2..7345508b2f 100644 --- a/reference/fleet/example-kubernetes-fleet-managed-agent-helm.md +++ b/reference/fleet/example-kubernetes-fleet-managed-agent-helm.md @@ -110,7 +110,7 @@ This can be easily implemented with the Helm chart. For details, refer to the [K * `--version `: Installs a specific version of the Helm chart and {{agent}}. Refer to [Preparations](#preparations) to check available versions. * `--set agent.version=`: Installs a specific version of {{agent}}. By default, the chart installs the agent version that matches its own. * `--set-file agent.fleet.ca.value=/local-path/to/fleet-ca.crt`: Provides the CA certificate used by the {{fleet}} Server. This is typically needed when the server uses a certificate signed by a private CA. Not required for {{fleet}} Servers running on {{ecloud}}. - * `--set agent.fleet.insecure=true`: Use this option to skip the {{fleet}} certificate verification if your {{fleet}} Server uses a self-signed certificate, such as when installed in quickstart mode. Not required for {{fleet}} Servers running on {{ecloud}}. Note that this option is not recommended for production environments. + * `--set agent.fleet.insecure=true`: Use this option to skip the {{fleet}} certificate verification if your {{fleet}} Server uses a self-signed certificate, such as when installed in quickstart mode. Not required for {{fleet}} Servers running on {{ecloud}}. This option is not recommended for production environments. * `--set kube-state-metrics.enabled=false`: In case you already have KSM installed in your cluster, and you don't want to install a second instance. * `--set kube-state-metrics.fullnameOverride=ksm`: If you want to deploy KSM with a different release name (it defaults to `kube-state-metrics`). This can be useful if you have already a default installation of KSM and you want a second one. :::: diff --git a/reference/fleet/example-kubernetes-standalone-agent-helm.md b/reference/fleet/example-kubernetes-standalone-agent-helm.md index fe4c87436e..a42d79f688 100644 --- a/reference/fleet/example-kubernetes-standalone-agent-helm.md +++ b/reference/fleet/example-kubernetes-standalone-agent-helm.md @@ -292,7 +292,7 @@ By default {{agent}} runs under the `elastic` user account. For some use cases y elastic+ 543 0.0 0.0 5480 2360 pts/0 R+ 22:47 0:00 ps aux ``` -4. In the command output, note that {{agent}} is currently running as the `elastic` user: +4. In the command output, {{agent}} is currently running as the `elastic` user: ```sh elastic+ 10 0.2 1.3 2555252 132804 ? Sl 21:04 0:13 elastic-agent container -c /etc/elastic-agent/agent.yml -e diff --git a/reference/fleet/example-standalone-monitor-nginx-serverless.md b/reference/fleet/example-standalone-monitor-nginx-serverless.md index f9fd04bbdd..9f49de8de3 100644 --- a/reference/fleet/example-standalone-monitor-nginx-serverless.md +++ b/reference/fleet/example-standalone-monitor-nginx-serverless.md @@ -115,7 +115,7 @@ Elastic integrations are a streamlined way to connect your data from popular ser :alt: The nginx-policy UI with integrations tab selected ::: -2. Note that the System integration (`system-1`) is included because you opted earlier to collect system logs and metrics. +2. The System integration (`system-1`) is included because you opted earlier to collect system logs and metrics. 3. Click **Add integration**. 4. On the Integrations page search for "nginx". @@ -156,7 +156,7 @@ Rather than opt for {{fleet}} to centrally manage {{agent}}, you’ll configure 4. For the **Configure the agent** step, choose **Download Policy**. Save the `elastic-agent.yml` file to a directory on the host where you’ll install nginx for monitoring. - Have a look inside the policy file and notice that it contains all of the input, output, and other settings for the Nginx and System integrations. If you already have a standalone agent installed on a host with an existing {{agent}} policy, you can use the method described here to add a new integration. Just add the settings from the **Configure the agent** step to your existing `elastic-agent.yml` file. + Have a look inside the policy file and notice that it contains all of the input, output, and other settings for the Nginx and System integrations. If you already have a standalone agent installed on a host with an existing {{agent}} policy, you can use the method described here to add a new integration. Add the settings from the **Configure the agent** step to your existing `elastic-agent.yml` file. 5. For the **Install {{agent}} on your host** step, select the tab for your host operating system and run the commands on your host. diff --git a/reference/fleet/example-standalone-monitor-nginx.md b/reference/fleet/example-standalone-monitor-nginx.md index 493a81d908..33996c31ce 100644 --- a/reference/fleet/example-standalone-monitor-nginx.md +++ b/reference/fleet/example-standalone-monitor-nginx.md @@ -114,7 +114,7 @@ Elastic integrations are a streamlined way to connect your data from popular ser :alt: The nginx-policy UI with integrations tab selected ::: -2. Note that the System integration (`system-1`) is included because you opted earlier to collect system logs and metrics. +2. The System integration (`system-1`) is included because you opted earlier to collect system logs and metrics. 3. Click **Add integration**. 4. On the Integrations page search for "nginx". @@ -155,7 +155,7 @@ Rather than opt for {{fleet}} to centrally manage {{agent}}, you’ll configure 4. For the **Configure the agent** step, choose **Download Policy**. Save the `elastic-agent.yml` file to a directory on the host where you’ll install nginx for monitoring. - Have a look inside the policy file and notice that it contains all of the input, output, and other settings for the Nginx and System integrations. If you already have a standalone agent installed on a host with an existing {{agent}} policy, you can use the method described here to add a new integration. Just add the settings from the **Configure the agent** step to your existing `elastic-agent.yml` file. + Have a look inside the policy file and notice that it contains all of the input, output, and other settings for the Nginx and System integrations. If you already have a standalone agent installed on a host with an existing {{agent}} policy, you can use the method described here to add a new integration. Add the settings from the **Configure the agent** step to your existing `elastic-agent.yml` file. 5. For the **Install {{agent}} on your host** step, select the tab for your host operating system and run the commands on your host. diff --git a/reference/fleet/filter-agent-list-by-tags.md b/reference/fleet/filter-agent-list-by-tags.md index 38972fc156..2f86ecbde3 100644 --- a/reference/fleet/filter-agent-list-by-tags.md +++ b/reference/fleet/filter-agent-list-by-tags.md @@ -49,7 +49,7 @@ To manage tags in {{fleet}}: | Create a new tag | Type the tag name and click **Create new tag…**. Notice the tag name hasa check mark to show that the tag has been added to the selected agents. | | Rename a tag | Hover over the tag name and click the ellipsis button. Type a new name and press Enter.The tag will be renamed in all agents that use it, even agents that are notselected. | | Delete a tag | Hover over the tag name and click the ellipsis button. Click **Delete tag**.The tag will be deleted from all agents, even agents that are not selected. | - | Add or remove a tag from an agent | Click the tag name to add or clear the check mark. In the **Tags** column,notice that the tags are added or removed. Note that the menu only showstags that are common to all selected agents. | + | Add or remove a tag from an agent | Click the tag name to add or clear the check mark. In the **Tags** column,notice that the tags are added or removed. The menu only showstags that are common to all selected agents. | diff --git a/reference/fleet/fleet-agent-proxy-managed.md b/reference/fleet/fleet-agent-proxy-managed.md index 3604fa8410..7745a9b7ed 100644 --- a/reference/fleet/fleet-agent-proxy-managed.md +++ b/reference/fleet/fleet-agent-proxy-managed.md @@ -64,7 +64,7 @@ These steps describe how to set up {{fleet}} components to use a proxy. 3. **Attach the proxy to the output** - Similarly, if the data plane traffic to an output is to traverse via a proxy, that proxy definition would need to be added to the output defined in the Fleet. + Similarly, if the data plane traffic to an output is to traverse through a proxy, that proxy definition would need to be added to the output defined in the Fleet. 1. In {{fleet}}, open the **Settings** tab. 2. In the list of **Outputs**, choose an output and select the edit button to configure it. diff --git a/reference/fleet/fleet-agent-proxy-support.md b/reference/fleet/fleet-agent-proxy-support.md index 017a5d3a51..4ddd51fdce 100644 --- a/reference/fleet/fleet-agent-proxy-support.md +++ b/reference/fleet/fleet-agent-proxy-support.md @@ -8,7 +8,7 @@ products: # Using a proxy server with Elastic Agent and Fleet [fleet-agent-proxy-support] -Many enterprises secure their assets by placing a proxy server between them and the internet. The main role of the proxy server is to filter content and provide a single gateway through which all traffic traverses in and out of a data center. These proxy servers provide a various degree of functionality, security and privacy. +Many enterprises secure their assets by placing a proxy server between them and the internet. The main role of the proxy server is to filter content and provide a single gateway through which all traffic traverses in and out of a data center. These proxy servers provide a various degree of functionality, security, and privacy. Your organization’s security strategy and other considerations may require you to use a proxy server between some components in your deployment. For example, you may have a firewall rule that prevents endpoints from connecting directly to {{es}}. In this scenario, you can set up the {{agent}} to connect to a proxy, then the proxy can connect to {{es}} through the firewall. diff --git a/reference/fleet/fleet-enrollment-tokens.md b/reference/fleet/fleet-enrollment-tokens.md index 52abaf9bd1..0f8d6919bf 100644 --- a/reference/fleet/fleet-enrollment-tokens.md +++ b/reference/fleet/fleet-enrollment-tokens.md @@ -44,7 +44,7 @@ To create an enrollment token: 1. In {{kib}}, go to **Management → {{fleet}} → Enrollment tokens**. 2. Click **Create enrollment token**. Name your token and select an agent policy. - Note that the token name you specify must be unique so as to avoid conflict with any existing API keys. + The token name you specify must be unique so as to avoid conflict with any existing API keys. :::{image} images/create-token.png :alt: Enrollment tokens tab in {{fleet}} @@ -89,7 +89,7 @@ To revoke an enrollment token: To re-enroll your {{agent}}s, use an active enrollment token. -Note that when an enrollment token is revoked it is not immediately deleted. Deletion occurs automatically after the duration specified in the {{es}} [`xpack.security.authc.api_key.delete.retention_period`](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md#api-key-service-settings-delete-retention-period) setting has expired (see [Invalidate API key API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-security-invalidate-api-key) for details). +When an enrollment token is revoked it is not immediately deleted. Deletion occurs automatically after the duration specified in the {{es}} [`xpack.security.authc.api_key.delete.retention_period`](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md#api-key-service-settings-delete-retention-period) setting has expired (see [Invalidate API key API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-security-invalidate-api-key) for details). Until the enrollment token has been deleted: diff --git a/reference/fleet/fleet-server-monitoring.md b/reference/fleet/fleet-server-monitoring.md index cbb196a31e..b5d0148328 100644 --- a/reference/fleet/fleet-server-monitoring.md +++ b/reference/fleet/fleet-server-monitoring.md @@ -46,4 +46,4 @@ The following dashboard shows data for the query `data_stream.namespace: "fleets :screenshot: ::: -Note that as an alternative to running the query, you can hide all metrics except `fleet_server` in the dashboard. +As an alternative to running the query, you can hide all metrics except `fleet_server` in the dashboard. diff --git a/reference/fleet/fleet-server-secrets.md b/reference/fleet/fleet-server-secrets.md index 362703238b..489eaa052b 100644 --- a/reference/fleet/fleet-server-secrets.md +++ b/reference/fleet/fleet-server-secrets.md @@ -22,7 +22,7 @@ Stand-alone {{fleet-server}} is under active development. The following secret values may be used when configuring {{fleet-server}}. -Note that the configuration fragments shown below are specified either in the UI as part of the output specification or as part of the {{fleet-server}} integration settings. +The configuration fragments shown below are specified either in the UI as part of the output specification or as part of the {{fleet-server}} integration settings. `service_token` : The `service_token` is used to communicate with {{es}}. diff --git a/reference/fleet/fleet-settings.md b/reference/fleet/fleet-settings.md index dd00b3ec7c..8e7d4b1859 100644 --- a/reference/fleet/fleet-settings.md +++ b/reference/fleet/fleet-settings.md @@ -140,9 +140,9 @@ On the **{{fleet}}** > **Settings** page, you can also configure {{fleet}} to au ### Delete unenrolled agents [delete-unenrolled-agents-setting] -After an {{agent}} has been unenrolled in {{fleet}}, a number of documents about the agent are retained just in case the agent needs to be recovered at some point. You can choose to have all data related to an unenrolled agent deleted automatically. +After an {{agent}} has been unenrolled in {{fleet}}, a number of documents about the agent are retained in case the agent needs to be recovered at some point. You can choose to have all data related to an unenrolled agent deleted automatically. -Note that this option can also be enabled by adding the `xpack.fleet.enableDeleteUnenrolledAgents: true` setting to the [{{kib}} settings file](/get-started/the-stack.md). +This option can also be enabled by adding the `xpack.fleet.enableDeleteUnenrolledAgents: true` setting to the [{{kib}} settings file](/get-started/the-stack.md). To enable automatic deletion of unenrolled agents: @@ -163,4 +163,4 @@ To display agentless resources in the agent and agent policy lists: 1. Go to **{{fleet}}** > **Settings**. 2. In the **Advanced Settings** section, enable **Show agentless resources**. -Note that you can view and request diagnostics for agentless agents, but you cannot upgrade, unenroll, or reassign them. \ No newline at end of file +You can view and request diagnostics for agentless agents, but you cannot upgrade, unenroll, or reassign them. \ No newline at end of file diff --git a/reference/fleet/install-agent-msi.md b/reference/fleet/install-agent-msi.md index 035724d23f..278510bba6 100644 --- a/reference/fleet/install-agent-msi.md +++ b/reference/fleet/install-agent-msi.md @@ -64,7 +64,7 @@ Installing using an MSI package has the following behaviors: ## Upgrading [_upgrading] -The {{agent}} version can be upgraded via {{fleet}}, but the registered MSI version will display the initially installed version (this shortcoming will be addressed in future releases). Attempts to upgrade outside of {{fleet}} via the MSI will require an uninstall and reinstall procedure to upgrade. Also note that this MSI implementation relies on the tar {{agent}} binary to upgrade the installation. Therefore if the {{agent}} is installed in an air-gapped environment, you must ensure that the tar image is available before an upgrade request is issued. +The {{agent}} version can be upgraded through {{fleet}}, but the registered MSI version will display the initially installed version (this shortcoming will be addressed in future releases). Attempts to upgrade outside of {{fleet}} through the MSI will require an uninstall and reinstall procedure to upgrade. This MSI implementation relies on the tar {{agent}} binary to upgrade the installation. Therefore if the {{agent}} is installed in an air-gapped environment, you must ensure that the tar image is available before an upgrade request is issued. ## Installing in a custom location [_installing_in_a_custom_location] diff --git a/reference/fleet/install-fleet-managed-elastic-agent.md b/reference/fleet/install-fleet-managed-elastic-agent.md index 158c5e19b6..beedd529b3 100644 --- a/reference/fleet/install-fleet-managed-elastic-agent.md +++ b/reference/fleet/install-fleet-managed-elastic-agent.md @@ -24,7 +24,7 @@ To get up and running quickly, read one of our end-to-end guides: Looking for upgrade info? Refer to [Upgrade {{agent}}s](/reference/fleet/upgrade-elastic-agent.md). -Just want to learn how to install {{agent}}? Continue reading this page. +Want to learn how to install {{agent}}? Continue reading this page. ## Prerequisites [elastic-agent-prereqs] @@ -64,7 +64,7 @@ To install an {{agent}} and enroll it in {{fleet}}: :::: 3. Make sure **Enroll in Fleet** is selected. -4. Download, install, and enroll the {{agent}} on your host by selecting your host operating system and following the **Install {{agent}} on your host** step. Note that the commands shown are for AMD platforms, but ARM packages are also available. Refer to the {{agent}} [downloads page](https://www.elastic.co/downloads/elastic-agent) for the full list of available packages. +4. Download, install, and enroll the {{agent}} on your host by selecting your host operating system and following the **Install {{agent}} on your host** step. The commands shown are for AMD platforms, but ARM packages are also available. Refer to the {{agent}} [downloads page](https://www.elastic.co/downloads/elastic-agent) for the full list of available packages. 1. If you are enrolling the agent in a {{fleet-server}} that uses your organization’s certificate you *must* add the `--certificate-authorities` option to the command provided in the in-product instructions. If you do not include the certificate, you will see the following error: "x509: certificate signed by unknown authority". diff --git a/reference/fleet/install-uninstall-integration-assets.md b/reference/fleet/install-uninstall-integration-assets.md index 042da7ca70..533a69ad65 100644 --- a/reference/fleet/install-uninstall-integration-assets.md +++ b/reference/fleet/install-uninstall-integration-assets.md @@ -19,7 +19,7 @@ products: 2. Click the **Settings** tab. 3. Click **Install assets** to set up the {{kib}} and {{es}} assets. -Note that it’s currently not possible to have multiple versions of the same integration installed. When you upgrade an integration, the previous version assets are removed and replaced by the current version. +It's currently not possible to have multiple versions of the same integration installed. When you upgrade an integration, the previous version assets are removed and replaced by the current version. ::::{admonition} Spaces support for integration assets