Merge branch 'main' into issue-2526-suppression-adv-setting-9.2-serv

Author: nastasha-solomon

deploy-manage/deploy/self-managed.md

@@ -33,7 +33,8 @@ For a comparison of these deployment options, refer to [Choosing your deployment
 
 This section focuses on deploying {{es}} and {{kib}} without an orchestrator.
 
-Depending on your use case, you might need to deploy other components, such as APM, Fleet, or Logstash. Deploying those components is not covered in this section. [Learn more about optional components](/get-started/the-stack.md).
+Depending on your use case, you might need to deploy other components, such as APM, Fleet, or Logstash.
+Deploying those components is not covered in this section. [Learn more about optional components](/get-started/the-stack.md).
 
 This section covers the following tasks:
 

deploy-manage/deploy/self-managed/important-settings-configuration.md

@@ -1,6 +1,7 @@
 ---
 mapped_pages:
   - https://www.elastic.co/guide/en/elasticsearch/reference/current/important-settings.html
+  - https://www.elastic.co/guide/en/elasticsearch/reference/current/networkaddress-cache-ttl.html
 applies_to:
   deployment:
     self:
@@ -13,16 +14,17 @@ products:
 {{es}} requires very little configuration to get started, but there are a number of items which **must** be considered before using your cluster in production:
 
 * [Path settings](#path-settings)
-* [Cluster name setting](elasticsearch://reference/elasticsearch/configuration-reference/miscellaneous-cluster-settings.md#cluster-name)
+* [Cluster name setting](#_cluster_name_setting)
 * [Node name setting](#node-name)
 * [Network host settings](#network.host)
 * [Discovery settings](#discovery-settings)
 * [Heap size settings](#heap-size-settings)
 * [JVM heap dump path setting](#heap-dump-path)
-* [GC logging settings](elasticsearch://reference/elasticsearch/jvm-settings.md#gc-logging)
+* [GC logging settings](#_gc_logging_settings)
 * [Temporary directory settings](#es-tmpdir)
-* [JVM fatal error log setting](elasticsearch://reference/elasticsearch/jvm-settings.md#error-file-path)
+* [JVM fatal error log setting](#_jvm_fatal_error_log_setting)
 * [Cluster backups](#important-settings-backups)
+* [DNS cache settings](#networkaddress-cache-ttl)
 
 ## Path settings [path-settings]
 
@@ -241,3 +243,7 @@ In a disaster, [snapshots](../../tools/snapshot-and-restore.md) can prevent perm
 **Taking a snapshot is the only reliable and supported way to back up a cluster.** You cannot back up an {{es}} cluster by making copies of the data directories of its nodes. There are no supported methods to restore any data from a file system-level backup. If you try to restore a cluster from such a backup, it may fail with reports of corruption or missing files or other data inconsistencies, or it may appear to have succeeded having silently lost some of your data.
 
 ::::
+
+## DNS cache settings [networkaddress-cache-ttl]
+
+{{es}} runs with a security manager in place. With a security manager in place, the JVM defaults to caching positive hostname resolutions indefinitely and defaults to caching negative hostname resolutions for ten seconds. {{es}} overrides this behavior with default values to cache positive lookups for sixty seconds, and to cache negative lookups for ten seconds. These values should be suitable for most environments, including environments where DNS resolutions vary with time. If not, you can edit the values `es.networkaddress.cache.ttl` and `es.networkaddress.cache.negative.ttl` in the [JVM options](elasticsearch://reference/elasticsearch/jvm-settings.md#set-jvm-options). Note that the values [`networkaddress.cache.ttl=<timeout>`](https://docs.oracle.com/javase/8/docs/technotes/guides/net/properties.md) and [`networkaddress.cache.negative.ttl=<timeout>`](https://docs.oracle.com/javase/8/docs/technotes/guides/net/properties.md) in the [Java security policy](https://docs.oracle.com/javase/8/docs/technotes/guides/security/PolicyFiles.md) are ignored by {{es}} unless you remove the settings for `es.networkaddress.cache.ttl` and `es.networkaddress.cache.negative.ttl`.

deploy-manage/deploy/self-managed/important-system-configuration.md

@@ -18,7 +18,6 @@ The following settings **must** be considered before going to production:
 * [](setup-configuration-memory.md)
 * [](vm-max-map-count.md)
 * [](max-number-of-threads.md)
-* [](networkaddress-cache-ttl.md)
 * [](file-descriptors.md) (Linux and MacOS only)
 * [](executable-jna-tmpdir.md) (Linux only)
 * [](system-config-tcpretries.md) (Linux only)

deploy-manage/deploy/self-managed/networkaddress-cache-ttl.md

@@ -25,7 +25,7 @@ Refer to [Troubleshooting discovery](../../../troubleshoot/elasticsearch/discove
 
 By default the cluster formation module offers two seed hosts providers to configure the list of seed nodes: a *settings*-based and a *file*-based seed hosts provider. It can be extended to support cloud environments and other forms of seed hosts providers via [discovery plugins](elasticsearch://reference/elasticsearch-plugins/discovery-plugins.md). Seed hosts providers are configured using the `discovery.seed_providers` setting, which defaults to the *settings*-based hosts provider. This setting accepts a list of different providers, allowing you to make use of multiple ways to find the seed hosts for your cluster.
 
-Each seed hosts provider yields the IP addresses or hostnames of the seed nodes. If it returns any hostnames then these are resolved to IP addresses using a DNS lookup. If a hostname resolves to multiple IP addresses then {{es}} tries to find a seed node at all of these addresses. If the hosts provider does not explicitly give the TCP port of the node by then, it will implicitly use the first port in the port range given by `transport.profiles.default.port`, or by `transport.port` if `transport.profiles.default.port` is not set. The number of concurrent lookups is controlled by `discovery.seed_resolver.max_concurrent_resolvers` which defaults to `10`, and the timeout for each lookup is controlled by `discovery.seed_resolver.timeout` which defaults to `5s`. Note that DNS lookups are subject to [JVM DNS caching](../../deploy/self-managed/networkaddress-cache-ttl.md).
+Each seed hosts provider yields the IP addresses or hostnames of the seed nodes. If it returns any hostnames then these are resolved to IP addresses using a DNS lookup. If a hostname resolves to multiple IP addresses then {{es}} tries to find a seed node at all of these addresses. If the hosts provider does not explicitly give the TCP port of the node by then, it will implicitly use the first port in the port range given by `transport.profiles.default.port`, or by `transport.port` if `transport.profiles.default.port` is not set. The number of concurrent lookups is controlled by `discovery.seed_resolver.max_concurrent_resolvers` which defaults to `10`, and the timeout for each lookup is controlled by `discovery.seed_resolver.timeout` which defaults to `5s`. Note that DNS lookups are subject to [JVM DNS caching](/deploy-manage/deploy/self-managed/important-settings-configuration.md#networkaddress-cache-ttl).
 
 #### Settings-based seed hosts provider [settings-based-hosts-provider]
 

deploy-manage/distributed-architecture/discovery-cluster-formation/discovery-hosts-providers.md

@@ -19,13 +19,19 @@ These steps show how you can safely perform maintenance on hosts in your ECE ins
 
 You can perform these maintenance actions on the hosts in your ECE installation using one of these methods:
 
-* [By disabling the Docker daemon (nondestructive)](#ece-perform-host-maintenance-docker-disable)
+* [By disabling the container services (nondestructive)](#ece-perform-host-maintenance-container-engine-disable):
+  * [For Docker-based installations: disable the Docker service](#ece-perform-host-maintenance-docker-disable)
+  * [For Podman-based installations: disable the Podman-related services](#ece-perform-host-maintenance-podman-disable) 
 * [By deleting the host (destructive)](#ece-perform-host-maintenance-delete-runner)
 * [By shutting down the host (less destructive)](#ece-perform-host-maintenance-delete-runner)
 
 Which method you choose depends on how invasive your host maintenance needs to be. If your host maintenance could affect ECE, use the destructive method that first deletes the host from your installation. These methods include a step that moves any hosted {{es}} clusters and {{kib}} instances off the affected hosts and are generally considered safe, provided that your ECE installation still has sufficient resources available to operate after the host has been removed.
 
-## By disabling the Docker daemon [ece-perform-host-maintenance-docker-disable]
+## By disabling the container services (nondestructive) [ece-perform-host-maintenance-container-engine-disable]
+
+The way that you disable container services differs based on the platform you used to deploy your ECE hosts.
+
+### For Docker-based installations: disable the Docker service [ece-perform-host-maintenance-docker-disable]
 
 This method lets you perform maintenance actions on hosts without first removing the associated host from your {{ece}} installation. It works by disabling the Docker daemon. The host remains a part of your ECE installation throughout these steps but will be offline and the resources it provides will not be available.
 
@@ -71,6 +77,74 @@ To perform host maintenance:
 
 After the host shows a green status in the Cloud UI, it is fully functional again and can be used as before.
 
+### For Podman-based installations: disable the Podman-related services [ece-perform-host-maintenance-podman-disable]
+
+This method lets you perform maintenance actions on hosts without first removing the associated host from your {{ece}} installation. It works by disabling the Podman related services. The host remains a part of your ECE installation throughout these steps but will be offline and the resources it provides will not be available.
+
+To perform host maintenance:
+
+1. Recommended: If the host holds the allocator role and you have enough spare capacity:
+   1. [Enable maintenance mode](enable-maintenance-mode.md) on the allocator.
+   2. [Move all nodes off the allocator](move-nodes-instances-from-allocators.md) and to other allocators in your installation. Moving all nodes lets you retain the same level of redundancy for highly available {{es}} clusters and ensures that other clusters without high availability remain available.
+   ::::{important}
+   Skipping Step 1 will affect the availability of clusters with nodes on the allocator.
+   ::::
+
+2. Disable the Podman service, Podman socket, and Podman restart service:
+
+    ```sh
+    sudo systemctl disable podman.service
+    sudo systemctl disable podman.socket
+    sudo systemctl disable podman-restart.service
+    ```
+
+3. Reboot the host:
+
+    ```sh
+    sudo reboot
+    ```
+
+4. After rebooting, confirm there are no running containers by running the following command. The output should be empty.
+    ```sh
+    sudo podman ps
+    ```
+
+	If an `frc-*` or `fac-*` container is returned in the output, stop it:
+	
+	```sh
+	sudo podman stop $(sudo podman ps -a --filter "name=fac" --filter "name=frc" --format "{{.ID}}")
+	```
+
+4. Perform your maintenance on the host, such as patching the operating system.
+5. Re-enable the Podman related services:
+
+    ```sh
+    sudo systemctl enable podman.service
+    sudo systemctl enable podman.socket
+    sudo systemctl enable podman-restart.service
+    ```
+
+6. Reboot the host again:
+
+    ```sh
+    sudo reboot
+    ```
+
+7. Confirm the containers have started:
+
+    ```sh
+    sudo podman ps -a
+    ```
+
+	The use `-a` flag ensures that no containers are overlooked.
+
+
+8. If you enabled maintenance mode in Step 1, take the allocator out of maintenance mode.
+9. Optional for allocators: ECE will start using the allocator again as you create new or change existing clusters, but it will not automatically redistribute nodes to an allocator after it becomes available. If you want to move nodes back to the same allocator after host maintenance, you need to manually [move the nodes](move-nodes-instances-from-allocators.md) and specify the allocator as a target.
+10. Verify that all ECE services and deployments are back up by checking that the host shows a green status in the Cloud UI.
+
+After the host shows a green status in the Cloud UI, it is fully functional again and can be used as before.
+
 ## By deleting the host (destructive) [ece-perform-host-maintenance-delete-runner]
 
 This method lets you perform potentially destructive maintenance actions on hosts. It works by deleting the associated host, which removes the host from your {{ece}} installation. To add the host to your ECE installation again after host maintenance is complete, you must reinstall ECE.

deploy-manage/images/cloud-ec-private-link-service.png

@@ -24,9 +24,10 @@ Find answers to your questions about AutoOps for ECE, ECK, and self-managed clus
 * [Can I use macOS to install {{agent}} for this feature?](#macos-install)
 * [Do I have to define an Elastic IP address to enable the agent to send data to {{ecloud}}?](#elastic-ip-address)
 
-**Questions about collected metrics**
+**Questions about collected metrics and data**
 * [Where are AutoOps metrics stored?](#autoops-metrics-storage)
 * [What information does {{agent}} extract from my cluster?](#extracted-info)
+* [How does AutoOps gather data from my cluster and ensure its security?](#data-gathering)
 
 ## General questions
 $$$why-autoops$$$ **Why should I use AutoOps for my clusters?** 
@@ -42,7 +43,7 @@ $$$autoops-metrics-cost$$$ **Is there an added cost for shipping metrics data to
     You can [choose the CSP region where your data is stored](#autoops-metrics-storage). 
 
 $$$es-versions$$$ **Which versions of {{es}} does AutoOps support?**
-:   AutoOps is compatible with all [supported {{es}} versions](https://www.elastic.co/support/eol).
+:   AutoOps is compatible with [supported {{es}} versions](https://www.elastic.co/support/eol) (7.17.x and above).
 
 $$$deployment-types$$$ **Which deployment types can be connected to AutoOps?**
 :   You can connect to AutoOps on a standalone {{stack}}, ECE ({{ece}}), or ECK ({{eck}}) deployment.
@@ -65,7 +66,7 @@ $$$elastic-ip-address$$$ **Do I have to define an Elastic IP address to enable t
 
 :   For more information, refer to [](/deploy-manage/security/elastic-cloud-static-ips.md).
 
-## Questions about collected metrics
+## Questions about collected metrics and data
 $$$autoops-metrics-storage$$$ **Where are AutoOps metrics stored?**
 :   You can choose where to store your metrics from the following AWS regions:
 
@@ -88,3 +89,14 @@ $$$extracted-info$$$ **What information does {{agent}} extract from my cluster?*
     | [_template](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-indices-get-template) | Retrieves legacy index templates | Similar to composable index templates but in older format |
     | [_resolve/index/*](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-indices-resolve-index) | Resolves index, data stream, and alias names to their current definitions | Mappings between names and underlying data objects |
 
+$$$data-gathering$$$ **How does AutoOps gather data from my cluster and ensure its security?**
+:   AutoOps gathers data from your cluster using two protocols:
+    * **HTTP request**: Made to our Cloud Connected API to register your cluster with {{ecloud}} and gather registration-related data.
+    * **OpenTelemetry Protocol (OTLP)**: Used to gather all other operational data.
+
+    Each channel is authenticated through an API key or token to ensure your data's security. The following table offers more details: 
+
+    | Protocol | Data extracted | Port | Authentication method | 
+    | --- | --- | --- | --- |
+    | HTTP |  Basic cluster information from the `/` endpoint <br><br> License information from the `/_license` endpoint | **443**: standard HTTPS port | Uses an {{ecloud}} API key which is limited for use with Cloud Connect only. |
+    | OTLP | Operational information | **4318**: standard OTLP HTTP port <br><br> This service will be exposed on port 443 in the future. | Uses an AutoOps token which is functionally equivalent to an API key. |

deploy-manage/maintenance/ece/perform-ece-hosts-maintenance.md

@@ -49,4 +49,5 @@ The following table shows the errors you might encounter if something goes wrong
 | `LICENSE_EXPIRED` | Elastic license is expired | Contact [sales](https://www.elastic.co/contact#sales) to renew your license. |
 | `LICENSE_USED_BY_ANOTHER_ACCOUNT` | License key connected to another account | A license key can only be connected to one {{ecloud}} organization. Contact [Elastic support](https://support.elastic.co/) for help. |
 | `VERSION_MISMATCH` | {{es}} version is unsupported | Upgrade your cluster to a [supported version](https://www.elastic.co/support/eol). |
-| `UNKNOWN_ERROR` | Installation failed | {{agent}} couldn't be installed due to an unknown issue. Consult the troubleshooting guide or contact [Elastic support](https://support.elastic.co/) for more help. |
+| `UNKNOWN_ERROR` | Installation failed | {{agent}} couldn't be installed due to an unknown issue. Consult the troubleshooting guide or contact [Elastic support](https://support.elastic.co/) for more help. |
+| `` | Failed to register Cloud Connected Mode: cluster license type is not supported | The cluster you are trying to connect doesn't have the required license to connect to AutoOps. For more information, refer to the [prerequisites](/deploy-manage/monitor/autoops/cc-connect-self-managed-to-autoops.md#prerequisites). |