Merge branch 'main' into alxchalkias-dnstxtclaim-samlsso

Author: alxchalkias

deploy-manage/users-roles/cluster-or-deployment-auth/file-based.md

@@ -5,8 +5,8 @@ mapped_pages:
   - https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-users-and-roles.html
 applies_to:
   deployment:
-    self: all
-    eck: all
+    self: ga
+    eck: ga
 products:
   - id: elasticsearch
   - id: cloud-kubernetes
@@ -16,11 +16,7 @@ products:
 
 You can manage and authenticate users with the built-in `file` realm. With the `file` realm, users are defined in local files on each node in the cluster.
 
-The `file` realm is useful as a fallback or recovery realm. For example in cases where the cluster is unresponsive or the security index is unavailable, or when you forget the password for your administrative users. In this type of scenario, the `file` realm is a convenient workaround: you can define a new `admin` user in the `file` realm and use it to log in and reset the credentials of all other users.
-
-You can configure only one file realm on {{es}} nodes.
-
-Refer to [enabling a file realm user for recovery](https://www.youtube.com/watch?v=sueO7sz1buw) for a video walkthrough. 
+The `file` realm is useful as a fallback or recovery realm. For example, you might use this realm in cases where the cluster is unresponsive or the security index is unavailable, or when you forget the password for your administrative users. In this type of scenario, the `file` realm is a convenient workaround: you can define a new `admin` user in the `file` realm and use it to log in and reset the credentials of all other users. For a walkthrough of this process, refer to [](/troubleshoot/elasticsearch/file-based-recovery.md). Refer to [enabling a file realm user for recovery](https://www.youtube.com/watch?v=sueO7sz1buw) for a video walkthrough. 
 
 ::::{important}
 * In self-managed deployments, as the administrator of the cluster, it is your responsibility to ensure the same users are defined on every node in the cluster. The {{stack}} {{security-features}} do not deliver any mechanism to guarantee this.
@@ -29,33 +25,27 @@ Refer to [enabling a file realm user for recovery](https://www.youtube.com/watch
 
 ## Configure a file realm [file-realm-configuration]
 
-You don’t need to explicitly configure a `file` realm. The `file` and `native` realms are added to the realm chain by default. Unless configured otherwise, the `file` realm is added first, followed by the `native` realm. You can define only one `file` realm per node.
+You don’t need to explicitly configure a `file` realm. The `file` and `native` realms are added to the realm chain by default. Unless configured otherwise, the `file` realm is added first, followed by the `native` realm. You can define only one `file` realm on each node.
 
 1. (Optional) Add a realm configuration to [`elasticsearch.yml`](/deploy-manage/stack-settings.md) under the `xpack.security.authc.realms.file` namespace. At a minimum, you must set the realm’s `order` attribute.
 
     For example, the following snippet shows a `file` realm configuration that sets the `order` to zero so the realm is checked first:
 
     ```yaml
-    xpack:
-      security:
-        authc:
-          realms:
-            file:
-              file1:
-                order: 0
+    xpack.security.authc.realms.file.file1.order: 0
     ```
 
-2. If you're using a self-managed {{es}} cluster, optionally change how often the `users` and `users_roles` files are checked.
+2. (Optional) For self-managed deployments, you can change how often the `users` and `users_roles` files are checked.
 
     By default, {{es}} checks these files for changes every 5 seconds. You can change this default behavior by changing the `resource.reload.interval.high` setting in the [`elasticsearch.yml`](/deploy-manage/stack-settings.md) file.
 
     :::{{warning}}
     Because `resource.reload.interval.high` is a common setting in {{es}}, changing its value may effect other schedules in the system.
     :::
 
-3. Restart {{es}}.
+3. In self-managed deployments, if either of these settings is modified, perform a [rolling restart](/deploy-manage/maintenance/start-stop-services/full-cluster-restart-rolling-restart-procedures.md#restart-cluster-rolling) of the {{es}} nodes for your changes to take effect. 
 
-   In {{eck}}, this change is propagated automatically.
+    In {{eck}}, changes are automatically propagated.
 
 
 ## Add users
@@ -120,13 +110,13 @@ In a self-managed cluster, you can edit the contents of `ES_PATH_CONF/users` and
 :::{tab-item} {{eck}}
 You can pass `users` and `user_roles` files to {{eck}} using a file realm secret:
 
-```yaml
+```yaml subs=true
 apiVersion: elasticsearch.k8s.elastic.co/v1
 kind: Elasticsearch
 metadata:
   name: elasticsearch-sample
 spec:
-  version: 8.16.1
+  version: {{version.stack}}
   auth:
     fileRealm:
     - secretName: my-filerealm-secret-1

solutions/_snippets/elastic-managed-llm.md

@@ -5,5 +5,5 @@ The Elastic Managed LLM is available out-of-the box; no manual connector setup o
 To learn more about security and data privacy, refer to the [connector documentation](https://www.elastic.co/docs/reference/kibana/connectors-kibana/elastic-managed-llm) and [download the model card](https://raw.githubusercontent.com/elastic/kibana/refs/heads/main/docs/reference/resources/Elastic_Managed_LLM_model_card.pdf).
 
 :::{important}
-Using the Elastic Managed LLM incurs additional costs. Refer to [{{ecloud}} pricing](https://www.elastic.co/pricing) for more information.
+Using the Elastic Managed LLM incurs additional costs. Refer to [{{ecloud}} pricing](https://www.elastic.co/pricing/serverless-search) for more information.
 :::

solutions/observability/incident-management/create-manage-rules.md

@@ -64,7 +64,6 @@ From the action menu you can also:
 * Run rule (without waiting for next scheduled check)
 * Update API keys
 
-
 ## View rule details [observability-create-manage-rules-view-rule-details]
 
 Click on an individual rule on the **{{rules-app}}** page to view details including the rule name, status, definition, execution history, related alerts, and more.
@@ -102,3 +101,15 @@ To temporarily suppress notifications for *all* rules, create a [maintenance win
 To import and export rules, use [{{saved-objects-app}}](/explore-analyze/find-and-organize.md).
 
 Rules are disabled on export. You are prompted to re-enable the rule on successful import.
+
+## Add resources for investigating alerts [observability-create-manage-rules-add-investigation-resources]
+
+When creating or editing a rule, add the following resources to help you get started with investigating alerts:
+
+* {applies_to}`stack: ga 9.1` **Investigation guide**: Investigation guides can help you respond to alerts more efficiently and consistently. When creating them, you can include instructions for responding to alerts, links to external supporting materials, and more. When the rule generates an alert, the investigation guide can be accessed from the **Investigation guide** tab on the alert's details page. 
+
+    ::::{tip}
+    Use Markdown to format and structure text in your investigation guide.
+    ::::
+
+* {applies_to}`stack: ga 9.1` **Related and suggested dashboards**: Link to dashboards that provide useful insights about your environment, active events, and any other information that might be relevant during your investigations. When the rule generates an alert, linked dashboards can be accessed from the **Related dashboards** tab on the alert's details page. From the tab, you can also review and add suggested dashboards (available for custom threshold rules only).

solutions/observability/incident-management/view-alerts.md

@@ -65,6 +65,22 @@ To view the alert in the app that triggered it:
 * From the alert detail flyout, click **View in app**.
 * From the **Alerts** table, click the {icon}`eye` icon.
 
+## Review related alerts [observability-view-alerts-find-related-alerts]
+```{applies_to}
+stack: ga 9.1 
+```
+
+Check related alerts to find other alerts that might be related to the same incident. You can add these alerts to a case and investigate them as a group instead of analyzing them individually.
+
+To find related alerts, go to the **Related alerts** tab from an alert's details page. Within the table, alerts are ordered from most to least relevant. To only view alerts that were created around the same time as the current alert (+/- 30 minutes), apply the **Triggered around the same time** filter.
+
+The relevancy of alerts is determined by how closely they match the current alert and other similiarites that they might share:
+
+1. Alerts in the space are filtered down to only include alerts that were created about one day before or after the current alert. 
+2. Data from the new subset of alerts is compared against the current alert to identify matching values and similarities. Data such as the time at which alerts were generated or recovered, tags added to the alerts, group values, and more are evaluated.
+3. Alerts are scored based on how closely they match the current alert. Alerts with a score above a certain threshold are considered relevant and are included in the list of related alerts.
+
+
 ## Understand alert statuses [observability-view-alerts-understand-statuses]
 
 There are four common alert statuses:

solutions/search/agent-builder/kibana-api.md

@@ -7,8 +7,6 @@ applies_to:
 ---
 
 :::{warning}
-WIP
-
 These pages are hidden from the docs TOC and have `noindexed` meta headers.
 :::
 
@@ -18,7 +16,8 @@ These APIs allow you to programmatically work with the {{agent-builder}} abstrac
 
 ## API reference
 
-For the full API documentation, refer to the [Kibana API reference](https://www.elastic.co/docs/api/doc/kibana/).
+For the full API documentation, refer to the [Kibana serverless API reference](https://www.elastic.co/docs/api/doc/serverless/).
+% TODO: Update link once page is live
 
 ## Using the APIs
 

solutions/search/agent-builder/programmatic-access.md

@@ -7,18 +7,20 @@ applies_to:
 ---
 
 :::{warning}
-WIP
-
 These pages are hidden from the docs TOC and have `noindexed` meta headers.
 :::
 
 # Work programmatically with {{agent-builder}}
 
-{{agent-builder}} provides comprehensive APIs and additional integration options for programmatic access and automation.
+{{agent-builder}} provides comprehensive integration options for programmatic access and automation.
 
 These interfaces enable you to build integrations with other applications and extend Agent Builder's capabilities to fit your specific requirements.
 
-- **[Kibana API](kibana-api.md)**: RESTful APIs for working with {{agent-builder}} programmatically
+:::{tip}
+Most users will probably want to integrate with Agent Builder using MCP or A2A, but you can also work programmatically with tools, agents, and conversations using the Kibana APIs.
+:::
+
 - **[MCP server](mcp-server.md)**: A standardized interface that allows external MCP clients (such as Claude Desktop or Cursor) to access {{agent-builder}} tools
 - **[A2A server](a2a-server.md)**: Agent-to-agent communication endpoints that follow the A2A protocol specification, enabling external A2A clients to interact with {{agent-builder}} agents
+- **[Kibana API](kibana-api.md)**: RESTful APIs for working with {{agent-builder}} programmatically
 

solutions/search/elastic-agent-builder.md

@@ -14,7 +14,9 @@ These pages are hidden from the docs TOC and have `noindexed` meta headers.
 
 # {{agent-builder}} 
 
-{{agent-builder}} is an AI-powered conversation framework for working with {{es}} data using natural language. It features both a chat UI for synchronous interaction and extensive programmatic access through APIs, MCP and A2A servers.
+{{agent-builder}} is a set of AI-powered capabilities for developing and interacting with agents that work with your {{es}} data. Agent Builder simplifies building data-driven agents with intuitive UI and programmatic interfaces, so you don't have to compose the different pieces separately.
+
+You can use the built-in agent for natural language conversations with any {{es}} data or instance, or work programmatically with tools, agents, and conversations using Elastic APIs, MCP, and A2A.
 
 ## Key capabilities
 

troubleshoot/elasticsearch.md

@@ -36,6 +36,7 @@ If you're using {{ech}}, you can use AutoOps to monitor your cluster. AutoOps si
 
 * [](/troubleshoot/elasticsearch/start-ilm.md)
 * [](/troubleshoot/elasticsearch/index-lifecycle-management-errors.md)
+* [](/troubleshoot/elasticsearch/file-based-recovery.md)
 
 ## Capacity [troubleshooting-capacity]