Apply suggestions from code review

Co-authored-by: shainaraskas <[email protected]>

Author: eedugon

deploy-manage/production-guidance.md

@@ -64,7 +64,7 @@ Other sections of the documentation provide important guidance for running {{sta
 
 ### Plan your data structure, availability, and formatting [ec_plan_your_data_structure_availability_and_formatting]
 
-* Build a [data architecture](/manage-data/lifecycle/data-tiers.md) that best fits your needs. Based on your own access and retention policies, you can add warm, cold, frozen data tiers, and automated deletion of old data.
+* Build a [data architecture](/manage-data/lifecycle/data-tiers.md) that best fits your needs. Based on your own access and retention policies, you can add warm, cold, and frozen data tiers, and automate deletion of old data.
 * Make your data [highly available](/deploy-manage/tools.md) for production environments or otherwise critical data stores, and take regular [backup snapshots](./tools/snapshot-and-restore.md), or consider [](./tools/cross-cluster-replication.md) to replicate indices across clusters.
 * Normalize event data to better analyze, visualize, and correlate your events by adopting the [Elastic Common Schema](asciidocalypse://docs/ecs/docs/reference/ecs-getting-started.md) (ECS). Elastic integrations use ECS out-of-the-box. If you are writing your own integrations, ECS is recommended.
 

deploy-manage/production-guidance/availability-and-resilience.md

@@ -14,11 +14,11 @@ applies_to:
 
 Distributed systems like {{es}} are designed to keep working even if some of their components have failed. As long as there are enough well-connected nodes to take over their responsibilities, an {{es}} cluster can continue operating normally if some of its nodes are unavailable or disconnected.
 
-{{es}} implements high availability at three key levels:
+{{es}} implements high availability (HA) at three key levels:
 
-* Node level – Running multiple nodes within the cluster to avoid single points of failure and maintain operational stability.
-* Cluster level – Ensuring redundancy by distributing nodes across availability zones to prevent failures from affecting the entire cluster.
-* Index level – Configuring shard replication to protect against data loss and improve search performance by distributing queries across multiple copies.
+* **Node level**: Running multiple nodes within the cluster to avoid single points of failure and maintain operational stability.
+* **Cluster level**: Ensuring redundancy by distributing nodes across availability zones to prevent failures from affecting the entire cluster.
+* **Index level**: Configuring shard replication to protect against data loss and improve search performance by distributing queries across multiple copies.
 
 Each of these HA mechanisms contributes to {{es}}’s resilience and scalability. The appropriate strategy depends on factors such as data criticality, query patterns, and infrastructure constraints. It is up to you to determine the level of resiliency and high availability that best fits your use case. This sections provides detailed guidance on designing a production-ready {{es}} deployment that balances availability, performance, and scalability.
 

deploy-manage/production-guidance/availability-and-resilience/resilience-in-ech.md

@@ -29,17 +29,15 @@ With multiple {{es}} nodes in multiple availability zones you have the recommend
 GET _all/_settings/index.number_of_replicas
 ```
 
-Moreover, a high availability (HA) cluster requires at least three master-eligible nodes. For clusters that have fewer than six {{es}} nodes, any data node in the hot tier will also be a master-eligible node. You can achieve this by having hot nodes (serving as both data and master-eligible nodes) in three availability zones, or by having data nodes in two zones and a tiebreaker (will be automatically added if you choose two zones). For clusters that have six {{es}} nodes and beyond, dedicated master-eligible nodes are introduced. When your cluster grows, consider separating dedicated master-eligible nodes from dedicated data nodes. We recommend using at least 4GB RAM for dedicated master nodes.
+A high availability (HA) cluster requires at least three master-eligible nodes. For clusters that have fewer than six {{es}} nodes, any data node in the hot tier will also be a master-eligible node. You can achieve this by having hot nodes (serving as both data and master-eligible nodes) in three availability zones, or by having data nodes in two zones and a tiebreaker (will be automatically added if you choose two zones). For clusters that have six {{es}} nodes and beyond, dedicated master-eligible nodes are introduced. When your cluster grows, consider separating dedicated master-eligible nodes from dedicated data nodes. We recommend using at least 4GB RAM for dedicated master nodes.
 
 The data in your {{es}} clusters is also backed up every 30 minutes, 4 hours, or 24 hours, depending on which snapshot interval you choose. These regular intervals provide an extra level of redundancy. We do support [snapshot and restore](../../../deploy-manage/tools/snapshot-and-restore.md), regardless of whether you use one, two, or three availability zones. However, with only a single availability zone and in the event of an outage, it might take a while for your cluster come back online. Using a single availability zone also leaves your cluster exposed to the risk of data loss, if the backups you need are not useable (failed or partial snapshots missing the indices to restore) or no longer available by the time that you realize that you might need the data (snapshots have a retention policy).
 
 ## Important considerations
 
-::::{warning} 
 * Clusters that use only one availability zone are not highly available and are at risk of data loss. To safeguard against data loss, you must use at least two availability zones.
 * Indices with no replica, except for searchable snapshot indices, are not highly available. You should use replicas to mitigate against possible data loss.
 * Clusters that only have one master node are not highly available and are at risk of data loss. You must have three master-eligible nodes.
-::::
 
 
 

deploy-manage/production-guidance/kibana-in-production-environments.md

@@ -22,7 +22,7 @@ Additionally, the task manager enables distributed coordination across multiple
 
 ::::{important} 
 * {{kib}} does not support rolling [upgrades](/deploy-manage/upgrade/deployment-or-cluster/kibana.md), and deploying mixed versions of {{kib}} can result in data loss or upgrade failures. Please shut down all instances of {{kib}} before performing an upgrade, and ensure all running {{kib}} instances have matching versions.
-* While {{kib}} isn’t terribly resource intensive, we still recommend running {{kib}} separate from  your {{es}} data or master nodes.
+* While {{kib}} isn’t resource intensive, we still recommend running {{kib}} separate from  your {{es}} data or master nodes.
 ::::
 
 ## Section overview
@@ -54,7 +54,7 @@ deployment:
   self: all
 ```
 
-To run multiple {{kib}} instances connected to the same {{es}} cluster, you need to adjust the configuration. See [Configuring {{kib}}](../deploy/self-managed/configure-kibana.md) for details on each setting.
+To run multiple {{kib}} instances connected to the same {{es}} cluster, you need to adjust the configuration. See the [{{kib}} configuration reference](kibana://reference/configuration-reference) for details on each setting.
 
 ::::{note}
 When adding multiple {{kib}} instances to the same deployment in {{ech}}, {{ece}}, or {{eck}}, the orchestrator applies the necessary configuration, requiring no manual setup.
@@ -132,10 +132,12 @@ elasticsearch.hosts:
   - http://elasticsearch2:9200
 ```
 
-Related configurations include `elasticsearch.sniffInterval`, `elasticsearch.sniffOnStart`, and `elasticsearch.sniffOnConnectionFault`. These can be used to automatically update the list of hosts as a cluster is resized.  Parameters can be found on the [settings page](kibana://reference/configuration-reference/general-settings.md).
+Related configurations include `elasticsearch.sniffInterval`, `elasticsearch.sniffOnStart`, and `elasticsearch.sniffOnConnectionFault`. These can be used to automatically update the list of hosts as a cluster is resized.  Parameters can be found in the [{{kib}} configuration reference](kibana://reference/configuration-reference/general-settings.md).
 
 ::::{note}
-The previous configuration can be useful when there is no load balancer or reverse proxy in front of {{es}}. If a load balancer is in place to distribute traffic among {{es}} instances, Kibana should be configured to connect to it instead. In orchestrated deployments, {{kib}} is automatically configured to connect to {{es}} through a load-balanced service.
+The previous configuration can be useful when there is no load balancer or reverse proxy in front of {{es}}. If a load balancer is in place to distribute traffic among {{es}} instances, Kibana should be configured to connect to it instead. 
+
+In [orchestrated deployments](/deploy-manage/deploy.md#about-orchestration), {{kib}} is automatically configured to connect to {{es}} through a load-balanced service.
 ::::
 
 ## Memory [memory] 

deploy-manage/production-guidance/kibana-reporting-production-considerations.md

@@ -10,7 +10,7 @@ applies_to:
 # Kibana reporting production considerations [reporting-production-considerations]
 
 
-To generate reports, {{kib}} uses the Chromium web browser, which runs on the server in headless mode. Chromium is an open-source project not related to Elastic, and is embedded into {{kib}}. Chromium may require [additional OS dependencies](/deploy-manage/kibana-reporting-configuration.md#install-reporting-packages) to run properly.
+To generate [reports](/explore-analyze/report-and-share.md), {{kib}} uses the Chromium web browser, which runs on the server in headless mode. Chromium is an open-source project not related to Elastic, and is embedded into {{kib}}. Chromium may require [additional OS dependencies](/deploy-manage/deploy/kibana-reporting-configuration.md#install-reporting-packages) to run properly.
 
 ::::{note} 
 Chromium is not embedded into {{kib}} for the Darwin (Mac OS) architecture. When running on Darwin, Reporting will download Chromium into the proper area of the {{kib}} installation path the first time the server starts. To separately download and install the browser, see [Manually install the Chromium browser for Darwin](../../explore-analyze/report-and-share/reporting-troubleshooting-pdf.md#reporting-manual-chromium-install).

deploy-manage/production-guidance/optimize-performance.md

@@ -25,6 +25,4 @@ This section provides recommendations for various use cases.
 * [Tune approximate kNN search](optimize-performance/approximate-knn-search.md)
 * [Tune for disk usage](optimize-performance/disk-usage.md)
 
-% this one has been moved to manage data, not sure if it makes sense to mention here, as it's not about performance or prod recommendations
-% * [Use {{es}} for time series data](../../manage-data/use-case-use-elasticsearch-to-manage-time-series-data.md)
 

deploy-manage/reference-architectures/hotfrozen-high-availability.md

@@ -47,7 +47,7 @@ We use an Availability Zone (AZ) concept in the architecture above. When running
 ::::
 
 
-The diagram illustrates an {{es}} cluster deployed across 3 availability zones (AZ). For production we recommend a minimum of 2 availability zones and 3 availability zones for mission critical applications. See [Plan for production](/deploy-manage/production-guidance.md) for more details. A cluster that is running in {{ecloud}} that has data nodes in only two AZs will create a third master-eligible node in a third AZ. High availability cannot be achieved without three zones for any distributed computing technology.
+The diagram illustrates an {{es}} cluster deployed across 3 availability zones (AZ). For production we recommend a minimum of 2 availability zones and 3 availability zones for mission critical applications. See [](/deploy-manage/production-guidance/availability-and-resilience/resilience-in-ech.md) for more details. A cluster that is running in {{ecloud}} that has data nodes in only two AZs will create a third master-eligible node in a third AZ. High availability cannot be achieved without three zones for any distributed computing technology.
 
 The number of data nodes shown for each tier (hot and frozen) is illustrative and would be scaled up depending on ingest volume and retention period. Hot nodes contain both primary and replica shards. By default, primary and replica shards are always guaranteed to be in different availability zones in {{ech}}, but when self-deploying [shard allocation awareness](../distributed-architecture/shard-allocation-relocation-recovery/shard-allocation-awareness.md) would need to be configured. Frozen nodes act as a large high-speed cache and retrieve data from the snapshot store as needed.