[OnWeek] Fix Vale rule warnings in reference/fleet (pt1) (#3907)

This PR is part of the OnWeek project about fixing Vale rule violations
in docs-content.

It fixes warnings in part of the `reference/fleet` folder.

Assisted by Cursor.

Author: natasha-moore-elastic

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}}.
 
 ::::
 

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`.
 
             ::::
 

reference/fleet/advanced-kubernetes-managed-by-fleet.md

@@ -83,7 +83,7 @@ containers:
 ```
 
 Notes
-:   The <ImageVersion> 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 <ImageVersion> 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:

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.
 

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

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]

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.

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

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 "")<br>(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 "")<br>(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 "")<br>{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`<br><br>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 "")<br>(uses input conditions instead) | ![no](images/red-x.svg "")<br>(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 "")<br>(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 "")<br>(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). |