Merge pull request #965 from colleenmcginnis/docs-clean-up

[docs] Miscellaneous docs clean up

Author: marciw

docs/docset.yml

@@ -55,7 +55,7 @@ CreateIndexResponse createResponse = client.indices()
     );
 ```
 
-Builder lambdas become particularly useful with complex nested queries like the one below, taken from the [intervals query API documentation](elasticsearch://reference/query-languages/query-dsl-intervals-query.md).
+Builder lambdas become particularly useful with complex nested queries like the one below, taken from the [intervals query API documentation](elasticsearch://reference/query-languages/query-dsl/query-dsl-intervals-query.md).
 
 This example also highlights a useful naming convention for builder parameters in deeply nested structures. For lambda expressions with a single argument, Kotlin provides the implicit `it` parameter and Scala allows use of `_`. This can be approximated in Java by using an underscore or a single letter prefix followed by a number representing the depth level (i.e. `_0`, `_1`, or `b0`, `b1` and so on). Not only does this remove the need to create throw-away variable names, but it also improves code readability. Correct indentation also allows the structure of the query to stand out.
 

docs/reference/building-objects.md

@@ -86,13 +86,13 @@ esClient.close();
 
 Your Elasticsearch endpoint can be found on the **My deployment** page of your deployment:
 
-:::{image} ../images/es-endpoint.jpg
+:::{image} images/es-endpoint.jpg
 :alt: Finding Elasticsearch endpoint
 :::
 
 You can generate an API key on the **Management** page under Security.
 
-:::{image} ../images/create-api-key.png
+:::{image} images/create-api-key.png
 :alt: Create API key
 :::
 

docs/reference/getting-started.md

@@ -9,21 +9,21 @@ You can use [OpenTelemetry](https://opentelemetry.io/) to monitor the performanc
 
 The native instrumentation in the Java API 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 Java API Client. The following image shows a trace that records the handling of three different {{es}} requests: an `index`, `get` and a search `request`:
 
-:::{image} ../images/otel-waterfall-instrumented-without-http.jpg
+:::{image} images/otel-waterfall-instrumented-without-http.jpg
 :alt: Distributed trace with {{es}} spans
 :class: screenshot
 :::
 
 Usually, OpenTelemetry agents and 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-instrumented.jpg
+:::{image} images/otel-waterfall-instrumented.jpg
 :alt: Distributed trace with {{es}} and HTTP spans
 :class: screenshot
 :::
 
 Advanced Java API 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 an `index` request in a scenario with two {{es}} nodes:
 
-:::{image} ../images/otel-waterfall-retries.jpg
+:::{image} images/otel-waterfall-retries.jpg
 :alt: Distributed trace with request retries
 :class: screenshot
 :::