Merge branch 'main' into profiling-updates

mdbirnstiehl · web-flow · commit 7b36dcde5763 · 2025-11-21T14:23:09.000-06:00
diff --git a/deploy-manage/cloud-organization/billing/cloud-hosted-deployment-billing-dimensions.md b/deploy-manage/cloud-organization/billing/cloud-hosted-deployment-billing-dimensions.md
@@ -30,7 +30,7 @@ Deployment capacity typically constitutes the majority of your bill, and is the
 
 ### How can I control the deployment capacity cost? [ec_how_can_i_control_the_deployment_capacity_cost] 
 
-Deployment capacity is purely a function of your current deployment configuration and time.  To reduce this cost, you must [configure your deployment](../../deploy/elastic-cloud/configure.md) to use fewer resources.  To determine how much a particular deployment configuration will cost, try our [pricing calculator](https://cloud.elastic.co/pricing).
+Deployment capacity is purely a function of your current deployment configuration and time.  To reduce this cost, you must [configure your deployment](../../deploy/elastic-cloud/configure.md) to use fewer resources.  To determine how much a particular deployment configuration will cost, try our {{ech}} [pricing calculator](https://cloud.elastic.co/pricing).
 
 
 ## Data Transfer [data-transfer] 
diff --git a/deploy-manage/cloud-organization/billing/elasticsearch-billing-dimensions.md b/deploy-manage/cloud-organization/billing/elasticsearch-billing-dimensions.md
@@ -33,7 +33,7 @@ For detailed {{es-serverless}} project rates, refer to the [{{es-serverless}} pr
 * **Indexing:** The VCUs used to index incoming documents. Indexing VCUs account for compute resources consumed for ingestion. This is based on ingestion rate and amount of data ingested at any given time. Transforms and ingest pipelines also contribute to ingest VCU consumption.
 * **Search:** The VCUs used to return search results with the latency and queries per second (QPS) you require. Search VCUs are calculated as a factor of the compute resources needed to run search queries, search throughput, and latency. Search VCUs are not charged per search request. Instead, they are a factor of the compute resources that scale up and down based on amount of searchable data, search load (QPS), and performance (latency and availability).
 * **Machine learning:** The VCUs used to perform inference, NLP tasks, and other ML activities. ML VCUs are a factor of the models deployed and number of ML operations such as inference for search and ingest. ML VCUs are typically consumed for generating embeddings during ingestion and during semantic search or reranking.
-* **Tokens:** The Elastic Managed LLM is charged per 1 million input and output tokens. The LLM powers all AI Search features such as Playground and AI Assistant for Search and is enabled by default.
+* **Tokens:** [The Elastic Inference Service](https://www.elastic.co/docs/explore-analyze/elastic-inference/eis) is charged based on tokens used with machine learning models. For embeddings and rerankers, usage is billed per million input tokens sent to the models. For LLMs, this is either per 1 million input or per 1 million output tokens. Elastic Managed LLMs can power all AI Search features (such as Playground and AI Assistant for Search), as well as features in the Security and Observability products, and are enabled by default.
 
 ## Data storage and billing [elasticsearch-billing-information-about-the-search-ai-lake-dimension-gb]
 
diff --git a/deploy-manage/cloud-organization/billing/serverless-project-billing-dimensions.md b/deploy-manage/cloud-organization/billing/serverless-project-billing-dimensions.md
@@ -15,7 +15,7 @@ products:
 * [Offerings](#offerings)
 * [Add-ons](#add-ons)
 
-Specific prices can be found in the [Cloud Pricing Table](https://cloud.elastic.co/cloud-pricing-table?productType=serverless).
+Specific prices can be found in the [Cloud Pricing Table](https://cloud.elastic.co/cloud-pricing-table?productType=serverless) or you can create an [Elastic Cloud Serverless Estimate](https://cloud.elastic.co/pricing/serverless).
 
 ## Offerings [offerings] 
 
diff --git a/deploy-manage/deploy/cloud-enterprise/resize-deployment.md b/deploy-manage/deploy/cloud-enterprise/resize-deployment.md
@@ -34,7 +34,7 @@ To resize a deployment:
         ::::
 
     RAM per instance
-    :   Node and instance capacity should be sufficient to sustain your search workload, even if you lose an availability zone. Currently, half of the memory is assigned to the JVM heap. For example, on an {{es}} cluster node with 32 GB RAM, 16 GB would be allotted to heap. Up to 64 GB RAM and 1 TB storage per node are supported.
+    :   Node and instance capacity should be sufficient to sustain your search workload, even if you lose an availability zone. For instances up to 64 GB of RAM, half the memory is assigned to the JVM heap. For instances larger than 64 GB, the heap size is capped at 32 GB. For example, on an {{es}} cluster node with 32 GB RAM, 16 GB would be allotted to heap, while on a 128 GB node, 32 GB would be allotted to heap. Up to 256 GB RAM and 1 TB storage per node are supported.
 
     Before finalizing your changes, you can review the **Architecture** summary, which shows the total number of instances per zone, with each circle color representing a different type of instance.
 
diff --git a/deploy-manage/deploy/elastic-cloud/ec-customize-deployment-components.md b/deploy-manage/deploy/elastic-cloud/ec-customize-deployment-components.md
@@ -31,7 +31,7 @@ To change a cluster’s topology, from deployment management, select **Edit depl
 
 For trials, larger sizes are not available until you [add a credit card](../../cloud-organization/billing/add-billing-details.md).
 
-Currently, half the memory is assigned to the JVM heap (a bit less when monitoring is activated). For example, on a 32 GB cluster, 16 GB are allotted to heap. The disk-to-RAM ratio currently is 1:24, meaning that you get 24 GB of storage space for each 1 GB of RAM. All clusters are backed by SSD drives.
+For instances up to 64 GB of RAM, half the memory is assigned to the JVM heap (a bit less when monitoring is activated). For instances larger than 64 GB, the heap size is capped at 32 GB. For example, on a 32 GB instance, 16 GB are allotted to heap, while on a 128 GB instance, 32 GB are allotted to heap. Up to 256 GB RAM per instance is supported. The disk-to-RAM ratio currently is 1:24, meaning that you get 24 GB of storage space for each 1 GB of RAM. All clusters are backed by SSD drives.
 
 ::::{tip}
 For production systems, each {{es}} instance in your cluster should have at least 4 GB of RAM, which assigns 2 GB to the JVM heap. Review [Minimum size recommendations for production use](elastic-cloud-hosted-planning.md#ec-minimum-recommendations) for more details.
diff --git a/explore-analyze/machine-learning/anomaly-detection/ml-limitations.md b/explore-analyze/machine-learning/anomaly-detection/ml-limitations.md
@@ -11,7 +11,7 @@ products:
 
 # Anomaly detection limitations [ml-limitations]
 
-The following limitations and known problems apply to the {{version.stack}} release of the Elastic {{ml-features}}. The limitations are grouped into four categories:
+The following limitations and known problems apply to the Elastic {{ml-features}}. The limitations are grouped into four categories:
 
 * [Platform limitations](#ad-platform-limitations) are related to the platform that hosts the {{ml}} feature of the {{stack}}.
 * [Configuration limitations](#ad-config-limitations) apply to the configuration process of the {{anomaly-jobs}}.
diff --git a/explore-analyze/machine-learning/data-frame-analytics/ml-dfa-limitations.md b/explore-analyze/machine-learning/data-frame-analytics/ml-dfa-limitations.md
@@ -11,7 +11,7 @@ products:
 
 # Data frame analytics limitations [ml-dfa-limitations]
 
-The following limitations and known problems apply to the {{version.stack}} release of the Elastic {{dfanalytics}} feature. The limitations are grouped into the following categories:
+The following limitations and known problems apply to the Elastic {{dfanalytics}} feature. The limitations are grouped into the following categories:
 
 * [Platform limitations](#dfa-platform-limitations) are related to the platform that hosts the {{ml}} feature of the {{stack}}.
 * [Configuration limitations](#dfa-config-limitations) apply to the configuration process of the {{dfanalytics-jobs}}.
diff --git a/explore-analyze/machine-learning/nlp/ml-nlp-limitations.md b/explore-analyze/machine-learning/nlp/ml-nlp-limitations.md
@@ -11,7 +11,7 @@ products:
 
 # NLP limitations [ml-nlp-limitations]
 
-The following limitations and known problems apply to the {{version.stack}} release of the Elastic {{nlp}} trained models feature.
+The following limitations and known problems apply to the Elastic {{nlp}} trained models feature.
 
 ## Document size limitations when using `semantic_text` fields [ml-nlp-large-documents-limit-10k-10mb]
 
diff --git a/explore-analyze/transforms/transform-limitations.md b/explore-analyze/transforms/transform-limitations.md
@@ -11,7 +11,7 @@ products:
 
 # {{transforms-cap}} limitations [transform-limitations]
 
-The following limitations and known problems apply to the {{version.stack}} release of the Elastic {{transform}} feature. The limitations are grouped into the following categories:
+The following limitations and known problems apply to the Elastic {{transform}} feature. The limitations are grouped into the following categories:
 
 * [Configuration limitations](#transform-config-limitations) apply to the configuration process of the {{transforms}}.
 * [Operational limitations](#transform-operational-limitations) affect the behavior of the {{transforms}} that are running.
diff --git a/reference/fleet/running-on-kubernetes-managed-by-fleet.md b/reference/fleet/running-on-kubernetes-managed-by-fleet.md
@@ -60,7 +60,7 @@ Download the manifest file, substituting `{agent_version}` with the version numb
 curl -L -O https://raw.githubusercontent.com/elastic/elastic-agent/refs/tags/v{agent_version}/deploy/kubernetes/elastic-agent-managed-kubernetes.yaml
 ```
 
-For example, to download the manifest of the latest {{version.stack}} release:
+For example, to download the manifest of the latest release:
 
 ```sh subs=true
 curl -L -O https://raw.githubusercontent.com/elastic/elastic-agent/refs/tags/v{{version.stack}}/deploy/kubernetes/elastic-agent-managed-kubernetes.yaml
diff --git a/solutions/observability/apm/index.md b/solutions/observability/apm/index.md
@@ -26,4 +26,4 @@ Metrics are another vital source of information when debugging production system
 
 ## Give Elastic APM a try [give_elastic_apm_a_try]
 
-Want to quickly spin up an APM deployment? Refer to [Get started for APM](/solutions/observability/apm/get-started.md). To host everything yourself instead, refer to [Set up APM Server](/solutions/observability/apm/apm-server/setup.md).
+Want to quickly spin up an APM deployment? Refer to [Get started for APM](/solutions/observability/apm/get-started.md). We recommend using the [Elastic Distributions of OpenTelemetry (EDOT)](/solutions/observability/apm/opentelemetry/index.md) to collect application telemetry data. To host everything yourself instead, refer to [Set up APM Server](/solutions/observability/apm/apm-server/setup.md).
diff --git a/solutions/observability/cicd.md b/solutions/observability/cicd.md
@@ -2,6 +2,8 @@
 navigation_title: CI/CD
 mapped_pages:
   - https://www.elastic.co/guide/en/observability/current/ci-cd-observability.html
+applies_to:
+  stack: ga
 products:
   - id: observability
 ---
@@ -18,14 +20,18 @@ To provide monitoring dashboards, alerting, and root cause analysis on pipelines
 
 ## CI/CD observability architectures [ci-cd-architecture]
 
-Using the APM Server, connect all your OpenTelemetry native CI/CD tools directly to Elastic {{observability}}.
+Use the {{apm-server}} to connect all your OpenTelemetry native CI/CD tools directly to Elastic {{observability}}.
+
+:::{tip}
+We recommend using the [{{edot}} Collector](opentelemetry://reference/index.md) to collect CI/CD observability data.
+:::
 
 :::{image} /solutions/images/observability-simple-arch-observability.png
 :alt: Simple architecture of CI/CD observability with Elastic
 :title: Architecture of CI/CD observability with Elastic
 :::
 
-A more advanced CI/CD observability architecture includes an OpenTelemetry Collector deployed on the edge, next to the CI/CD tools. This architecture provides the following:
+A more advanced CI/CD observability architecture includes an [{{edot}} Collector](opentelemetry://reference/index.md) deployed on the edge, next to the CI/CD tools. This architecture provides the following:
 
 * Low latency between the CI/CD tools and the collector is particularly beneficial to ephemeral tools like the otel-cli.
 * The ability to route the observability signals to multiple backends in addition to Elastic {{observability}}.
diff --git a/solutions/observability/infra-and-hosts.md b/solutions/observability/infra-and-hosts.md
@@ -17,6 +17,10 @@ products:
 
 Explore the topics in this section to learn how to observe and monitor hosts and other systems running in your environment.
 
+:::{tip}
+We recommend using the [Elastic Distribution of OpenTelemetry (EDOT) Collector](/solutions/observability/get-started/quickstart-monitor-hosts-with-opentelemetry.md) to collect infrastructure metrics and logs. You can also use the [Elastic Agent](/solutions/observability/infra-and-hosts/get-started-with-system-metrics.md) with integrations for infrastructure monitoring.
+:::
+
 |     |     |
 | --- | --- |
 | [Analyze infrastructure and host metrics](/solutions/observability/infra-and-hosts/analyze-infrastructure-host-metrics.md) | Visualize infrastructure metrics to help diagnose problematic spikes, identify high resource utilization, automatically discover and track pods, and unify your metrics with other observability data. |
diff --git a/solutions/observability/infra-and-hosts/analyze-infrastructure-host-metrics.md b/solutions/observability/infra-and-hosts/analyze-infrastructure-host-metrics.md
@@ -14,7 +14,9 @@ products:
 
 Observability allows you to visualize infrastructure metrics to help diagnose problematic spikes, identify high resource utilization, automatically discover and track pods, and unify your metrics with logs and APM data.
 
-Using {{agent}} integrations, you can ingest and analyze metrics from servers, Docker containers, Kubernetes orchestrations, explore and analyze application telemetry, and more.
+:::{tip}
+We recommend using the [Elastic Distribution of OpenTelemetry (EDOT) Collector](/solutions/observability/get-started/quickstart-monitor-hosts-with-opentelemetry.md) to collect infrastructure metrics. You can also use {{agent}} integrations to ingest and analyze metrics from servers, Docker containers, {{k8s}} deployments, and more.
+:::
 
 For more information, refer to the following links:
 
diff --git a/solutions/observability/logs/ecs-formatted-application-logs.md b/solutions/observability/logs/ecs-formatted-application-logs.md
@@ -3,16 +3,20 @@ mapped_pages:
   - https://www.elastic.co/guide/en/observability/current/logs-ecs-application.html
   - https://www.elastic.co/guide/en/serverless/current/observability-ecs-application-logs.html
 applies_to:
-  stack: all
-  serverless: all
+  stack: ga
+  serverless: ga
 products:
   - id: observability
   - id: cloud-serverless
 ---
 
 # ECS formatted application logs [logs-ecs-application]
 
-Logs formatted in Elastic Common Schema (ECS) don’t require manual parsing, and the configuration can be reused across applications. ECS-formatted logs, when paired with an {{apm-agent}}, allow you to correlate logs to easily view logs that belong to a particular trace.
+Logs formatted in {{product.ecs}} don't require manual parsing, and the same ingest configuration can be reused across applications. ECS-formatted logs, when paired with an {{apm-agent}} or [{{edot}} SDKs](opentelemetry://reference/edot-sdks/index.md), allow you to correlate logs to easily view logs that belong to a particular trace.
+
+:::{tip}
+We recommend using the [{{edot}} SDKs](opentelemetry://reference/edot-sdks/index.md) to instrument your applications and collect ECS-formatted logs with automatic log correlation. You can also format your logs in ECS format.
+:::
 
 You can format your logs in ECS format the following ways:
 
diff --git a/solutions/observability/logs/plaintext-application-logs.md b/solutions/observability/logs/plaintext-application-logs.md
@@ -3,8 +3,8 @@ mapped_pages:
   - https://www.elastic.co/guide/en/observability/current/logs-plaintext.html
   - https://www.elastic.co/guide/en/serverless/current/observability-plaintext-application-logs.html
 applies_to:
-  stack: all
-  serverless: all
+  stack: ga
+  serverless: ga
 products:
   - id: observability
   - id: cloud-serverless
@@ -31,7 +31,11 @@ To ingest, parse, and correlate plaintext logs:
 Send application logs to {{es}} using one of the following shipping tools:
 
 * [{{filebeat}}](/solutions/observability/logs/plaintext-application-logs.md#ingest-plaintext-logs-with-filebeat) A lightweight data shipper that sends log data to {{es}}.
-* [{{agent}}](/solutions/observability/logs/plaintext-application-logs.md#ingest-plaintext-logs-with-the-agent) A single agent for logs, metrics, security data, and threat prevention. Combined with Fleet, you can centrally manage {{agent}} policies and lifecycles directly from {{kib}}.
+* [{{agent}}](/solutions/observability/logs/plaintext-application-logs.md#ingest-plaintext-logs-with-the-agent) A single agent that can collect logs, metrics, and security data, and protect your hosts. You can use {{fleet}} to manage {{agent}} policies and lifecycles directly from {{kib}}.
+
+:::{tip}
+We recommend using the [{{edot}} Collector](/solutions/observability/logs/stream-any-log-file-using-edot-collector.md) to collect application logs.
+:::
 
 
 ### Ingest logs with {{filebeat}} [ingest-plaintext-logs-with-filebeat]
diff --git a/solutions/search/agent-builder/limitations-known-issues.md b/solutions/search/agent-builder/limitations-known-issues.md
@@ -40,7 +40,16 @@ Error: Invalid function call syntax
 Error executing agent: No tool calls found in the response.
 ```
 
-$$$conversation-length-exceeded$$$
+### Context length exceeded error [conversation-length-exceeded]
+
+This error occurs when a conversation exceeds the maximum context length supported by the LLM. This typically happens when tools return large responses that consume the available token budget.
+
+To mitigate this issue, consider the following strategies:
+
+- **Optimize queries**: Narrow your questions to reduce the scope of data retrieval
+- **Start a new conversation**: Begin a fresh conversation, optionally providing a summary of the previous context
+- **Refine tool descriptions**: Update tool descriptions and agent instructions to guide the agent toward requesting only essential data
+- **Limit tool response size**: Create custom tools that filter or paginate data to return smaller, focused datasets
 
 ### {{esql}} limitations
 
diff --git a/troubleshoot/deployments/cloud-enterprise/node-bootlooping.md b/troubleshoot/deployments/cloud-enterprise/node-bootlooping.md
@@ -106,7 +106,7 @@ To view any added plugins or bundles:
 
 ## OOM errors [ece-config-change-errors-oom-errors]
 
-Configuration change errors can occur when there is insufficient RAM configured for a data tier. In this case, the cluster typically also shows OOM (out of memory) errors. To resolve these, you need to increase the amount of heap memory, which is half of the amount of memory allocated to a cluster. You might also detect OOM in plan changes via their [related exit codes](/deploy-manage/maintenance/start-stop-services/start-stop-elasticsearch.md#fatal-errors) `127`, `137`, and `158`.
+Configuration change errors can occur when there is insufficient RAM configured for a data tier. In this case, the cluster typically also shows OOM (out of memory) errors. To resolve these, you need to increase the amount of heap memory. For instances up to 64 GB of RAM, heap memory is half of the total memory allocated. For instances larger than 64 GB, the heap size is capped at 32 GB. You might also detect OOM in plan changes via their [related exit codes](/deploy-manage/maintenance/start-stop-services/start-stop-elasticsearch.md#fatal-errors) `127`, `137`, and `158`.
 
 You can also read our detailed blog [Managing and troubleshooting {{es}} memory](https://www.elastic.co/blog/managing-and-troubleshooting-elasticsearch-memory).
 
diff --git a/troubleshoot/monitoring/node-bootlooping.md b/troubleshoot/monitoring/node-bootlooping.md
@@ -140,7 +140,7 @@ To view any added plugins or bundles:
 
 ## OOM errors [ec-config-change-errors-oom-errors]
 
-Configuration change errors can occur when there is insufficient RAM configured for a data tier. In this case, the cluster typically also shows OOM (out of memory) errors. To resolve these, you need to increase the amount of heap memory, which is half of the amount of memory allocated to a cluster. You might also detect OOM in plan changes via their [related exit codes](/deploy-manage/maintenance/start-stop-services/start-stop-elasticsearch.md#fatal-errors) `127`, `137`, and `158`.
+Configuration change errors can occur when there is insufficient RAM configured for a data tier. In this case, the cluster typically also shows OOM (out of memory) errors. To resolve these, you need to increase the amount of heap memory. For instances up to 64 GB of RAM, heap memory is half of the total memory allocated. For instances larger than 64 GB, the heap size is capped at 32 GB. You might also detect OOM in plan changes via their [related exit codes](/deploy-manage/maintenance/start-stop-services/start-stop-elasticsearch.md#fatal-errors) `127`, `137`, and `158`.
 
 Check the [{{es}} cluster size](/deploy-manage/deploy/elastic-cloud/ec-customize-deployment-components.md#ec-cluster-size) and the [JVM memory pressure indicator](/deploy-manage/monitor/ec-memory-pressure.md) documentation to learn more.
 
