You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: deploy-manage/deploy/elastic-cloud/restrictions-known-problems.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -26,7 +26,7 @@ When using {{ecloud}}, there are some limitations you should be aware of:
26
26
*[Regions and Availability Zones](#ec-regions-and-availability-zone)
27
27
% * [Known problems](#ec-known-problems)
28
28
29
-
For limitations related to logging and monitoring, check the [Restrictions and limitations](../../monitor/stack-monitoring/ece-ech-stack-monitoring.md#ec-restrictions-monitoring) section of the logging and monitoring page.
29
+
For limitations related to logging and monitoring, check the [Restrictions and limitations](../../monitor/stack-monitoring/ece-ech-stack-monitoring.md#restrictions-monitoring) section of the logging and monitoring page.
30
30
31
31
% Occasionally, we also publish information about [Known problems](#ec-known-problems) with our {{ecloud}} or the Elastic Stack.
Copy file name to clipboardExpand all lines: deploy-manage/monitor/access-performance-metrics-on-elastic-cloud.md
+16-16Lines changed: 16 additions & 16 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,7 +11,7 @@ applies_to:
11
11
12
12
For {{ech}} deployments, 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.
13
13
14
-
For advanced views or production monitoring, [enable logging and monitoring](../stack-monitoring/ece-ech-stack-monitoring.md). The monitoring application provides more advanced views for {{es}} and JVM metrics, and includes a configurable retention period.
14
+
For advanced views or production monitoring, [enable logging and monitoring](/deploy-manage/monitor/stack-monitoring/ece-ech-stack-monitoring.md). The monitoring application provides more advanced views for {{es}} and JVM metrics, and includes a configurable retention period.
15
15
16
16
To access cluster performance metrics:
17
17
@@ -27,19 +27,19 @@ The following metrics are available:
Shows the maximum usage of the CPU resources assigned to your {{es}} 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%.
35
35
36
36
::::{tip}
37
-
This chart reports the maximum CPU values over the sampling period. [Logs and Metrics](../stack-monitoring/ece-ech-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).
37
+
This chart reports the maximum CPU values over the sampling period. [Logs and metrics](/deploy-manage/monitor/stack-monitoring/ece-ech-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).
Indicates the total memory used by the JVM heap over time. We’ve configured {{es}}'s garbage collector to keep memory usage below 75% for heaps of 8GB or larger. For heaps smaller than 8GB, the threshold is 85%. If memory pressure consistently remains above this threshold, you might need to resize your cluster or reduce memory consumption. Check [how high memory pressure can cause performance issues](../../../troubleshoot/monitoring/high-memory-pressure.md).
82
+
Indicates the total memory used by the JVM heap over time. We’ve configured {{es}}'s garbage collector to keep memory usage below 75% for heaps of 8GB or larger. For heaps smaller than 8GB, the threshold is 85%. If memory pressure consistently remains above this threshold, you might need to resize your cluster or reduce memory consumption. Check [how high memory pressure can cause performance issues](/troubleshoot/monitoring/high-memory-pressure.md).
83
83
84
84
85
85
### GC overhead per node [ec_gc_overhead_per_node]
:alt: Graph showing the garbage collection overhead per node
89
89
:::
90
90
@@ -95,30 +95,30 @@ Indicates the overhead involved in JVM garbage collection to reclaim memory.
95
95
96
96
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.
97
97
98
-
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.
98
+
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.
99
99
100
100
To help diagnose high CPU usage you can also use the {{es}} [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.
101
101
102
102
::::{tip}
103
-
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.
103
+
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.
104
104
::::
105
105
106
106
107
107
Work with the metrics shown in **Cluster Performance Metrics** section to help you find the information you need:
108
108
109
109
* Hover on any part of a graph to get additional information. For example, hovering on a section of a graph that shows response times reveals the percentile that responses fall into at that point in time:
* Zoom in on a graph by drawing a rectangle to select a specific time window. As you zoom in one metric, other performance metrics change to show data for the same time window.
116
116
117
-
:::{image} ../../../images/cloud-metrics-zoom.png
117
+
:::{image} /images/cloud-metrics-zoom.png
118
118
:alt: Zoom the metric graph
119
119
:::
120
120
121
-
* 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.
122
-
* Reset the metric graph axes with ![Reset the metric graph](../../../images/cloud-metrics-reset.png""), which returns the graphs to their original scale.
121
+
* 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.
122
+
* Reset the metric graph axes with ![Reset the metric graph](/images/cloud-metrics-reset.png""), which returns the graphs to their original scale.
123
123
124
124
Cluster performance metrics are shown per node and are color-coded to indicate which running {{es}} instance they belong to.
Copy file name to clipboardExpand all lines: deploy-manage/monitor/autoops/ec-autoops-deployment-view.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,7 +10,7 @@ applies_to:
10
10
11
11
The **Deployment** view is the event control panel that allows you to see which issues are affecting the {{es}} cluster and get a list of action items to address them.
@@ -35,7 +35,7 @@ The **Events History** panel lists events that happened at some point and that h
35
35
36
36
The **Deployment Info** panel provides a quick overview of the {{es}} cluster resources in the selected deployment, such as {{es}} version, cluster status (indicated by the colors green, yellow, or red) at the top right, number of nodes distributed by role, and resources metrics.
Copy file name to clipboardExpand all lines: deploy-manage/monitor/autoops/ec-autoops-dismiss-event.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,7 +10,7 @@ applies_to:
10
10
11
11
Some events that are triggered may not require your attention immediately, or at all. Users with the appropriate permissions can choose to dismiss an event, preventing AutoOps from opening it. This action can be reversed using the Dismiss events report.
Copy file name to clipboardExpand all lines: deploy-manage/monitor/autoops/ec-autoops-event-settings.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -23,7 +23,7 @@ The event settings include:
23
23
* Index patterns to exclude - AutoOps will exclude system indices to prevent unnecessary events from opening. You can add or remove indices from the list.
24
24
* Data roles tier to exclude from indications - Add threshold based on the type of data tier.
Copy file name to clipboardExpand all lines: deploy-manage/monitor/autoops/ec-autoops-nodes-view.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,7 +10,7 @@ applies_to:
10
10
11
11
The **Nodes** view provides a thorough overview on the essential metrics for all monitored deployment nodes. You can delve into specific nodes to observe metrics over extended periods. This includes data on the indexing rate and latency, search rate and latency, as well as details concerning thread pools, data, circuit breakers, network, disk, and additional elements.
Copy file name to clipboardExpand all lines: deploy-manage/monitor/autoops/ec-autoops-notifications-settings.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -217,7 +217,7 @@ When the connector settings have been completed, continue to set up the notifica
217
217
218
218
From the **Notifications** report, you can check all the notifications sent. The report lists all the events that were set up in the notification filters and provide their status.
0 commit comments