progress

Author: shainaraskas

deploy-manage/monitor.md

@@ -2,6 +2,7 @@
 mapped_urls:
   - https://www.elastic.co/guide/en/elasticsearch/reference/current/monitor-elasticsearch-cluster.html
   - https://www.elastic.co/guide/en/elasticsearch/reference/current/secure-monitoring.html
+  - https://www.elastic.co/guide/en/cloud/current/ec-monitoring.html
 applies_to:
   deployment:
     ess: all
@@ -31,6 +32,7 @@ The documentation team is working to combine content pulled from the following p
 
 * [/raw-migrated-files/elasticsearch/elasticsearch-reference/monitor-elasticsearch-cluster.md](/raw-migrated-files/elasticsearch/elasticsearch-reference/monitor-elasticsearch-cluster.md)
 * [/raw-migrated-files/elasticsearch/elasticsearch-reference/secure-monitoring.md](/raw-migrated-files/elasticsearch/elasticsearch-reference/secure-monitoring.md)
+* [](/raw-migrated-files/cloud/cloud/ec-monitoring.md)
 
 ## Monitoring your cluster or deployment
 

raw-migrated-files/cloud/cloud/ec-saas-metrics-accessing.md renamed to deploy-manage/monitor/access-performance-metrics-on-elastic-cloud.md

@@ -1,12 +1,17 @@
-# Access performance metrics [ec-saas-metrics-accessing]
+---
+mapped_urls:
+  - https://www.elastic.co/guide/en/cloud/current/ec-saas-metrics-accessing.html
+  - https://www.elastic.co/guide/en/cloud-heroku/current/ech-saas-metrics-accessing.html
+applies_to:
+  deployment:
+    ess: all
+---
 
-Cluster performance metrics are available directly in the [{{ecloud}} Console](https://cloud.elastic.co?page=docs&placement=docs-body). The graphs on this page include a subset of {{ech}}-specific performance metrics.
+# Performance metrics on {{ecloud}} [ec-saas-metrics-accessing]
 
-For advanced views or production monitoring, [enable logging and monitoring](../../../deploy-manage/monitor/stack-monitoring/elastic-cloud-stack-monitoring.md). The monitoring application provides more advanced views for Elasticsearch and JVM metrics, and includes a configurable retention period.
+Cluster performance metrics are available directly in the [{{ecloud}} Console](https://cloud.elastic.co?page=docs&placement=docs-body). The graphs on this page include a subset of {{ech}}-specific performance metrics.
 
-:::{important}
- If you’re using Elastic Cloud Hosted, then you can use AutoOps to monitor your cluster. AutoOps significantly simplifies cluster management with performance recommendations, resource utilization visibility, real-time issue detection and resolution paths. For more information, refer to [Monitor with AutoOps](/deploy-manage/monitor/autoops.md).
-:::
+For advanced views or production monitoring, [enable logging and monitoring](../stack-monitoring/elastic-cloud-stack-monitoring.md). The monitoring application provides more advanced views for Elasticsearch and JVM metrics, and includes a configurable retention period.
 
 To access cluster performance metrics:
 
@@ -29,18 +34,16 @@ The following metrics are available:
 Shows the maximum usage of the CPU resources assigned to your Elasticsearch cluster, as a percentage. CPU resources are relative to the size of your cluster, so that a cluster with 32GB of RAM gets assigned twice as many CPU resources as a cluster with 16GB of RAM. All clusters are guaranteed their share of CPU resources, as {{ech}} infrastructure does not overcommit any resources. CPU credits permit boosting the performance of smaller clusters temporarily, so that CPU usage can exceed 100%.
 
 ::::{tip}
-This chart reports the maximum CPU values over the sampling period. [Logs and Metrics](../../../deploy-manage/monitor/stack-monitoring/elastic-cloud-stack-monitoring.md) ingested into [Stack Monitoring](../../../deploy-manage/monitor/monitoring-data/visualizing-monitoring-data.md)'s "CPU Usage" instead reflects the average CPU over the sampling period. Therefore, you should not expect the two graphs to look exactly the same. When investigating [CPU-related performance issues](../../../troubleshoot/monitoring/performance.md), you should default to [Stack Monitoring](../../../deploy-manage/monitor/monitoring-data/visualizing-monitoring-data.md).
+This chart reports the maximum CPU values over the sampling period. [Logs and Metrics](../stack-monitoring/elastic-cloud-stack-monitoring.md) ingested into [Stack Monitoring](visualizing-monitoring-data.md)'s "CPU Usage" instead reflects the average CPU over the sampling period. Therefore, you should not expect the two graphs to look exactly the same. When investigating [CPU-related performance issues](../../../troubleshoot/monitoring/performance.md), you should default to [Stack Monitoring](visualizing-monitoring-data.md).
 ::::
 
-
-
 ### CPU credits [ec_cpu_credits]
 
 :::{image} ../../../images/cloud-metrics-cpu-credits.png
 :alt: Graph showing available CPU credits
 :::
 
-Shows your remaining CPU credits, measured in seconds of CPU time. CPU credits enable the boosting of CPU resources assigned to your cluster to improve performance temporarily when it is needed most. For more details check [How to use vCPU to boost your instance](../../../deploy-manage/monitor/monitoring-data/ec-vcpu-boost-instance.md).
+Shows your remaining CPU credits, measured in seconds of CPU time. CPU credits enable the boosting of CPU resources assigned to your cluster to improve performance temporarily when it is needed most. For more details check [How to use vCPU to boost your instance](ec-vcpu-boost-instance.md).
 
 
 ### Number of requests [ec_number_of_requests]
@@ -92,12 +95,12 @@ Indicates the overhead involved in JVM garbage collection to reclaim memory.
 
 Performance correlates directly with resources assigned to your cluster, and many of these metrics will show some sort of correlation with each other when you are trying to determine the cause of a performance issue. Take a look at some of the scenarios included in this section to learn how you can determine the cause of performance issues.
 
-It is not uncommon for performance issues on {{ech}} to be caused by an undersized cluster that cannot cope with the workload it is being asked to handle. If your cluster performance metrics often shows high CPU usage or excessive memory pressure, consider increasing the size of your cluster soon to improve performance. This is especially true for clusters that regularly reach 100% of CPU usage or that suffer out-of-memory failures; it is better to resize your cluster early when it is not yet maxed out than to have to resize a cluster that is already overwhelmed. [Changing the configuration of your cluster](../../../deploy-manage/deploy/elastic-cloud/configure.md) may add some overhead if data needs to be migrated to the new nodes, which can increase the load on a cluster further and delay configuration changes.
+It is not uncommon for performance issues on {{ech}} to be caused by an undersized cluster that cannot cope with the workload it is being asked to handle. If your cluster performance metrics often shows high CPU usage or excessive memory pressure, consider increasing the size of your cluster soon to improve performance. This is especially true for clusters that regularly reach 100% of CPU usage or that suffer out-of-memory failures; it is better to resize your cluster early when it is not yet maxed out than to have to resize a cluster that is already overwhelmed. [Changing the configuration of your cluster](../../deploy/elastic-cloud/configure.md) may add some overhead if data needs to be migrated to the new nodes, which can increase the load on a cluster further and delay configuration changes.
 
 To help diagnose high CPU usage you can also use the Elasticsearch [nodes hot threads API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-nodes-hot-threads), which identifies the threads on each node that have the highest CPU usage or that have been executing for a longer than normal period of time.
 
 ::::{tip}
-Got an overwhelmed cluster that needs to be upsized? [Try enabling maintenance mode first](../../../deploy-manage/maintenance/ece/start-stop-routing-requests.md). It will likely help with configuration changes.
+Got an overwhelmed cluster that needs to be upsized? [Try enabling maintenance mode first](../../maintenance/ece/start-stop-routing-requests.md). It will likely help with configuration changes.
 ::::
 
 
@@ -125,7 +128,4 @@ Cluster performance metrics are shown per node and are color-coded to indicate w
 
 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-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.
-
-
-
+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.

deploy-manage/monitor/monitoring-data/ec-memory-pressure.md renamed to deploy-manage/monitor/ec-memory-pressure.md

@@ -1,5 +1,4 @@
 ---
-navigation_title: "Beats Metrics"
 mapped_pages:
   - https://www.elastic.co/guide/en/kibana/current/beats-page.html
 applies_to:
@@ -12,7 +11,7 @@ applies_to:
 
 
 
-# Beats Metrics [beats-page]
+# Beats metrics [beats-page]
 
 
 If you are monitoring Beats, the **Stack Monitoring** page in {{kib}} contains a panel for Beats in the cluster overview.