Merge branch 'main' into 232/ui-dlm-lifecycle

Author: kilfoyle

deploy-manage/security/fips-ingest.md

@@ -85,14 +85,23 @@ When you use {{agent}} and {{fleet-server}}, these limitations apply:
 * Running {{agent}} in [OpenTelemetry mode](https://github.com/elastic/elastic-agent/blob/main/internal/pkg/otel/README.md) is not yet supported. This includes all receivers, such as Filebeat Receiver, Metricbeat Receiver, [Prometheus Receiver](https://www.elastic.co/docs/reference/integrations/prometheus).
 * Some Elastic Integrations are not FIPS compatible, as they depend on functionality that is not yet supported for FIPS configuration. In general, when using {{agent}} and {{fleet-server}}, the same restrictions listed previously for {{metricbeat}} and {{filebeat}} modules, inputs, and processors apply.
 
-  These Elastic Integrations have components that are **not** FIPS compatible, and **cannot** be used in FIPS environments, even if combined with other ingest tools that offer FIPS mode. 
-
-  - [Azure Logs Integration (v2 preview)](integration-docs://reference/azure/events.md)
-  - [Azure Event Hub Input](integration-docs://reference/azure/eventhub.md)
-  - [SQL Input](integration-docs://reference/sql.md) 
-  - [PostgreSQL Integration](integration-docs://reference/postgresql.md)
-  - [MongoDB Integration](integration-docs://reference/mongodb.md)
-  - [MySQL Integration](integration-docs://reference/mysql.md)
-  - [Microsoft SQL Server Integration](integration-docs://reference/microsoft_sqlserver.md)
-  - [Oracle Integration](integration-docs://reference/oracle.md)
-
+### Elastic Integrations that are not FIPS compatible [ingest-limitations-integrations]
+
+These Elastic Integrations have components that are **not** FIPS compatible, and **cannot** be used in FIPS environments, even if combined with other ingest tools that offer FIPS mode. 
+
+- [Azure Logs Integration (v2 preview)](integration-docs://reference/azure/events.md)
+- [Azure Event Hub Input](integration-docs://reference/azure/eventhub.md)
+- [Azure AI Foundry Integration](integration-docs://reference/azure_ai_foundry.md)
+- [Azure App Service Integration](integration-docs://reference/azure_app_service.md)
+- [Azure Application Insights Integration](integration-docs://reference/azure_application_insights.md)
+- [Azure Billing Metrics Integration](integration-docs://reference/azure_billing.md)
+- [Azure Functions Integration](integration-docs://reference/azure_functions.md)
+- [Custom Azure Logs Integration](integration-docs://reference/azure_logs.md)
+- [Azure Resource Metrics Integration](integration-docs://reference/azure_metrics.md)
+- [Azure OpenAI Integration](integration-docs://reference/azure_openai.md)
+- [SQL Input](integration-docs://reference/sql.md) 
+- [PostgreSQL Integration](integration-docs://reference/postgresql.md)
+- [MongoDB Integration](integration-docs://reference/mongodb.md)
+- [MySQL Integration](integration-docs://reference/mysql.md)
+- [Microsoft SQL Server Integration](integration-docs://reference/microsoft_sqlserver.md)
+- [Oracle Integration](integration-docs://reference/oracle.md)

deploy-manage/upgrade/orchestrator/upgrade-cloud-on-k8s.md

@@ -101,8 +101,11 @@ This will update the ECK installation to the latest binary and update the CRDs a
 Upgrading the operator results in a one-time update to existing managed resources in the cluster. This potentially triggers a rolling restart of pods by Kubernetes to apply those changes. The following list contains the ECK operator versions that would cause a rolling restart after they have been installed.
 
 ```
-1.6, 1.9, 2.0, 2.1, 2.2, 2.4, 2.5, 2.6, 2.7, 2.8, 2.14
+1.6, 1.9, 2.0, 2.1, 2.2, 2.4, 2.5, 2.6, 2.7, 2.8, 2.14, 3.1 <1>
 ```
+
+1. The restart when upgrading to version 3.1 happens only for applications using [stack monitoring](/deploy-manage/monitor/stack-monitoring/eck-stack-monitoring.md).
+
 ::::{note}
 Stepping over one of these versions, for example, upgrading ECK from 2.6 to 2.9, still triggers a rolling restart.
 ::::

explore-analyze/ai-assistant.md

@@ -12,31 +12,33 @@ applies_to:
 products:
   - id: kibana
   - id: observability
+  - id: security
   - id: cloud-serverless
 ---
 
 # AI assistant
 
 $$$token-limits$$$
 
-**AI Assistant** is a chat-based interactive tool to help you with a variety of tasks related to Elasticsearch and Kibana, including:
+**AI Assistant** is a chat-based interactive tool that can help with a variety of tasks throughout Elasticsearch and Kibana, including:
 
 - **Constructing queries**: Assists you in building queries to search and analyze your data, including converting queries from other languages to [ES|QL](query-filter/languages/esql.md).
 - **Indexing data**: Guides you on how to index data into Elasticsearch.
 - **Using APIs**: Calls Elasticsearch APIs on your behalf if you need specific operations performed.
 - **Generating sample data**: Helps you create sample data for testing and development purposes.
 - **Visualizing and analyzing data**: Assists you in creating visualizations and analyzing your data using Kibana.
 - **Troubleshooting**: Explains errors, messages, and suggests remediation.
+- **Investigating threats**: Helps analyze potential attacks, provides threat research, and assists with alert triage.
 
-AI Assistant requires specific privileges and a generative AI connector.
-
-% Check [Configure AI Assistant](../deploy-manage/) for more details on how to enable and configure it.
-
-The capabilities and ways to interact with AI Assistant can differ for each solution. Find more information in the respective solution docs:
+AI Assistant requires specific privileges and a large language model (LLM) connector. The capabilities and ways to interact with AI Assistant can differ for each solution. To learn more about how it works in each solution, refer to:
 
 - [{{obs-ai-assistant}}](../solutions/observability/observability-ai-assistant.md)
 - [AI Assistant for Security](../solutions/security/ai/ai-assistant.md)
 
+To learn more about configuring LLM connectors, refer to:
+
+- [Enable LLM access](../solutions/security/ai/set-up-connectors-for-large-language-models-llm.md)
+
 ## Prompt best practices [rag-for-esql]
 Elastic AI Assistant allows you to take full advantage of the Elastic platform to improve your operations. It can help you write an ES|QL query for a particular use case, or answer general questions about how to use the platform. Its ability to assist you depends on the specificity and detail of your questions. The more context and detail you provide, the more tailored and useful its responses will be.
 

explore-analyze/query-filter.md

@@ -26,8 +26,7 @@ You’ll use a combination of an API endpoint and a query language to interact w
 
 - A number of [tools](/explore-analyze/query-filter/tools.md) are available for you to save, debug, and optimize your queries.
 
-% todo: update link to the best target
-If you're just getting started with Elasticsearch, try the hands-on [API quickstart](/solutions/search/elasticsearch-basics-quickstart.md) to learn how to add data and run basic searches using Query DSL and the `_search` endpoint.
+If you're just getting started with {{es}}, try the hands-on [](/solutions/search/get-started/index-basics.md) to learn how to add data and run basic searches using Query DSL and the `_search` endpoint.
 
 ## Filtering
 

manage-data/ingest/transform-enrich/readable-maintainable-ingest-pipelines.md

@@ -1,4 +1,3 @@
-
 ---
 mapped_pages:
   - https://www.elastic.co/docs/manage-data/ingest/transform-enrich/common-mistakes.html

manage-data/migrate/migrate-data-between-elasticsearch-clusters-with-minimal-downtime.md

@@ -48,11 +48,11 @@ Tp complete the migration with minimal downtime, use incremental snapshots. Whil
 
 1. **09:00**: Take the initial full snapshot of the old cluster. You can also take the initial full snapshot the day before.
 2. **09:30**: Restore the snapshot to the new cluster.
-3. **09:55**: Take another snapshot of the old cluster and restore it to the new cluster. Repeat this process until the snapshot and restore operations take only a few seconds or minutes.
+3. **09:55**: Take another snapshot of the old cluster and restore it to the new cluster. Repeat this process until the snapshot and restore operations take only a few seconds or minutes. Remember that when restoring indices that _already_ exist in the new cluster (for example, to pull in recently copied data), they first need to be [closed](/deploy-manage/tools/snapshot-and-restore/restore-snapshot.md#considerations). Also, remember that the restore operation automatically opens indices, so you will likely need to close the actively written ones after restoring them.
 4. **10:15**: Perform the final cutover.
     1. In the old cluster, pause indexing or set indices to read-only. For details on setting indices to read-only to safely pause indexing during migration, check [Index lifecycle actions: Read-only](elasticsearch://reference/elasticsearch/index-lifecycle-actions/ilm-readonly.md).
     2. Take a final snapshot. 
-    3. Restore the snapshot to the new cluster. 
+    3. Restore the snapshot to the new cluster. Again, remember that to restore indices that already exist, they first need to be closed.
     4. Change ingestion and querying to the new cluster. 
     5. Open the indices in the new cluster. 
 

redirects.yml

@@ -308,3 +308,5 @@ redirects:
   'solutions/security/configure-elastic-defend/enable-access-for-macos-monterey.md': 'solutions/security/configure-elastic-defend/enable-access-for-macos.md'
   'solutions/security/configure-elastic-defend/enable-access-for-macos-ventura-higher.md': 'solutions/security/configure-elastic-defend/enable-access-for-macos.md'
 
+# Related to https://github.com/elastic/docs-content/pull/2245/
+  'solutions/search/elasticsearch-basics-quickstart.md': 'solutions/search/get-started/index-basics.md'

reference/fleet/add-fleet-server-kubernetes.md

@@ -336,7 +336,7 @@ Adapt and change the suggested manifests and deployment strategy to your needs,
           automountServiceAccountToken: false
           containers:
           - name: elastic-agent
-            image: docker.elastic.co/beats/elastic-agent:{{version.stack}}
+            image: docker.elastic.co/elastic-agent:{{version.stack}}
             env:
               - name: FLEET_SERVER_ENABLE
                 value: "true"
@@ -422,7 +422,7 @@ Adapt and change the suggested manifests and deployment strategy to your needs,
           automountServiceAccountToken: false
           containers:
           - name: elastic-agent
-            image: docker.elastic.co/beats/elastic-agent:{{version.stack}}
+            image: docker.elastic.co/elastic-agent:{{version.stack}}
             env:
               - name: FLEET_SERVER_ENABLE
                 value: "true"

release-notes/elastic-cloud-serverless/known-issues.md

@@ -51,7 +51,7 @@ After you complete this step, risk scores should automatically begin to successf
 
 ## Resolved
 
-:::{dropdown} In {{sec-serverless}}, installing an {{elastic-defend}} integration or a new agent policy upgrades installed prebuilt rules, reverting user customizations and overwriting user-added actions and exceptions
+:::{dropdown} Installing the {{elastic-defend}} integration or a new agent policy in {{sec-serverless}} forces an upgrade of prebuilt rules
 
 On April 10, 2025, it was discovered that when you install a new {{elastic-defend}} integration or agent policy, the installed prebuilt detection rules upgrade to their latest versions (if any new versions are available). The upgraded rules lose any user-added rule actions, exceptions, and customizations.