[Observability] Add docs on schema selection for host data

solutions/observability/incident-management/create-an-inventory-rule.md

@@ -31,12 +31,12 @@ When you select **Create inventory alert**, the parameters you configured on the
 
 ::::
 
-
-
 ## Inventory conditions [inventory-conditions]
 
 Conditions for each rule can be applied to specific metrics relating to the inventory type you select. You can choose the aggregation type, the metric, and by including a warning threshold value, you can be alerted on multiple threshold values based on severity scores. When creating the rule, you can still get notified if no data is returned for the specific metric or if the rule fails to query {{es}}.
 
+When creating a rule for `Hosts`, you also need to select a data collection schema in the **Schema** field. Select **Elastic System Integration** for host data collected using the Elastic System Integration or **OpenTelemetry** for host data collected using OpenTelemetry.
+
 In this example, Kubernetes Pods is the selected inventory type. The conditions state that you will receive a critical alert for any pods within the `ingress-nginx` namespace with a memory usage of 95% or above and a warning alert if memory usage is 90% or above. The chart shows the results of applying the rule to the last 20 minutes of data. Note that the chart time range is 20 times the value of the look-back window specified in the `FOR THE LAST` field.
 
 :::{image} /solutions/images/serverless-inventory-alert.png

solutions/observability/infra-and-hosts/analyze-compare-hosts.md

@@ -36,9 +36,12 @@ To learn more about the metrics shown on this page, refer to the [Metrics refere
 ::::{note}
 **Don’t see any metrics?**
 
-If you haven’t added data yet, click **Add data** to search for and install an Elastic integration.
 
-Need help getting started? Follow the steps in [Get started with system metrics](/solutions/observability/infra-and-hosts/get-started-with-system-metrics.md).
+If you haven’t added data yet, click **Add data → Host** and select how you want to monitor your host—OpenTelemetry or Elastic Agent.
+
+For more on collecting host data, refer to:
+* [OpenTelemetry](opentelemetry://reference/edot-collector/config/configure-metrics-collection.md#process-metrics)
+* [Elastic System Integration](integration-docs://reference/system.md)
 
 ::::
 
@@ -152,6 +155,10 @@ To learn more about creating and managing rules, refer to [Alerting](/solutions/
 
 ::::
 
+## Select data collection schema
+
+The **Schema** selector shows the available data collection schemas for the current query. If host data from both the Elastic System Integration and OpenTelemetry are available, the selector defaults to **OpenTelemetry**. Select **Elastic System Integration** to see host data collected using the Elastic System Integration.
+
 
 
 ## View host details [view-host-details]
@@ -402,4 +409,7 @@ When a host is detected by APM, but is not collecting full metrics (for example,
 
 This could mean that the APM agent has not been configured to use the correct host name. Instead, the host name might be the container name or the Kubernetes pod name.
 
-To get the correct host name, you need to set some additional configuration options, specifically `system.kubernetes.node.name` as described in [Kubernetes data](/solutions/observability/apm/managed-intake-service-event-api.md#kubernetes-data).
+To get the correct host name, you need to set some additional configuration options, specifically `system.kubernetes.node.name` as described in [Kubernetes data](/solutions/observability/apm/managed-intake-service-event-api.md#kubernetes-data).
+
+### I don't see all of my host data [observability-analyze-hosts-i-dont-see-all-of-my-host-data]
+If you have host data from both the Elastic System Integration and OpenTelemetry (OTel), the selector defaults to OTel. If you want to see Elastic System Integration data for your current query, select **Elastic System Integration** from the **Schema** selector.

solutions/observability/infra-and-hosts/detect-metric-anomalies.md

@@ -12,17 +12,16 @@ products:
 
 # Detect metric anomalies [observability-detect-metric-anomalies]
 
-::::{note}
-
-**For Observability serverless projects**, the **Editor** role or higher is required to create {{ml}} jobs. To learn more, refer to [Assign user roles and privileges](/deploy-manage/users-roles/cloud-organization/user-roles.md#general-assign-user-roles).
-
-::::
-
-
 You can create {{ml}} jobs to detect and inspect memory usage and network traffic anomalies for hosts and Kubernetes pods.
 
 You can model system memory usage, along with inbound and outbound network traffic across hosts or pods. You can detect unusual increases in memory usage and unusually high inbound or outbound traffic across hosts or pods.
 
+## Prerequisites
+To create ML jobs to detect metric anomalies, you need to meet the following requirements:
+
+* **For Observability serverless projects**, the **Editor** role or higher is required to create {{ml}} jobs. To learn more, refer to [Assign user roles and privileges](/deploy-manage/users-roles/cloud-organization/user-roles.md#general-assign-user-roles).
+* Metric anomaly detection does not work for OpenTelemetry hosts.
+
 
 ## Enable {{ml}} jobs for hosts or Kubernetes pods [ml-jobs-hosts]