[troubleshooting] Move images

troubleshoot/deployments/cloud-enterprise/cloud-enterprise.md

@@ -24,7 +24,7 @@ The **Deployments** page in the Cloud UI provides several ways to find deploymen
 * Search for partial or whole deployment names or IDs in the search text box
 * Add filters to the **Deployments** view to filter for specific conditions:
 
-    :::{image} ../../../images/cloud-enterprise-deployment-filter.png
+    :::{image} /troubleshoot/images/cloud-enterprise-deployment-filter.png
     :alt: Add a filter
     :::
 

troubleshoot/deployments/cloud-enterprise/common-issues.md

@@ -102,7 +102,7 @@ To check if you are affected and to resolve this issue:
 
     A quick check in the AWS EC2 Dashboard confirms that `192.168.40.73` is a private IP address, which is not accessible externally:
 
-    :::{image} ../../../images/cloud-enterprise-ece-aws-private-ip.png
+    :::{image} /troubleshoot/images/cloud-enterprise-ece-aws-private-ip.png
     :alt: Private IP address information in AWS EC2 Dashboard
     :::
 
@@ -111,7 +111,7 @@ To check if you are affected and to resolve this issue:
     * For the Cloud UI, use the public host name or public IP. In this example, the Cloud UI is accessible externally at `ec2-54-162-168-86.compute-1.amazonaws.com:12400`.
     * For Elasticsearch and Kibana, [update your cluster endpoint](../../../deploy-manage/deploy/cloud-enterprise/change-endpoint-urls.md) to use the public IP address. In this example, you can use `54.162.168.86`:
 
-        :::{image} ../../../images/cloud-enterprise-ece-aws-public-ip.png
+        :::{image} /troubleshoot/images/cloud-enterprise-ece-aws-public-ip.png
         :alt: Public IP address is used for cluster endpoints in the Cloud UI
         :::
 

troubleshoot/elasticsearch/add-tier.md

@@ -30,7 +30,7 @@ In order to get the shards assigned we need enable a new tier in the deployment.
 
 3. Open your deployment’s side navigation menu (placed under the Elastic logo in the upper left corner) and go to **Dev Tools > Console**.
 
-    :::{image} ../../images/elasticsearch-reference-kibana-console.png
+    :::{image} /troubleshoot/images/elasticsearch-reference-kibana-console.png
     :alt: {{kib}} Console
     :screenshot:
     :::

troubleshoot/elasticsearch/allow-all-cluster-allocation.md

@@ -30,7 +30,7 @@ We’ll achieve this by inspecting the system-wide `cluster.routing.allocation.e
 
 3. Open your deployment’s side navigation menu (placed under the Elastic logo in the upper left corner) and go to **Dev Tools > Console**.
 
-    :::{image} ../../images/elasticsearch-reference-kibana-console.png
+    :::{image} /troubleshoot/images/elasticsearch-reference-kibana-console.png
     :alt: {{kib}} Console
     :screenshot:
     :::

troubleshoot/elasticsearch/allow-all-index-allocation.md

@@ -31,7 +31,7 @@ In order to get the shards assigned we’ll need to change the value of the [con
 
 3. Open your deployment’s side navigation menu (placed under the Elastic logo in the upper left corner) and go to **Dev Tools > Console**.
 
-    :::{image} ../../images/elasticsearch-reference-kibana-console.png
+    :::{image} /troubleshoot/images/elasticsearch-reference-kibana-console.png
     :alt: {{kib}} Console
     :screenshot:
     :::

troubleshoot/elasticsearch/decrease-disk-usage-data-node.md

@@ -34,7 +34,7 @@ Reducing the replicas of an index can potentially reduce search throughput and d
 
 5. For each index you chose, click on its name, then on the panel that appears click `Edit settings`, reduce the value of the `index.number_of_replicas` to the desired value and then click `Save`.
 
-    :::{image} ../../images/elasticsearch-reference-reduce_replicas.png
+    :::{image} /troubleshoot/images/elasticsearch-reference-reduce_replicas.png
     :alt: Reducing replicas
     :screenshot:
     :::

troubleshoot/elasticsearch/diagnose-unassigned-shards.md

@@ -28,7 +28,7 @@ In order to diagnose the unassigned shards, follow the next steps:
 
 3. Open your deployment’s side navigation menu (placed under the Elastic logo in the upper left corner) and go to **Dev Tools > Console**.
 
-    :::{image} ../../images/elasticsearch-reference-kibana-console.png
+    :::{image} /troubleshoot/images/elasticsearch-reference-kibana-console.png
     :alt: {{kib}} Console
     :screenshot:
     :::

troubleshoot/elasticsearch/diagnosing-corrupted-repositories.md

@@ -26,7 +26,7 @@ First mark the repository as read-only on the secondary deployments:
 
 3. Open your deployment’s side navigation menu (placed under the Elastic logo in the upper left corner) and go to **Stack Management > Snapshot and Restore > Repositories**.
 
-    :::{image} ../../images/elasticsearch-reference-repositories.png
+    :::{image} /troubleshoot/images/elasticsearch-reference-repositories.png
     :alt: {{kib}} Console
     :screenshot:
     :::
@@ -39,7 +39,7 @@ Note that we’re now configuring the primary (current) deployment.
 
 1. Open the primary deployment’s side navigation menu (placed under the Elastic logo in the upper left corner) and go to **Stack Management > Snapshot and Restore > Repositories**.
 
-    :::{image} ../../images/elasticsearch-reference-repositories.png
+    :::{image} /troubleshoot/images/elasticsearch-reference-repositories.png
     :alt: {{kib}} Console
     :screenshot:
     :::

troubleshoot/elasticsearch/elasticsearch-client-net-api/logging-with-fiddler.md

@@ -11,7 +11,7 @@ A web debugging proxy such as [Fiddler](http://www.telerik.com/fiddler) is a use
 
 To capture traffic against a remote cluster is as simple as launching Fiddler! You may want to also filter traffic to only show requests to the remote cluster by using the filters tab
 
-:::{image} ../../../images/elasticsearch-client-net-api-capture-requests-remotehost.png
+:::{image} /troubleshoot/images/elasticsearch-client-net-api-capture-requests-remotehost.png
 :alt: Capturing requests to a remote host
 :::
 
@@ -37,13 +37,13 @@ var client = new ElasticClient(connectionSettings);
 
 With Fiddler running, the requests and responses will now be captured and can be inspected in the Inspectors tab
 
-:::{image} ../../../images/elasticsearch-client-net-api-inspect-requests.png
+:::{image} /troubleshoot/images/elasticsearch-client-net-api-inspect-requests.png
 :alt: Inspecting requests and responses
 :::
 
 As before, you may also want to filter traffic to only show requests to `ipv4.fiddler` on the port on which you are running Elasticsearch.
 
-:::{image} ../../../images/elasticsearch-client-net-api-capture-requests-localhost.png
+:::{image} /troubleshoot/images/elasticsearch-client-net-api-capture-requests-localhost.png
 :alt: Capturing requests to localhost
 :::
 

troubleshoot/elasticsearch/fix-master-node-out-of-disk.md

@@ -17,7 +17,7 @@ mapped_pages:
 2. On the **Hosted deployments** panel, click the gear under the `Manage deployment` column that corresponds to the name of your deployment.
 3. Go to `Actions > Edit deployment` and then go to the `Master instances` section:
 
-    :::{image} ../../images/elasticsearch-reference-increase-disk-capacity-master-node.png
+    :::{image} /troubleshoot/images/elasticsearch-reference-increase-disk-capacity-master-node.png
     :alt: Increase disk capacity of master nodes
     :screenshot:
     :::

troubleshoot/elasticsearch/fix-other-node-out-of-disk.md

@@ -17,7 +17,7 @@ mapped_pages:
 2. On the **Hosted deployments** panel, click the gear under the `Manage deployment` column that corresponds to the name of your deployment.
 3. Go to `Actions > Edit deployment` and then go to the `Coordinating instances` or the `Machine Learning instances` section depending on the roles listed in the diagnosis:
 
-    :::{image} ../../images/elasticsearch-reference-increase-disk-capacity-other-node.png
+    :::{image} /troubleshoot/images/elasticsearch-reference-increase-disk-capacity-other-node.png
     :alt: Increase disk capacity of other nodes
     :screenshot:
     :::

troubleshoot/elasticsearch/increase-capacity-data-node.md

@@ -15,28 +15,28 @@ In order to increase the disk capacity of the data nodes in your cluster:
 2. On the **Hosted deployments** panel, click the gear under the `Manage deployment` column that corresponds to the name of your deployment.
 3. If autoscaling is available but not enabled, please enable it. You can do this by clicking the button `Enable autoscaling` on a banner like the one below:
 
-    :::{image} ../../images/elasticsearch-reference-autoscaling_banner.png
+    :::{image} /troubleshoot/images/elasticsearch-reference-autoscaling_banner.png
     :alt: Autoscaling banner
     :screenshot:
     :::
 
     Or you can go to `Actions > Edit deployment`, check the checkbox `Autoscale` and click `save` at the bottom of the page.
 
-    :::{image} ../../images/elasticsearch-reference-enable_autoscaling.png
+    :::{image} /troubleshoot/images/elasticsearch-reference-enable_autoscaling.png
     :alt: Enabling autoscaling
     :screenshot:
     :::
 
 4. If autoscaling has succeeded the cluster should return to `healthy` status. If the cluster is still out of disk, please check if autoscaling has reached its limits. You will be notified about this by the following banner:
 
-    :::{image} ../../images/elasticsearch-reference-autoscaling_limits_banner.png
+    :::{image} /troubleshoot/images/elasticsearch-reference-autoscaling_limits_banner.png
     :alt: Autoscaling banner
     :screenshot:
     :::
 
     or you can go to `Actions > Edit deployment` and look for the label `LIMIT REACHED` as shown below:
 
-    :::{image} ../../images/elasticsearch-reference-reached_autoscaling_limits.png
+    :::{image} /troubleshoot/images/elasticsearch-reference-reached_autoscaling_limits.png
     :alt: Autoscaling limits reached
     :screenshot:
     :::

troubleshoot/elasticsearch/increase-cluster-shard-limit.md

@@ -30,7 +30,7 @@ In order to get the shards assigned we’ll need to increase the number of shard
 
 3. Open your deployment’s side navigation menu (placed under the Elastic logo in the upper left corner) and go to **Dev Tools > Console**.
 
-    :::{image} ../../images/elasticsearch-reference-kibana-console.png
+    :::{image} /troubleshoot/images/elasticsearch-reference-kibana-console.png
     :alt: {{kib}} Console
     :screenshot:
     :::

troubleshoot/elasticsearch/increase-shard-limit.md

@@ -30,7 +30,7 @@ In order to get the shards assigned we’ll need to increase the number of shard
 
 3. Open your deployment’s side navigation menu (placed under the Elastic logo in the upper left corner) and go to **Dev Tools > Console**.
 
-    :::{image} ../../images/elasticsearch-reference-kibana-console.png
+    :::{image} /troubleshoot/images/elasticsearch-reference-kibana-console.png
     :alt: {{kib}} Console
     :screenshot:
     :::

troubleshoot/elasticsearch/increase-tier-capacity.md

@@ -28,7 +28,7 @@ One way to get the replica shards assigned is to add an availability zone. This
 
 3. Open your deployment’s side navigation menu (placed under the Elastic logo in the upper left corner) and go to **Dev Tools > Console**.
 
-    :::{image} ../../images/elasticsearch-reference-kibana-console.png
+    :::{image} /troubleshoot/images/elasticsearch-reference-kibana-console.png
     :alt: {{kib}} Console
     :screenshot:
     :::
@@ -57,7 +57,7 @@ The response will look like this:
 
 Now that you know the tier, you want to increase the number of nodes in that tier so that the replicas can be allocated. To do this you can either increase the size per zone to increase the number of nodes in the availability zone(s) you were already using, or increase the number of availability zones. Go back to the deployment’s landing page by clicking on the three horizontal bars on the top left of the screen and choosing **Manage this deployment**. On that page click the **Manage** button, and choose **Edit deployment**. Note that you must be logged in to [https://cloud.elastic.co/](https://cloud.elastic.co/) in order to do this. In the {{es}} section, find the tier where the replica shards could not be assigned.
 
-:::{image} ../../images/elasticsearch-reference-ess-advanced-config-data-tiers.png
+:::{image} /troubleshoot/images/elasticsearch-reference-ess-advanced-config-data-tiers.png
 :alt: {{kib}} Console
 :screenshot:
 :::

troubleshoot/elasticsearch/repeated-snapshot-failures.md

@@ -28,7 +28,7 @@ In order to check the status of failing {{slm}} policies we need to go to Kibana
 
 3. Open your deployment’s side navigation menu (placed under the Elastic logo in the upper left corner) and go to **Dev Tools > Console**.
 
-    :::{image} ../../images/elasticsearch-reference-kibana-console.png
+    :::{image} /troubleshoot/images/elasticsearch-reference-kibana-console.png
     :alt: {{kib}} Console
     :screenshot:
     :::

troubleshoot/elasticsearch/restore-from-snapshot.md

@@ -28,7 +28,7 @@ In order to restore the indices and data streams that are missing data:
 
 3. Open your deployment’s side navigation menu (placed under the Elastic logo in the upper left corner) and go to **Dev Tools > Console**.
 
-    :::{image} ../../images/elasticsearch-reference-kibana-console.png
+    :::{image} /troubleshoot/images/elasticsearch-reference-kibana-console.png
     :alt: {{kib}} Console
     :screenshot:
     :::

troubleshoot/elasticsearch/start-ilm.md

@@ -39,7 +39,7 @@ In order to start {{ilm}} we need to go to Kibana and execute the [start command
 
 3. Open your deployment’s side navigation menu (placed under the Elastic logo in the upper left corner) and go to **Dev Tools > Console**.
 
-    :::{image} ../../images/elasticsearch-reference-kibana-console.png
+    :::{image} /troubleshoot/images/elasticsearch-reference-kibana-console.png
     :alt: {{kib}} Console
     :screenshot:
     :::
@@ -127,7 +127,7 @@ In order to start {{slm}} we need to go to Kibana and execute the [start command
 
 3. Open your deployment’s side navigation menu (placed under the Elastic logo in the upper left corner) and go to **Dev Tools > Console**.
 
-    :::{image} ../../images/elasticsearch-reference-kibana-console.png
+    :::{image} /troubleshoot/images/elasticsearch-reference-kibana-console.png
     :alt: {{kib}} Console
     :screenshot:
     :::

troubleshoot/elasticsearch/troubleshoot-migrate-to-tiers.md

@@ -30,7 +30,7 @@ In order to get the shards assigned we need to call the [migrate to data tiers r
 
 3. Open your deployment’s side navigation menu (placed under the Elastic logo in the upper left corner) and go to **Dev Tools > Console**.
 
-    :::{image} ../../images/elasticsearch-reference-kibana-console.png
+    :::{image} /troubleshoot/images/elasticsearch-reference-kibana-console.png
     :alt: {{kib}} Console
     :screenshot:
     :::

troubleshoot/elasticsearch/troubleshooting-shards-capacity-issues.md

@@ -31,7 +31,7 @@ If you’re confident your changes won’t destabilize the cluster, you can temp
 
 3. Open your deployment’s side navigation menu (placed under the Elastic logo in the upper left corner) and go to **Dev Tools > Console**.
 
-    :::{image} ../../images/elasticsearch-reference-kibana-console.png
+    :::{image} /troubleshoot/images/elasticsearch-reference-kibana-console.png
     :alt: {{kib}} Console
     :screenshot:
     :::
@@ -241,7 +241,7 @@ If you’re confident your changes won’t destabilize the cluster, you can temp
 
 3. Open your deployment’s side navigation menu (placed under the Elastic logo in the upper left corner) and go to **Dev Tools > Console**.
 
-    :::{image} ../../images/kibana-console.png
+    :::{image} /troubleshoot/images/kibana-console.png
     :alt: {{kib}} Console
     :screenshot:
     :::

troubleshoot/ingest/fleet/common-problems.md

@@ -371,14 +371,14 @@ If you want to omit the raw events from the diagnostic, add the flag `--exclude-
 2. In the **Host** column, click the agent’s name.
 3. Select the **Diagnostics** tab and click the **Request diagnostics .zip** button.
 
-    :::{image} ../../../images/fleet-collect-agent-diagnostics1.png
+    :::{image} /troubleshoot/images/fleet-collect-agent-diagnostics1.png
     :alt: Collect agent diagnostics under agent details
     :screenshot:
     :::
 
 4. In the **Request Diagnostics** pop-up, select **Collect additional CPU metrics** if you’d like detailed CPU data.
 
-    :::{image} ../../../images/fleet-collect-agent-diagnostics2.png
+    :::{image} /troubleshoot/images/fleet-collect-agent-diagnostics2.png
     :alt: Collect agent diagnostics confirmation pop-up
     :screenshot:
     :::

troubleshoot/kibana/access.md

@@ -43,7 +43,7 @@ The status page displays information about the server resource usage and install
 
 To view the {{kib}} status page, use the status endpoint. For example, `localhost:5601/status`.
 
-:::{image} ../../images/kibana-kibana-status-page-7_14_0.png
+:::{image} /troubleshoot/images/kibana-kibana-status-page-7_14_0.png
 :alt: Kibana server status page
 :screenshot:
 :::

troubleshoot/kibana/alerts.md

@@ -32,7 +32,7 @@ The following debugging tools are available:
 
 **{{rules-ui}}** in **{{stack-manage-app}}** lists the rules available in the space you’re currently in. When you click a rule name, you are navigated to the [details page](../../explore-analyze/alerts-cases/alerts/create-manage-rules.md#rule-details) for the rule, where you can see currently active alerts. The start date on this page indicates when a rule is triggered, and for what alerts. In addition, the duration of the condition indicates how long the instance is active.
 
-:::{image} ../../images/kibana-rule-details-alerts-inactive.png
+:::{image} /troubleshoot/images/kibana-rule-details-alerts-inactive.png
 :alt: Alerting management details
 :screenshot:
 :::
@@ -42,7 +42,7 @@ The following debugging tools are available:
 
 When creating or editing an index threshold rule, you see a graph of the data the rule will operate against, from some date in the past until now, updated every 5 seconds.
 
-:::{image} ../../images/kibana-index-threshold-chart.png
+:::{image} /troubleshoot/images/kibana-index-threshold-chart.png
 :alt: Index Threshold chart
 :screenshot:
 :::
@@ -81,7 +81,7 @@ The result of this HTTP request (and printed to stdout by [kbn-action](https://g
 
 The **{{stack-manage-app}}** > **{{rules-ui}}** page contains an error banner that helps to identify the errors for the rules:
 
-:::{image} ../../images/kibana-rules-management-health.png
+:::{image} /troubleshoot/images/kibana-rules-management-health.png
 :alt: Rule management page with the errors banner
 :screenshot:
 :::

troubleshoot/kibana/maps.md

@@ -16,12 +16,12 @@ Use the information in this section to inspect Elasticsearch requests and find s
 
 Maps uses the [{{es}} vector tile search API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-search-mvt) and the [{{es}} search API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-search) to get documents and aggregation results from {{es}}. Use **Vector tiles** inspector to view {{es}} vector tile search API requests. Use **Requests** inspector to view {{es}} search API requests.
 
-:::{image} ../../images/kibana-vector_tile_inspector.png
+:::{image} /troubleshoot/images/kibana-vector_tile_inspector.png
 :alt: vector tile inspector
 :screenshot:
 :::
 
-:::{image} ../../images/kibana-requests_inspector.png
+:::{image} /troubleshoot/images/kibana-requests_inspector.png
 :alt: requests inspector
 :screenshot:
 :::

troubleshoot/monitoring/cluster-response-time.md

@@ -11,7 +11,7 @@ Your {{es}} cluster is humming along nicely with good performance until you sudd
 
 Initially, you think that perhaps memory pressure is to blame, because you already know that [high memory pressure can cause performance issues](/troubleshoot/monitoring/high-memory-pressure.md). You look at the **Cluster Performance Metrics** section of the [{{ecloud}} Console](https://cloud.elastic.co?page=docs&placement=docs-body) and, after some zooming in to the right time frame, you get these metrics:
 
-:::{image} /images/cloud-metrics-response-times.png
+:::{image} /troubleshoot/images/cloud-metrics-response-times.png
 :alt: Cluster performance metrics
 :::
 

troubleshoot/monitoring/deployment-health-warnings.md

@@ -10,7 +10,7 @@ mapped_pages:
 
 The {{ecloud}} [Deployments](https://cloud.elastic.co/deployments) page shows the current status of your active deployments. From time to time you may get one or more health warnings, such as the following:
 
-:::{image} /images/cloud-ec-ce-deployment-health-warning.png
+:::{image} /troubleshoot/images/cloud-ec-ce-deployment-health-warning.png
 :alt: A screen capture of the deployment page showing a typical warning: Deployment health warning: Latest change to {{es}} configuration failed.
 :::
 

troubleshoot/monitoring/high-availability.md

@@ -13,7 +13,7 @@ You created a new {{ech}} deployment that uses three availability zones and inde
 
 To answer this question, let’s take a look at CPU usage in the **Cluster Performance Metrics** section in the [{{ecloud}} Console](https://cloud.elastic.co?page=docs&placement=docs-body):
 
-:::{image} /images/cloud-metrics-cpu.png
+:::{image} /troubleshoot/images/cloud-metrics-cpu.png
 :alt: CPU usage over time
 :::