From 201b9c9d96f2071af127ee08dbad76fc1702a576 Mon Sep 17 00:00:00 2001 From: Colleen McGinnis Date: Wed, 16 Apr 2025 11:56:51 -0500 Subject: [PATCH] fix image paths for docs-assembler --- docs/reference/connecting.md | 16 ++++------------ docs/reference/getting-started.md | 8 ++------ docs/reference/opentelemetry.md | 18 ++++++------------ 3 files changed, 12 insertions(+), 30 deletions(-) diff --git a/docs/reference/connecting.md b/docs/reference/connecting.md index 76768e297..27bd224a2 100644 --- a/docs/reference/connecting.md +++ b/docs/reference/connecting.md @@ -16,9 +16,7 @@ This document contains code snippets to show you how to connect to various {{es} If you are using [Elastic Cloud](https://www.elastic.co/cloud), the client offers an easy way to connect to it. You need the Cloud ID that you can find in the cloud console, then your username and password. -:::{image} images/cloud_id.png -:alt: Cloud ID -::: +![Cloud ID](images/cloud_id.png) Once you have collected the Cloud ID you can use the client to connect to your Elastic Cloud instance, as follows: @@ -34,21 +32,15 @@ client = Elasticsearch::Client.new( You can also connect to the Cloud by using API Key authentication. You can generate an `API key` in the `Management` page under the section `Security`. -:::{image} images/cloud_api_key.png -:alt: API key -::: +![API key](images/cloud_api_key.png) When you click on `Create API key` you can choose a name and set the other options (eg. restrict privileges, expire after time, etc). -:::{image} images/api_key_name.png -:alt: Choose an API name -::: +![Choose an API name](images/api_key_name.png) After this step you will get the `API key` in the API keys page. -:::{image} images/cloud_api_key.png -:alt: API key -::: +![API key](images/cloud_api_key.png) **IMPORTANT**: you need to copy and store the `API key` in a secure place, since you will not be able to view it again in Elastic Cloud. diff --git a/docs/reference/getting-started.md b/docs/reference/getting-started.md index 82d5753b2..55b6e9cb2 100644 --- a/docs/reference/getting-started.md +++ b/docs/reference/getting-started.md @@ -38,15 +38,11 @@ client = Elasticsearch::Client.new( Your Elasticsearch endpoint can be found on the **My deployment** page of your deployment: -:::{image} images/es_endpoint.jpg -:alt: Finding Elasticsearch endpoint -::: +![Finding Elasticsearch endpoint](images/es_endpoint.jpg) You can generate an API key on the **Management** page under Security. -:::{image} images/create_api_key.png -:alt: Create API key -::: +![Create API key](images/create_api_key.png) For other connection options, refer to the [*Connecting*](/reference/connecting.md) section. diff --git a/docs/reference/opentelemetry.md b/docs/reference/opentelemetry.md index 6b512a99e..9ab636dd6 100644 --- a/docs/reference/opentelemetry.md +++ b/docs/reference/opentelemetry.md @@ -9,24 +9,18 @@ You can use [OpenTelemetry](https://opentelemetry.io/) to monitor the performanc The native instrumentation in the Ruby Client follows the [OpenTelemetry Semantic Conventions for {{es}}](https://opentelemetry.io/docs/specs/semconv/database/elasticsearch/). In particular, the instrumentation in the client covers the logical layer of {{es}} requests. A single span per request is created that is processed by the service through the Ruby Client. The following image shows a trace that records the handling of two different {{es}} requests: a `ping` request and a `search` request. -:::{image} images/otel-waterfall-without-http.png -:alt: Distributed trace with Elasticsearch spans -:class: screenshot -::: +% TO DO: Use `:class: screenshot` +![Distributed trace with Elasticsearch spans](images/otel-waterfall-without-http.png) Usually, OpenTelemetry auto-instrumentation modules come with instrumentation support for HTTP-level communication. In this case, in addition to the logical {{es}} client requests, spans will be captured for the physical HTTP requests emitted by the client. The following image shows a trace with both, {{es}} spans (in blue) and the corresponding HTTP-level spans (in red): -:::{image} images/otel-waterfall-with-http.png -:alt: Distributed trace with Elasticsearch spans -:class: screenshot -::: +% TO DO: Use `:class: screenshot` +![Distributed trace with Elasticsearch spans](images/otel-waterfall-with-http.png) Advanced Ruby Client behavior such as nodes round-robin and request retries are revealed through the combination of logical {{es}} spans and the physical HTTP spans. The following example shows a `search` request in a scenario with two nodes: -:::{image} images/otel-waterfall-retry.png -:alt: Distributed trace with Elasticsearch spans -:class: screenshot -::: +% TO DO: Use `:class: screenshot` +![Distributed trace with Elasticsearch spans](images/otel-waterfall-retry.png) The first node is unavailable and results in an HTTP error, while the retry to the second node succeeds. Both HTTP requests are subsumed by the logical {{es}} request span (in blue).