more

shainaraskas · shainaraskas · commit 6ab2abc1b5e6 · 2025-03-17T15:56:19.000-04:00
diff --git a/deploy-manage/monitor/autoops/ec-autoops-notifications-settings.md b/deploy-manage/monitor/autoops/ec-autoops-notifications-settings.md
@@ -95,7 +95,7 @@ The PagerDuty integration consists of the following parts:
 
 :::{dropdown} Slack
 
-$$$ec-autoops-slack
+$$$ec-autoops-slack$$$
 
 To set up a webhook to send AutoOps notifications to a Slack channel, go through the following steps.
 
diff --git a/deploy-manage/monitor/cloud-health-perf.md b/deploy-manage/monitor/cloud-health-perf.md
@@ -22,7 +22,7 @@ The deployment **Health** page provides detailed information on health issues, i
 
 To view the health for a deployment:
 
-1. Log in to the [{{ecloud}} Console](https://cloud.elastic.co?page=docs&placement=docs-body) or [Cloud UI](deploy-manage/deploy/cloud-enterprise/log-into-cloud-ui.md).
+1. Log in to the [{{ecloud}} Console](https://cloud.elastic.co?page=docs&placement=docs-body) or [Cloud UI](/deploy-manage/deploy/cloud-enterprise/log-into-cloud-ui.md).
 2. On the **Deployments** page, select your deployment.
 3. In your deployment menu, select **Health**.
 
@@ -31,7 +31,7 @@ The **Health** page provides the following information:
 * Health issues for {{kib}}, Enterprise Search, APM, and plan changes are reported in the health banner.
 * Health issues for {{es}} clusters are broken down into a table with more details on Severity, Description and Affected capabilities.
 
-:::{image} ../../../images/cloud-es-health-page.png
+:::{image} /images/cloud-es-health-page.png
 :alt: {{es}} Health page
 :::
 
@@ -41,7 +41,7 @@ The **Health** page provides the following information:
 
 You can also search and filter the table based on affected resources, such as indices, repositories, nodes, or SLM policies. Individual issues can be further expanded to get more details and guided troubleshooting.
 
-:::{image} ../../../images/cloud-es-health-page-table.png
+:::{image} /images/cloud-es-health-page-table.png
 :alt: {{es}} Health page with details and troubleshooting
 :::
 
@@ -65,7 +65,7 @@ deployment:
 
 For clusters that suffer out-of-memory failures, it can be difficult to determine whether the clusters are in a completely healthy state afterwards. For this reason, {{ech}} automatically reboots clusters that suffer out-of-memory failures.
 
-You will receive an email notification to let you know that a restart occurred. For repeated alerts, the emails are aggregated so that you do not receive an excessive number of notifications. Either [resizing your cluster to reduce memory pressure](../../deploy/elastic-cloud/ec-customize-deployment-components.md#ec-cluster-size) or reducing the workload that a cluster is being asked to handle can help avoid these cluster restarts.
+You will receive an email notification to let you know that a restart occurred. For repeated alerts, the emails are aggregated so that you do not receive an excessive number of notifications. Either [resizing your cluster to reduce memory pressure](/deploy-manage/deploy/elastic-cloud/ec-customize-deployment-components.md#ec-cluster-size) or reducing the workload that a cluster is being asked to handle can help avoid these cluster restarts.
 
 ## Cluster performance [ec-es-cluster-performance]
 
diff --git a/deploy-manage/monitor/ec-memory-pressure.md b/deploy-manage/monitor/ec-memory-pressure.md
@@ -10,9 +10,9 @@ applies_to:
 
 # JVM memory pressure indicator [ec-memory-pressure]
 
-In addition to the more detailed [cluster performance metrics](../stack-monitoring.md), {{ech}} and {{ece}} also include a JVM memory pressure indicator for each node in your cluster in your deployment overview. This indicator can help you to determine when you need to upgrade to a larger cluster.
+In addition to the more detailed [cluster performance metrics](/deploy-manage/monitor/stack-monitoring.md), {{ech}} and {{ece}} also include a JVM memory pressure indicator for each node in your cluster in your deployment overview. This indicator can help you to determine when you need to upgrade to a larger cluster.
 
-The percentage number used in the JVM memory pressure indicator is actually the fill rate of the old generation pool. For a detailed explanation of why this metric is used, check [Understanding Memory Pressure](https://www.elastic.co/blog/found-understanding-memory-pressure-indicator/).
+The percentage number used in the JVM memory pressure indicator is actually the fill rate of the old generation pool. For a detailed explanation of why this metric is used, refer to [Understanding memory pressure](https://www.elastic.co/blog/found-understanding-memory-pressure-indicator/).
 
 :::{image} ../../../images/cloud-memory-pressure-indicator.png
 :alt: Memory pressure indicator
diff --git a/deploy-manage/monitor/ec-saas-metrics-accessing.md b/deploy-manage/monitor/ec-saas-metrics-accessing.md
@@ -123,14 +123,4 @@ Work with the metrics shown in **Cluster Performance Metrics** section to help y
 * Pan around with ![Pan in a metric graph](../../../images/cloud-metrics-pan.png "") to make sure that you can get the right parts of a metric graph as you zoom in.
 * Reset the metric graph axes with ![Reset the metric graph](../../../images/cloud-metrics-reset.png ""), which returns the graphs to their original scale.
 
-Cluster performance metrics are shown per node and are color-coded to indicate which running Elasticsearch instance they belong to.
-
-
-## Cluster restarts after out-of-memory failures [ec_cluster_restarts_after_out_of_memory_failures]
-
-For clusters that suffer out-of-memory failures, it can be difficult to determine whether the clusters are in a completely healthy state afterwards. For this reason, {{ech}} automatically reboots clusters that suffer out-of-memory failures.
-
-You will receive an email notification to let you know that a restart occurred. For repeated alerts, the emails are aggregated so that you do not receive an excessive number of notifications. Either [resizing your cluster to reduce memory pressure](../../deploy/elastic-cloud/ec-customize-deployment-components.md#ec-cluster-size) or reducing the workload that a cluster is being asked to handle can help avoid these cluster restarts.
-
-
-
+Cluster performance metrics are shown per node and are color-coded to indicate which running Elasticsearch instance they belong to.
diff --git a/deploy-manage/monitor/ec-vcpu-boost-instance.md b/deploy-manage/monitor/ec-vcpu-boost-instance.md
@@ -49,5 +49,5 @@ You can check the **Monitoring > Performance > CPU Credits** section of the [{{e
 
 ## What to do if my vCPU credits get depleted constantly? [ec_what_to_do_if_my_vcpu_credits_get_depleted_constantly]
 
-If you need your cluster to be able to sustain a certain level of performance, you cannot rely on CPU boosting to handle the workload except temporarily. To ensure that performance can be sustained, consider increasing the size of your cluster. Read [this page](../../../troubleshoot/monitoring/performance.md) for more guidance.
+If you need your cluster to be able to sustain a certain level of performance, you cannot rely on CPU boosting to handle the workload except temporarily. To ensure that performance can be sustained, consider increasing the size of your cluster. Read [this page](/troubleshoot/monitoring/performance.md) for more guidance.
 
diff --git a/deploy-manage/monitor/logging-configuration.md b/deploy-manage/monitor/logging-configuration.md
@@ -26,14 +26,14 @@ When shipping logs to a monitoring deployment there are more logging features av
 * [Slow query and index logging](elasticsearch://reference/elasticsearch/index-settings/slow-log.md) - helps find and debug slow queries and indexing
 * Verbose logging - helps debug stack issues by increasing component logs
 
-After you’ve enabled log delivery on your deployment, you can [add the Elasticsearch user settings](../../deploy/cloud-enterprise/edit-stack-settings.md) to enable these features.
+After you’ve enabled log delivery on your deployment, you can [add the Elasticsearch user settings](/deploy-manage/deploy/cloud-enterprise/edit-stack-settings.md) to enable these features.
 
 
 ### For {{kib}} [extra-logging-features-kibana]
 
 * [Audit logging](../logging-configuration/enabling-audit-logs.md) - logs security-related events on your deployment
 
-After you’ve enabled log delivery on your deployment, you can [add the {{kib}} user settings](../../deploy/cloud-enterprise/edit-stack-settings.md) to enable this feature.
+After you’ve enabled log delivery on your deployment, you can [add the {{kib}} user settings](/deploy-manage/deploy/cloud-enterprise/edit-stack-settings.md) to enable this feature.
 
 
 ### Other components [extra-logging-features-enterprise-search]
diff --git a/deploy-manage/monitor/stack-monitoring.md b/deploy-manage/monitor/stack-monitoring.md
@@ -76,7 +76,7 @@ Most of these methods require that you configure monitoring of {{es}} before mon
 :::
 
 * **Logstash**:
-  * [Monitoring {{ls}} with {{agent}}](/reference/monitoring-logstash-with-elastic-agent.md) (recommended): Uses a single agent to gather logs and metrics. Can be managed from a central location in {{fleet}}.
+  * [Monitoring {{ls}} with {{agent}}](logstash://reference/monitoring-logstash-with-elastic-agent.md) (recommended): Uses a single agent to gather logs and metrics. Can be managed from a central location in {{fleet}}.
   * [Monitoring {{ls}} with legacy collection methods](logstash://reference/monitoring-logstash-legacy.md): Use {{metricbeat}} or legacy methods to collect monitoring data from {{ls}}.
 * **{{beats}}**:
 
@@ -90,8 +90,8 @@ Most of these methods require that you configure monitoring of {{es}} before mon
 * [**APM Server**](/solutions/observability/apps/monitor-apm-server.md)
 
 * **{{agent}}s**: 
-  * [{{fleet}}-managed {{agent}}s](/reference/ingestion-tools/fleet/monitor-elastic-agent.md) 
-  * [Standalone {{agent}}s](/reference/ingestion-tools/fleet/elastic-agent-monitoring-configuration.md)
+  * [{{fleet}}-managed {{agent}}s](docs-content://reference/ingestion-tools/fleet/monitor-elastic-agent.md) 
+  * [Standalone {{agent}}s](docs-content://reference/ingestion-tools/fleet/elastic-agent-monitoring-configuration.md)
 
 ### Access, view, and use monitoring data
 
diff --git a/deploy-manage/monitor/stack-monitoring/_snippets/legacy-warning.md b/deploy-manage/monitor/stack-monitoring/_snippets/legacy-warning.md
@@ -1,5 +1,5 @@
 :::{important}
 {{agent}} and {{metricbeat}} are the recommended methods for collecting and shipping monitoring data to a monitoring cluster.
 
-If you have previously configured legacy collection methods, you should migrate to using [{{agent}}](collecting-monitoring-data-with-elastic-agent.md) or [{{metricbeat}}](collecting-monitoring-data-with-metricbeat.md) collection. Do not use legacy collection alongside other collection methods.
+If you have previously configured legacy collection methods, you should migrate to using [{{agent}}](/deploy-manage/monitor/stack-monitoring/collecting-monitoring-data-with-elastic-agent.md) or [{{metricbeat}}](/deploy-manage/monitor/stack-monitoring/collecting-monitoring-data-with-metricbeat.md) collection. Do not use legacy collection alongside other collection methods.
 :::
diff --git a/deploy-manage/monitor/stack-monitoring/ece-ech-stack-monitoring.md b/deploy-manage/monitor/stack-monitoring/ece-ech-stack-monitoring.md
@@ -113,18 +113,18 @@ When shipping logs to a monitoring deployment there are more logging features av
 
 ### For {{es}} [extra-logging-features-elasticsearch]
 
-* [Audit logging](../logging-configuration/enabling-audit-logs.md) - logs security-related events on your deployment
+* [Audit logging](/deploy-manage/security/logging-configuration/enabling-audit-logs.md) - logs security-related events on your deployment
 * [Slow query and index logging](elasticsearch://reference/elasticsearch/index-settings/slow-log.md) - helps find and debug slow queries and indexing
 * Verbose logging - helps debug stack issues by increasing component logs
 
-After you’ve enabled log delivery on your deployment, you can [add the Elasticsearch user settings](../../deploy/cloud-enterprise/edit-stack-settings.md) to enable these features.
+After you’ve enabled log delivery on your deployment, you can [add the Elasticsearch user settings](/deploy-manage/deploy/cloud-enterprise/edit-stack-settings.md) to enable these features.
 
 
 ### For {{kib}} [extra-logging-features-kibana]
 
-* [Audit logging](../logging-configuration/enabling-audit-logs.md) - logs security-related events on your deployment
+* [Audit logging](/deploy-manage/security/logging-configuration/enabling-audit-logs.md) - logs security-related events on your deployment
 
-After you’ve enabled log delivery on your deployment, you can [add the {{kib}} user settings](../../deploy/cloud-enterprise/edit-stack-settings.md) to enable this feature.
+After you’ve enabled log delivery on your deployment, you can [add the {{kib}} user settings](/deploy-mange/deploy/cloud-enterprise/edit-stack-settings.md) to enable this feature.
 
 
 ### Other components [extra-logging-features-enterprise-search]
diff --git a/deploy-manage/monitor/stack-monitoring/kibana-monitoring-data.md b/deploy-manage/monitor/stack-monitoring/kibana-monitoring-data.md
@@ -58,7 +58,7 @@ deployment:
     These users must exist on the monitoring cluster. If you are accessing a remote monitoring cluster, you must use credentials that are valid on both the {{kib}} server and the monitoring cluster.
     ::::
 
-## View monitoring data in {{kib}}
+## View monitoring data in {{kib}} [view-monitoring-data-in-kibana]
 
 :::::{tab-set}
 ::::{tab-item} In ECK and self-managed
diff --git a/explore-analyze/alerts-cases/alerts/create-manage-rules.md b/explore-analyze/alerts-cases/alerts/create-manage-rules.md
@@ -166,7 +166,7 @@ Some rule types cannot be exported through this interface:
 
 **Security rules** can be imported and exported using the [Security UI](../../../solutions/security/detect-and-alert/manage-detection-rules.md#import-export-rules-ui).
 
-**Stack monitoring rules** are [automatically created](../../../deploy-manage/monitor/monitoring-data/kibana-alerts.md) for you and therefore cannot be managed in **Saved Objects**.
+**Stack monitoring rules** are [automatically created](../../../deploy-manage/monitor/monitoring-data/configure-stack-monitoring-alerts.md) for you and therefore cannot be managed in **Saved Objects**.
 
 ::::
 
diff --git a/explore-analyze/alerts-cases/alerts/maintenance-windows.md b/explore-analyze/alerts-cases/alerts/maintenance-windows.md
@@ -57,7 +57,7 @@ If you turn on **Filter alerts**, you can use KQL to filter the alerts affected
 ::::{note}
 
 * You can select only a single category when you turn on filters.
-* Some rules are not affected by maintenance window filters because their alerts do not contain requisite data. In particular, [{{stack-monitor-app}}](../../../deploy-manage/monitor/monitoring-data/kibana-alerts.md), [tracking containment](../../../explore-analyze/alerts-cases/alerts/geo-alerting.md), [{{anomaly-jobs}} health](../../../explore-analyze/machine-learning/anomaly-detection/ml-configuring-alerts.md), and [transform health](../../../explore-analyze/transforms/transform-alerts.md) rules are not affected by the filters.
+* Some rules are not affected by maintenance window filters because their alerts do not contain requisite data. In particular, [{{stack-monitor-app}}](../../../deploy-manage/monitor/monitoring-data/configure-stack-monitoring-alerts.md), [tracking containment](../../../explore-analyze/alerts-cases/alerts/geo-alerting.md), [{{anomaly-jobs}} health](../../../explore-analyze/machine-learning/anomaly-detection/ml-configuring-alerts.md), and [transform health](../../../explore-analyze/transforms/transform-alerts.md) rules are not affected by the filters.
 
 ::::
 
diff --git a/raw-migrated-files/cloud/cloud/ec-monitoring-setup.md b/raw-migrated-files/cloud/cloud/ec-monitoring-setup.md
@@ -59,7 +59,7 @@ To learn more about what [Elasticsearch monitoring metrics](/deploy-manage/monit
 :alt: Node tab in Kibana under Stack Monitoring
 :::
 
-Some [performance metrics](../../../deploy-manage/monitor/ec-saas-metrics-accessing.md) are also available directly in the [{{ecloud}} Console](https://cloud.elastic.co?page=docs&placement=docs-body) and don’t require looking at your monitoring deployment. If you’re ever in a rush to determine if there is a performance problem, you can get a quick overview by going to the **Performance** page from your deployment menu:
+Some [performance metrics](/deploy-manage/monitor/ec-saas-metrics-accessing.md) are also available directly in the [{{ecloud}} Console](https://cloud.elastic.co?page=docs&placement=docs-body) and don’t require looking at your monitoring deployment. If you’re ever in a rush to determine if there is a performance problem, you can get a quick overview by going to the **Performance** page from your deployment menu:
 
 :::{image} ../../../images/cloud-ec-ce-monitoring-performance.png
 :alt: Performance page of the Elastic Cloud console
@@ -104,7 +104,7 @@ You will get this request reported as a new log. Audit logs do not currently rep
 
 ## Get notified [ec_get_notified]
 
-You should take advantage of the default [Elastic Stack monitoring alerts](/deploy-manage/monitor/monitoring-data/kibana-alerts.md) that are available out-of-the-box. You don’t have to do anything other than enable shipping logs and metrics to have them made available to you (which you did earlier on).
+You should take advantage of the default [Elastic Stack monitoring alerts](/deploy-manage/monitor/monitoring-data/configure-stack-monitoring-alerts.md) that are available out-of-the-box. You don’t have to do anything other than enable shipping logs and metrics to have them made available to you (which you did earlier on).
 
 On top of these default alerts that write to indices you can investigate, you might want to add some custom actions, such as a [connector](kibana://reference/connectors-kibana.md) for Slack notifications. To set up these notifications, you first configure a Slack connector and then append it to the default alerts and actions. From Kibana:
 
@@ -115,7 +115,7 @@ On top of these default alerts that write to indices you can investigate, you mi
     3. Select **Save**.
 
 2. Go to **Stack Monitoring** and select **Enter setup mode**.
-3. Edit an alert rule, such as [CPU usage](/deploy-manage/monitor/monitoring-data/kibana-alerts.md#kibana-alerts-cpu-threshold):
+3. Edit an alert rule, such as [CPU usage](/deploy-manage/monitor/monitoring-data/configure-stack-monitoring-alerts.md#kibana-alerts-cpu-threshold):
 
     1. Select one of the alert rule fields and select **CPU Usage**.
     2. Choose **Edit rule** and scroll down to the bottom of the screen to select **Slack**.
diff --git a/raw-migrated-files/cloud/cloud/ec-planning.md b/raw-migrated-files/cloud/cloud/ec-planning.md
@@ -44,7 +44,7 @@ Clusters that only have one master node are not highly available and are at risk
 
 ## Do you know when to scale? [ec-workloads] 
 
-Knowing how to scale your deployment is critical, especially when unexpected workloads hits. Don’t forget to [check your performance metrics](../../../deploy-manage/monitor/ec-saas-metrics-accessing.md) to make sure your deployments are healthy and can cope with your workloads.
+Knowing how to scale your deployment is critical, especially when unexpected workloads hits. Don’t forget to [check your performance metrics](/deploy-manage/monitor/ec-saas-metrics-accessing.md) to make sure your deployments are healthy and can cope with your workloads.
 
 Scaling with {{ech}} is easy:
 
diff --git a/troubleshoot/elasticsearch/high-cpu-usage.md b/troubleshoot/elasticsearch/high-cpu-usage.md
@@ -38,7 +38,7 @@ To track CPU usage over time, we recommend enabling monitoring:
 ::::::{tab-item} {{ech}}
 * (Recommended) Enable [logs and metrics](../../deploy-manage/monitor/stack-monitoring/ece-ech-stack-monitoring.md). When logs and metrics are enabled, monitoring information is visible on {{kib}}'s [Stack Monitoring](../../deploy-manage/monitor/monitoring-data/visualizing-monitoring-data.md) page.
 
-    You can also enable the [CPU usage threshold alert](../../deploy-manage/monitor/monitoring-data/kibana-alerts.md) to be notified about potential issues through email.
+    You can also enable the [CPU usage threshold alert](../../deploy-manage/monitor/monitoring-data/configure-stack-monitoring-alerts.md) to be notified about potential issues through email.
 
 * From your deployment menu, view the [**Performance**](../../deploy-manage/monitor/monitoring-data/access-performance-metrics-on-elastic-cloud.md) page. On this page, you can view two key metrics:
 
@@ -52,7 +52,7 @@ To track CPU usage over time, we recommend enabling monitoring:
 ::::::{tab-item} Self-managed
 * Enable [{{es}} monitoring](../../deploy-manage/monitor/stack-monitoring.md). When logs and metrics are enabled, monitoring information is visible on {{kib}}'s [Stack Monitoring](../../deploy-manage/monitor/monitoring-data/visualizing-monitoring-data.md) page.
 
-    You can also enable the [CPU usage threshold alert](../../deploy-manage/monitor/monitoring-data/kibana-alerts.md) to be notified about potential issues through email.
+    You can also enable the [CPU usage threshold alert](../../deploy-manage/monitor/monitoring-data/configure-stack-monitoring-alerts.md) to be notified about potential issues through email.
 ::::::
 
 :::::::

Original file line number	Diff line number	Diff line change
`@@ -49,5 +49,5 @@ You can check the Monitoring > Performance > CPU Credits section of the [{{e`
`49`	`49`
`50`	`50`	`## What to do if my vCPU credits get depleted constantly? [ec_what_to_do_if_my_vcpu_credits_get_depleted_constantly]`
`51`	`51`
`52`		`-If you need your cluster to be able to sustain a certain level of performance, you cannot rely on CPU boosting to handle the workload except temporarily. To ensure that performance can be sustained, consider increasing the size of your cluster. Read [this page](../../../troubleshoot/monitoring/performance.md) for more guidance.`
	`52`	`+If you need your cluster to be able to sustain a certain level of performance, you cannot rely on CPU boosting to handle the workload except temporarily. To ensure that performance can be sustained, consider increasing the size of your cluster. Read [this page](/troubleshoot/monitoring/performance.md) for more guidance.`
`53`	`53`