Pulling refs/heads/main into main

admin/references/system-limits/sys-limits-infra-details.rst

@@ -490,24 +490,6 @@ Container burst/overage limit
    * :strong:`Customer impact`: If you exceed this limit, Infrastructure Monitoring drops data points from new containers but keeps
      accepting data points for existing containers.
 
-.. _high-resolution-custom-metrics-entitlement:
-
-High resolution custom metrics entitlement
-================================================================================
-
-   * :strong:`Default limit value`: Set by your contract entitlement
-   * :strong:`Notes`: Number of high resolution metrics allowed in your contract
-   * :strong:`Customer impact`: Splunk charges an overage of 1.5 times the normal price for usage that exceeds your contractual entitlement.
-
-.. _high-resolution-custom-metrics-burstoverage-limit:
-
-High resolution custom metrics burst/overage limit
-================================================================================
-
-   * :strong:`Default limit value`: Multiples of entitlement
-   * :strong:`Notes`: This limit is to protect the SaaS platform. It's typically a multiple of your contractual limit. For example, if you purchase 500 hosts, Infrastructure Monitoring might set limit to 800. The multiple decreases as your contractual limit increases.
-   * :strong:`Customer impact`: The system rejects MTS creations for high resolution metrics that exceed the limit.
-
 .. _bundled-mts-limit:
 
 Bundled MTS limit

admin/references/system-limits/sys-limits-infra.rst

@@ -252,12 +252,6 @@ Subscription limits
    * - :ref:`custom-mts-entitlement`
      - Set by your contract entitlement
 
-   * - :ref:`high-resolution-custom-metrics-burstoverage-limit`
-     - Multiples of entitlement
-
-   * - :ref:`high-resolution-custom-metrics-entitlement`
-     - Set by your contract entitlement
-
    * - :ref:`host-burstoverage-limit`
      - Multiples of entitlement
 

alerts-detectors-notifications/alert-condition-reference/heartbeat-check.rst

@@ -17,7 +17,7 @@ Heartbeat Check alerts when a signal has not reported for some time. This might
 Examples
 ============================================================================
 
-You have a detector that alerts you when the minimum number of logins being handled by each host goes below a specified value. If any host stops reporting, that detector isn't triggered if there is a problem. The Heartbeat Check condition notifies you if a host stops reporting.
+You have a detector that alerts you when the minimum number of logins being handled by each host goes below a specified value. If a host stops reporting, that detector isn't triggered if there is a problem. The Heartbeat Check condition notifies you if a host stops reporting, or if all hosts in a group stop reporting.
 
 
 Settings
@@ -35,7 +35,7 @@ Settings
 
    * - :strong:`Hasn't reported for`
      - Integer >= 1, followed by time indicator (s, m, h, d, w). For example, 30s, 10m, 2h, 5d, 1w.
-     - How long it's been since the signal last reported. Longer time periods result in lower sensitivity and potentially fewer alerts. If you specify a value for :guilabel:`Group by` (below), how long it's been since any member of the group stopped reporting.
+     - How long it's been since the signal last reported. Longer time periods result in lower sensitivity and potentially fewer alerts. If you specify a value for :guilabel:`Group by` (below), how long it's been since all members of the group stopped reporting.
 
    * - (optional) :strong:`Group by`
      - Dimension or property chosen from dropdown menu

gdi/opentelemetry/components/metrics-transform-processor.rst

@@ -47,7 +47,7 @@ For example:
 .. code-block:: yaml
 
   processors:
-    metrics_transform:
+    metricstransform:
 
 To complete the configuration, include the processor in the ``metrics`` pipeline of the ``service`` section of your configuration file. For example: