Move performance to java agent, merge javadoc into API page (open-telemetry#5590)

Co-authored-by: Patrice Chalin <[email protected]>

Author: 2 people

content/en/docs/collector/deployment/agent.md

@@ -129,7 +129,7 @@ Cons:
 [instrumentation]: /docs/languages/
 [otlp]: /docs/specs/otel/protocol/
 [collector]: /docs/collector/
-[instrument-java-metrics]: /docs/languages/java/api-components/#meterprovider
+[instrument-java-metrics]: /docs/languages/java/api/#meterprovider
 [otlp-exporter]: /docs/specs/otel/protocol/exporter/
 [java-otlp-example]:
   https://github.com/open-telemetry/opentelemetry-java-docs/tree/main/otlp

content/en/docs/concepts/instrumentation/libraries.md

@@ -267,8 +267,8 @@ After you create a span, pass new trace context to the application code
 (callback or handler), by making the span active; if possible, do this
 explicitly. The following Java example shows how to add trace context and
 activate a span. See the
-[Context extraction in Java](/docs/languages/java/api-components/#contextpropagators),
-for more examples.
+[Context extraction in Java](/docs/languages/java/api/#contextpropagators), for
+more examples.
 
 ```java
 // extract the context

content/en/docs/languages/java/api-components.md

@@ -11,10 +11,9 @@ cSpell:ignore: authservice autoconfigured blrp Customizer Dotel ignore LOWMEMORY
 <?code-excerpt path-base="examples/java/configuration"?>
 
 The [SDK](../sdk/) is the built-in reference implementation of the
-[API](../api-components/), processing and exporting telemetry produced by
-instrumentation API calls. Configuring the SDK to process and export
-appropriately is an essential step to integrating OpenTelemetry into an
-application.
+[API](../api/), processing and exporting telemetry produced by instrumentation
+API calls. Configuring the SDK to process and export appropriately is an
+essential step to integrating OpenTelemetry into an application.
 
 All SDK components have
 [programmatic configuration APIs](#programmatic-configuration). This is the most

content/en/docs/languages/java/api.md

@@ -13,8 +13,8 @@ cSpell:ignore: Logback logback
 
 <!-- markdownlint-disable no-duplicate-heading -->
 
-Instrumentation records telemetry using the [API](../api-components/). The
-[SDK](../sdk/) is the built-in reference implementation of the API, and is
+Instrumentation records telemetry using the [API](../api/). The [SDK](../sdk/)
+is the built-in reference implementation of the API, and is
 [configured](../configuration/) to process and export the telemetry produced by
 instrumentation API calls. This page discusses the OpenTelemetry ecosystem in
 OpenTelemetry Java, including resources for end users and cross-cutting
@@ -100,8 +100,8 @@ Instrumentation" column on
 
 [Native instrumentation](/docs/specs/otel/glossary/#natively-instrumented) is
 built directly into libraries or frameworks. OpenTelemetry encourages library
-authors to add native instrumentation using the [API](../api-components/). In
-the long term, we hope the native instrumentation becomes the norm, and view the
+authors to add native instrumentation using the [API](../api/). In the long
+term, we hope the native instrumentation becomes the norm, and view the
 instrumentation maintained by OpenTelemetry in
 [opentelemetry-java-instrumentation](https://github.com/open-telemetry/opentelemetry-java-instrumentation)
 as a temporary means of filling the gap.
@@ -152,20 +152,17 @@ context:
 
 For this correlation to work, trace context must be propagated throughout an
 application (across function calls and threads), and across application
-boundaries. The [context API](../api-components/#context-api) facilitates this.
+boundaries. The [context API](../api/#context-api) facilitates this.
 Instrumentation needs to be written in a manner which is context aware:
 
 - Libraries that represent the entry point to an application (i.e. HTTP servers,
-  message consumers, etc.) should
-  [extract context](../api-components/#contextpropagators) from incoming
-  messages.
+  message consumers, etc.) should [extract context](../api/#contextpropagators)
+  from incoming messages.
 - Libraries that represent an exit point from an application (i.e. HTTP clients,
-  message producers, etc.) should
-  [inject context](../api-components/#contextpropagators) into outgoing
-  messages.
-- Libraries should implicitly or explicitly pass
-  [Context](../api-components/#context) through the callstack and across any
-  threads.
+  message producers, etc.) should [inject context](../api/#contextpropagators)
+  into outgoing messages.
+- Libraries should implicitly or explicitly pass [Context](../api/#context)
+  through the callstack and across any threads.
 
 ## Semantic conventions
 
@@ -177,21 +174,20 @@ attribute key, value, and requirement levels.
 When writing instrumentation, consult the semantic conventions and conform to
 any which are applicable to the domain.
 
-OpenTelemetry Java [publishes artifacts](../api-components/#semantic-attributes)
-to assist in conforming to the semantic conventions, including generated
-constants for attribute keys and values.
+OpenTelemetry Java [publishes artifacts](../api/#semantic-attributes) to assist
+in conforming to the semantic conventions, including generated constants for
+attribute keys and values.
 
 TODO: discuss instrumentation API and how it helps conform to semantic
 conventions
 
 ## Log instrumentation
 
-While the [LoggerProvider](../api-components/#loggerprovider) /
-[Logger](../api-components/#logger) APIs are structurally similar to the
-equivalent [trace](../api-components/#tracerprovider) and
-[metric](../api-components/#meterprovider) APIs, they serve a different use
-case. As of now, `LoggerProvider` / `Logger` and associated classes represent
-the [Log Bridge API](/docs/specs/otel/logs/api/), which exists to write log
+While the [LoggerProvider](../api/#loggerprovider) / [Logger](../api/#logger)
+APIs are structurally similar to the equivalent [trace](../api/#tracerprovider)
+and [metric](../api/#meterprovider) APIs, they serve a different use case. As of
+now, `LoggerProvider` / `Logger` and associated classes represent the
+[Log Bridge API](/docs/specs/otel/logs/api/), which exists to write log
 appenders to bridge logs recorded through other log APIs / frameworks into
 OpenTelemetry. They are not intended for end user use as a replacement for Log4j
 / SLF4J / Logback / etc.

content/en/docs/languages/java/configuration.md

@@ -45,7 +45,7 @@ The OpenTelemetry Java documentation is organized as follows:
   Java instrumentation ecosystem. This is a key resource for application authors
   looking to integrate OpenTelemetry Java into applications. Learn about the
   different categories of instrumentation, and decide which is right for you.
-- [Record Telemetry with API](../api-components/): A technical reference for the
+- [Record Telemetry with API](../api/): A technical reference for the
   OpenTelemetry API, exploring all key aspects of the API with working code
   examples. Most users will use this page like an encyclopedia, consulting the
   index of sections as needed, rather than reading front to back.
@@ -62,7 +62,8 @@ The OpenTelemetry Java documentation is organized as follows:
   sections as needed, rather than reading front to back.
 - **Learn More**: Supplementary resources, including end-to-end
   [examples](../examples/), [Javadoc](../api/), component
-  [registry](../registry/), and a [performance reference](../performance/).
+  [registry](../registry/), and a
+  [performance reference](/docs/zero-code/java/agent/performance/).
 
 ## Repositories
 

content/en/docs/languages/java/instrumentation.md

@@ -7,13 +7,12 @@ cSpell:ignore: autoconfigured FQCNs Interceptable Logback okhttp
 <!-- markdownlint-disable blanks-around-fences -->
 <?code-excerpt path-base="examples/java/configuration"?>
 
-The SDK is the built-in reference implementation of the
-[API](../api-components/), processing and exporting telemetry produced by
-instrumentation API calls. This page is a conceptual overview of the SDK,
-including descriptions, links to relevant Javadocs, artifact coordinates, sample
-programmatic configurations and more. See
-**[Configure the SDK](../configuration/)** for details on SDK configuration,
-including
+The SDK is the built-in reference implementation of the [API](../api/),
+processing and exporting telemetry produced by instrumentation API calls. This
+page is a conceptual overview of the SDK, including descriptions, links to
+relevant Javadocs, artifact coordinates, sample programmatic configurations and
+more. See **[Configure the SDK](../configuration/)** for details on SDK
+configuration, including
 [zero-code SDK autoconfigure](../configuration/#zero-code-sdk-autoconfigure).
 
 The SDK consists of the following top level components:
@@ -74,8 +73,8 @@ component section includes:
 ### OpenTelemetrySdk
 
 [OpenTelemetrySdk](https://www.javadoc.io/doc/io.opentelemetry/opentelemetry-sdk/latest/io/opentelemetry/sdk/OpenTelemetrySdk.html)
-is the SDK implementation of [OpenTelemetry](../api-components/#opentelemetry).
-It is a holder for top-level SDK components which makes it convenient to pass
+is the SDK implementation of [OpenTelemetry](../api/#opentelemetry). It is a
+holder for top-level SDK components which makes it convenient to pass
 fully-configured SDK components to instrumentation.
 
 `OpenTelemetrySdk` is configured by the application owner, and consists of:
@@ -151,9 +150,8 @@ public class ResourceConfig {
 ### SdkTracerProvider
 
 [SdkTracerProvider](https://www.javadoc.io/doc/io.opentelemetry/opentelemetry-sdk-trace/latest/io/opentelemetry/sdk/trace/SdkTracerProvider.html)
-is the SDK implementation of
-[TracerProvider](../api-components/#tracerprovider), and is responsible for
-handling trace telemetry produced by the API.
+is the SDK implementation of [TracerProvider](../api/#tracerprovider), and is
+responsible for handling trace telemetry produced by the API.
 
 `SdkTracerProvider` is configured by the application owner, and consists of:
 
@@ -560,8 +558,8 @@ public class SpanLimitsConfig {
 ### SdkMeterProvider
 
 [SdkMeterProvider](https://www.javadoc.io/doc/io.opentelemetry/opentelemetry-sdk-metrics/latest/io/opentelemetry/sdk/metrics/SdkMeterProvider.html)
-is the SDK implementation of [MeterProvider](../api-components/#meterprovider),
-and is responsible for handling metric telemetry produced by the API.
+is the SDK implementation of [MeterProvider](../api/#meterprovider), and is
+responsible for handling metric telemetry produced by the API.
 
 `SdkMeterProvider` is configured by the application owner, and consists of:
 
@@ -929,9 +927,8 @@ public class ViewConfig {
 ### SdkLoggerProvider
 
 [SdkLoggerProvider](https://www.javadoc.io/doc/io.opentelemetry/opentelemetry-sdk-logs/latest/io/opentelemetry/sdk/logs/SdkLoggerProvider.html)
-is the SDK implementation of
-[LoggerProvider](../api-components/#loggerprovider), and is responsible for
-handling log telemetry produced by the log bridge API.
+is the SDK implementation of [LoggerProvider](../api/#loggerprovider), and is
+responsible for handling log telemetry produced by the log bridge API.
 
 `SdkLoggerProvider` is configured by the application owner, and consists of:
 

content/en/docs/languages/java/intro.md

@@ -1,7 +1,9 @@
 ---
 title: Performance
 description: Performance reference for the OpenTelemetry Java agent
-weight: 75
+weight: 400
+aliases:
+  - /docs/languages/java/performance/
 cSpell:ignore: Dotel
 ---
 
@@ -40,7 +42,7 @@ the Java agent.
 
 The volume of spans processed by the instrumentation might impact agent
 overhead. You can configure trace sampling to adjust the span volume and reduce
-resource usage. See [Sampling](../sdk/#sampler).
+resource usage. See [Sampling](/docs/languages/java/sdk/#sampler).
 
 ### Turn off specific instrumentations
 
@@ -99,7 +101,7 @@ instrumentations, see
 When troubleshooting agent overhead issues, do the following:
 
 - Check minimum requirements. See
-  [Prerequisites](../getting-started/#prerequisites).
+  [Prerequisites](/docs/languages/java/getting-started/#prerequisites).
 - Use the latest compatible version of the Java agent.
 - Use the latest compatible version of your JVM.
 

content/en/docs/languages/java/sdk.md

@@ -8859,6 +8859,10 @@
     "StatusCode": 200,
     "LastSeen": "2024-10-09T10:19:30.617798+02:00"
   },
+  "https://javadoc.io/doc/io.opentelemetry": {
+    "StatusCode": 200,
+    "LastSeen": "2024-11-13T09:26:22.921349-05:00"
+  },
   "https://javadoc.io/doc/io.opentelemetry/opentelemetry-exporter-prometheus/latest": {
     "StatusCode": 200,
     "LastSeen": "2024-01-30T16:14:53.216459-05:00"