Merge branch 'main' into szabosteve/conceptual-eis

Author: szabosteve

.github/ISSUE_TEMPLATE/issue-report.yaml

@@ -0,0 +1,42 @@
+name: "Docs issue"
+description: Report documentation issues such as inaccuracies, broken links, typos, or missing information.
+title: "[Issue]: "
+labels: ["triage"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Hi 👋. Thanks for taking the time to fill out this issue report!
+        This form will create an issue that Elastic's docs team will triage and prioritize.
+        You can also open a PR instead.
+  - type: dropdown
+    attributes:
+      label: Type of issue
+      description: What type of issue are you reporting?
+      multiple: false
+      options:
+        - Inaccurate
+        - Missing information
+        - I can't find what I'm looking for
+        - Other
+  - type: input
+    id: link
+    attributes:
+      label: What documentation page is affected
+      description: Include a link to the page where you're seeing the problem.
+    validations:
+      required: true
+  - type: textarea
+    id: related
+    attributes:
+      label: What happened?
+      description: Describe the issue you're experiencing. Screenshots are valuable too!
+    validations:
+      required: true
+  - type: textarea
+    id: moreinfo
+    attributes:
+      label: Additional info
+      description: Anything else we should know?
+    validations:
+      required: false

cloud-account/dark-mode.md

@@ -0,0 +1,31 @@
+---
+applies_to:
+  stack: all
+  serverless: all
+---
+
+# Use dark mode in Kibana
+
+The dark mode changes Kibana's default light appearance to a darker and higher-contrast color theme. From the application header, you can turn on dark mode or synchronize the color mode with your operating system settings.
+
+:::{tip}
+If you're using {{ecloud}}, this setting only applies to the Kibana UI of your serverless projects and hosted deployments. If you'd like to change the {{ecloud}} Console color theme too, you must do so separately from its respective interface.
+:::
+
+## Change your color mode preferences
+
+1. Open the user menu from the header.
+2. Select **Appearance**.
+3. Choose a color mode:
+
+    - **Light**: The default color mode of Kibana
+    - **Dark**: The dark and high-contrast color mode of Kibana
+    - **System**: Synchronizes Kibana's color mode with your system settings
+    - **Space default**: Sets the color mode to the value defined in the [Space settings](kibana://reference/advanced-settings.md#kibana-general-settings)
+
+      :::{admonition} Deprecated
+      The **Space default** option will be removed in a future version and automatically replaced with the System color mode.
+      :::
+
+4. Select **Save changes**.
+5. Refresh the page to apply the selected color mode.

cloud-account/index.md

@@ -7,7 +7,7 @@ applies:
   hosted: all
 ---
 
-# Manage your Cloud account
+# Manage your Cloud account and preferences
 
 Your {{ecloud}} account allows you to manage your personal settings, including your email address, password, and authentication methods. You can perform the following tasks at any time from your user profile:
 
@@ -21,6 +21,8 @@ If you use password-based login, then you can perform the following additional t
 
 Additionally, you can manage your organization membership, including joining or leaving an organization. Refer to [Join or leave an organization](/cloud-account/join-or-leave-an-organization.md) for more information.
 
+Some options also let you set personal preferences and customize the interface, such as [using dark mode](dark-mode.md) in your projects and deployments.
+
 ::::{tip} 
 This section focuses on the actions you can take as an individual user to manage your own account. It does not cover organization-wide settings, such as managing user permissions or configuring organization-level access controls, which are handled by the organization administrators.
 

cloud-account/toc.yml

@@ -5,4 +5,5 @@ toc:
   - file: update-your-email-address.md
   - file: change-your-password.md
   - file: add-a-login-method.md
-  - file: multifactor-authentication.md
+  - file: multifactor-authentication.md
+  - file: dark-mode.md

deploy-manage/autoscaling/trained-model-autoscaling.md

@@ -46,7 +46,7 @@ If you set the minimum number of allocations to 1, you will be charged even if t
 
 You can enable adaptive allocations by using:
 
-* the create inference endpoint API for [ELSER](../../explore-analyze/elastic-inference/inference-api/elasticsearch-inference-integration.md), [E5 and models uploaded through Eland](../../explore-analyze/elastic-inference/inference-api/elasticsearch-inference-integration.md) that are used as inference services.
+* the create inference endpoint API for [ELSER](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-inference-put-elser), [E5 and models uploaded through Eland](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-inference-put-elasticsearch) that are used as inference services.
 * the [start trained model deployment](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-ml-start-trained-model-deployment) or [update trained model deployment](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-ml-update-trained-model-deployment) APIs for trained models that are deployed on {{ml}} nodes.
 
 If the new allocations fit on the current {{ml}} nodes, they are immediately started. If more resource capacity is needed for creating new model allocations, then your {{ml}} node will be scaled up if {{ml}} autoscaling is enabled to provide enough resources for the new allocation. The number of model allocations can be scaled down to 0. They cannot be scaled up to more than 32 allocations, unless you explicitly set the maximum number of allocations to more. Adaptive allocations must be set up independently for each deployment and [{{infer}} endpoint](https://www.elastic.co/docs/api/doc/elasticsearch/group/endpoint-inference).

deploy-manage/deploy/cloud-enterprise/add-custom-bundles-plugins.md

@@ -314,7 +314,7 @@ To import a JVM trust store:
             }
     ```
 
-4. To use this bundle, you can refer it in the [GeoIP processor](elasticsearch://reference/ingestion-tools/enrich-processor/geoip-processor.md) of an ingest pipeline as `MyGeoLite2-City.mmdb` under `database_file` such as:
+4. To use this bundle, you can refer it in the [GeoIP processor](elasticsearch://reference/enrich-processor/geoip-processor.md) of an ingest pipeline as `MyGeoLite2-City.mmdb` under `database_file` such as:
 
     ```sh
     ...

deploy-manage/deploy/cloud-enterprise/ece-ha.md

@@ -1,74 +1,60 @@
 ---
+navigation_title: High availability
 applies_to:
   deployment:
     ece: all
 mapped_pages:
   - https://www.elastic.co/guide/en/cloud-enterprise/current/ece-ha.html
 ---
 
-# High availability [ece-ha]
+# High availability in ECE
 
-Ensuring high availability in {{ece}} (ECE) requires careful planning and implementation across multiple areas, including availability zones, master nodes, replica shards, snapshot backups, and Zookeeper nodes.
+Ensuring high availability (HA) in {{ece}} (ECE) requires careful planning and implementation across multiple areas, including availability zones, master nodes, replica shards, snapshot backups, and Zookeeper nodes.
 
-This section describes key considerations and best practices to prevent downtime and data loss at both the ECE platform level and within orchestrated deployments.
-
-## Availability zones [ece-ece-ha-1-az]
-
-Fault tolerance for ECE is based around the concept of *availability zones*.
-
-An availability zone contains resources available to an ECE installation that are isolated from other availability zones to safeguard against potential failure.
-
-Planning for a fault-tolerant installation with multiple availability zones means avoiding any single point of failure that could bring down ECE.
-
-The main difference between ECE installations that include two or three availability zones is that three availability zones enable ECE to create clusters with a *tiebreaker*. If you have only two availability zones in total in your installation, no tiebreaker is created.
+::::{note}
+This section focuses on ensuring high availability at the ECE platform level. For deployment-level considerations, including resiliency, scaling, and performance optimizations for running {{es}} and {{kib}}, refer to the general [production guidance](/deploy-manage/production-guidance.md).
+::::
 
-We recommend that for each deployment you use at least two availability zones for production and three for mission-critical systems. Using more than three availability zones for a deployment is not required nor supported. Availability zones are intended for high availability, not scalability.
+To maintain a minimum HA, you should deploy at least two ECE hosts for each role—**allocator, constructor, and proxy**—and at least three hosts for the **director** role, which runs ZooKeeper and requires quorum to operate reliably.
 
-::::{warning}
-{{es}} clusters that are set up to use only one availability zone are not [highly available](/deploy-manage/production-guidance/availability-and-resilience.md) and are at risk of data loss. To safeguard against data loss, you must use at least two {{ece}} availability zones.
-::::
+In addition, to improve resiliency at the availability zone level, it’s recommended to deploy ECE across three availability zones, with at least two allocators per zone and spare capacity to accommodate instance failover and workload redistribution in case of failures.
 
-::::{warning}
-Increasing the number of zones should not be used to add more resources. The concept of zones is meant for High Availability (2 zones) and Fault Tolerance (3 zones), but neither will work if the cluster relies on the resources from those zones to be operational. The recommendation is to scale up the resources within a single zone until the cluster can take the full load (add some buffer to be prepared for a peak of requests), then scale out by adding additional zones depending on your requirements: 2 zones for High Availability, 3 zones for Fault Tolerance.
-::::
+All Elastic-documented architectures recommend using three availability zones with ECE roles distributed across all zones. Refer to [deployment scenarios](./identify-deployment-scenario.md) for examples of small, medium, and large installations.
 
+Regardless of the resiliency level at the platform level, it’s important to also [configure your deployments for high availability](/deploy-manage/production-guidance/availability-and-resilience/resilience-in-ech.md).
 
-## Master nodes [ece-ece-ha-2-master-nodes]
+## Availability zones [ece-ece-ha-1-az]
 
-Tiebreakers are used in distributed clusters to avoid cases of [split brain](https://en.wikipedia.org/wiki/Split-brain_(computing)), where an {{es}} cluster splits into multiple, autonomous parts that continue to handle requests independently of each other, at the risk of affecting cluster consistency and data loss. A split-brain scenario is avoided by making sure that a minimum number of [master-eligible nodes](elasticsearch://reference/elasticsearch/configuration-reference/node-settings.md#master-node) must be present in order for any part of the cluster to elect a master node and accept user requests. To prevent multiple parts of a cluster from being eligible, there must be a [quorum-based majority](/deploy-manage/distributed-architecture/discovery-cluster-formation/modules-discovery-quorums.md) of `(n/2)+1` nodes, where `n` is the number of master-eligible nodes in the cluster. The minimum number of master nodes to reach quorum in a two-node cluster is the same as for a three-node cluster: two nodes must be available.
+Fault tolerance for ECE is based around the concept of *availability zones*.
 
-When you create a cluster with nodes in two availability zones when a third zone is available, ECE can create a tiebreaker in the third availability zone to help establish quorum in case of loss of an availability zone. The extra tiebreaker node that helps to provide quorum does not have to be a full-fledged and expensive node, as it does not hold data. For example: By tagging allocators hosts in ECE, can you create a cluster with eight nodes each in zones `ece-1a` and `ece-1b`, for a total of 16 nodes, and one tiebreaker node in zone `ece-1c`. This cluster can lose any of the three availability zones whilst maintaining quorum, which means that the cluster can continue to process user requests, provided that there is sufficient capacity available when an availability zone goes down.
+An availability zone contains resources available to an ECE installation that are isolated from other availability zones to safeguard against potential failure.
 
-By default, each node in an {{es}} cluster is a master-eligible node and a data node. In larger clusters, such as production clusters, it’s a good practice to split the roles, so that master nodes are not handling search or indexing work. When you create a cluster, you can specify to use dedicated [master-eligible nodes](elasticsearch://reference/elasticsearch/configuration-reference/node-settings.md#master-node), one per availability zone.
+Planning for a fault-tolerant installation with multiple availability zones means avoiding any single point of failure that could bring down ECE.
 
-::::{warning}
-Clusters that only have two or fewer master-eligible node are not [highly available](/deploy-manage/production-guidance/availability-and-resilience.md) and are at risk of data loss. You must have [at least three master-eligible nodes](/deploy-manage/distributed-architecture/discovery-cluster-formation/modules-discovery-quorums.md).
+::::{important}
+Adding more availability zones should not be used as a way to increase processing capacity and performance. The concept of zones is meant for high availability (2 zones) and fault tolerance (3 zones), but neither will work if your deployments rely on the resources from those zones to be operational. Refer to [scaling considerations](/deploy-manage/production-guidance/scaling-considerations.md#scaling-and-fault-tolerance) for more information.
 ::::
 
-## Replica shards [ece-ece-ha-3-replica-shards]
+The main difference between ECE installations that include two or three availability zones is that three availability zones enable ECE to create {{es}} clusters with a [voting-only tiebreaker](/deploy-manage/distributed-architecture/clusters-nodes-shards/node-roles.md#voting-only-node) instance. If you have only two availability zones in your installation, no tiebreaker can be placed in a third zone, limiting the cluster’s ability to tolerate certain failures.
 
-With multiple {{es}} nodes in multiple availability zones you have the recommended hardware, the next thing to consider is having the recommended index replication. Each index, with the exception of searchable snapshot indexes, should have one or more replicas. Use the index settings API to find any indices with no replica:
+## Tiebreaker master nodes
 
-```sh
-GET _all/_settings/index.number_of_replicas
-```
+A tiebreaker is a lightweight voting-only node used in distributed clusters to help avoid split-brain scenarios, where the cluster could incorrectly split into multiple autonomous parts during a network partition.
 
-::::{warning}
-Indices with no replica, except for [searchable snapshot indices](/deploy-manage/tools/snapshot-and-restore/searchable-snapshots.md), are not highly available. You should use replicas to mitigate against possible data loss.
-::::
+When you create a cluster with nodes in two availability zones when a third zone is available, ECE can create a tiebreaker in the third availability zone to help establish quorum in case of loss of an availability zone. The extra tiebreaker node that helps to provide quorum does not have to be a full-fledged and expensive node, as it does not hold data. For example: By [tagging allocators](./ece-configuring-ece-tag-allocators.md) hosts in ECE, can you create a cluster with eight nodes each in zones `ece-1a` and `ece-1b`, for a total of 16 nodes, and one tiebreaker node in zone `ece-1c`. This cluster can lose any of the three availability zones whilst maintaining quorum, which means that the cluster can continue to process user requests, provided that there is sufficient capacity available when an availability zone goes down.
 
-Refer to [](../../reference-architectures.md) for information about {{es}} architectures.
+## Zookeeper nodes
 
-## Snapshot backups [ece-ece-ha-4-snapshot]
+Make sure you have three Zookeepers—by default, on the Director host—for your ECE installation. Similar to three {{es}} master nodes can form a quorum, three Zookeepers can form the quorum for high availability purposes.
 
-You should configure and use [{{es}} snapshots](/deploy-manage/tools/snapshot-and-restore.md). Snapshots provide a way to backup and restore your {{es}} indices. They can be used to copy indices for testing, to recover from failures or accidental deletions, or to migrate data to other deployments. We recommend configuring an [{{ece}}-level repository](../../tools/snapshot-and-restore/cloud-enterprise.md) to apply across all deployments. See [Work with snapshots](../../tools/snapshot-and-restore.md) for more guidance.
+Backing up Zookeeper data directory is also recommended. Refer to [rebuilding a broken Zookeeper quorum](../../../troubleshoot/deployments/cloud-enterprise/rebuilding-broken-zookeeper-quorum.md) for more guidance.
 
-## Furthermore considerations [ece-ece-ha-5-other]
+## External resources accessibility
 
-* Make sure you have three Zookeepers - by default, on the Director host - for your ECE installation. Similar to three Elasticsearch master nodes can form a quorum, three Zookeepers can forum the quorum for high availability purposes. Backing up Zookeeper data directory is also recommended, read [this doc](../../../troubleshoot/deployments/cloud-enterprise/rebuilding-broken-zookeeper-quorum.md) for more guidance.
+If you’re using a [private Docker registry server](ece-install-offline-with-registry.md) or hosting any [custom bundles and plugins](../../../solutions/search/full-text/search-with-synonyms.md) on a web server, make sure these resources are accessible from all ECE allocators, so they can continue to be accessed in the event of a network partition or zone outage.
 
-* Make sure that if you’re using a [private Docker registry server](ece-install-offline-with-registry.md) or are using any [custom bundles and plugins](../../../solutions/search/full-text/search-with-synonyms.md) hosted on a web server, that these are available to all ECE allocators, so that they can continue to be accessed in the event of a network partition or zone outage.
+## Other recommendations
 
-* Don’t delete containers unless guided by Elastic Support or there’s public documentation explicitly describing this as required action. Otherwise, it can cause issues and you may lose access or functionality of your {{ece}} platform. See [Troubleshooting container engines](../../../troubleshoot/deployments/cloud-enterprise/troubleshooting-container-engines.md) for more information.
+Avoid deleting containers unless explicitly instructed by Elastic Support or official documentation. Doing so may lead to unexpected issues or loss of access to your {{ece}} platform. For more details, refer to [](/troubleshoot/deployments/cloud-enterprise/troubleshooting-container-engines.md).
 
-If in doubt, please [contact support for help](../../../troubleshoot/deployments/cloud-enterprise/ask-for-help.md).
+If in doubt, please [contact support for help](/troubleshoot/index.md#contact-us).