yandrey321 opened a new pull request, #11723:
URL: https://github.com/apache/ozone/pull/11723
## What changes were proposed in this pull request?
**Problem.** Every Ozone client calls `TracingUtil.initTracing()`. With
tracing disabled but
`ozone.tracing.client.application-aware=true` (both defaults, HDDS-13803),
and no `GlobalOpenTelemetry` registered by
the application, `initialize()` builds Ozone's OpenTelemetry SDK right away:
- the OTLP exporter;
- a `BatchSpanProcessor` with its export thread;
- the `SdkTracerProvider`, registered as `GlobalOpenTelemetry`.
In this mode Ozone only creates a span under a valid parent span, which most
client processes never have, so all
of this usually goes unused. It costs about 80 ms and several hundred
classes in every cold client: YARN containers,
CLI commands, MapReduce tasks.
**Implementation idea.** In application-aware mode without an application
`GlobalOpenTelemetry`, `initialize()` now
only records that an SDK may be needed. The first span created under a valid
parent completes the initialization,
once, under the class lock:
- it adopts an application `GlobalOpenTelemetry` registered since then, if
there is one;
- otherwise it builds Ozone's SDK, exactly as before.
Spans are created under a parent in three places: `buildSpan` (a valid
current span), `importAndCreateSpan` (a
propagated parent) and `createActivatedSpanFromW3cHttpHeaders` (a valid
remote parent). Each calls `initPendingSdk()`
before using the tracer. `hasUsableTracer()` counts a pending SDK as usable,
so `isTracingActive()` and
`createProxy()` behave as before.
**Key decisions.**
- **Only application-aware mode changes.** With `ozone.tracing.enabled=true`
the SDK is still built at init, because
Ozone can start root spans at once.
- **The pending state is cleared even if building the SDK fails.** The
failure is logged once, as at init before.
- **Adopting a global registered later is new.** An application that
registers its `GlobalOpenTelemetry` after
creating the Ozone client now gets its spans into its own SDK. Before,
Ozone had already installed its own SDK as
the global, so the application's `GlobalOpenTelemetry.set()` failed.
**Side effects.**
- In application-aware mode, Ozone registers its SDK as
`GlobalOpenTelemetry` at the first traced call instead of at
client creation. A co-resident library that reads `GlobalOpenTelemetry`
before then sees the default no-op instance,
as in a process with tracing turned off.
- The export thread only exists after the first traced call.
Generated-by: Claude Code (Claude Opus 5.5)
## What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-17350
## How was this patch tested?
- **New tests in `TestTracingInitModes`**, all with no application global
unless stated:
- application-aware mode without a parent span builds nothing and
registers no global, while tracing still
counts as active and no root span is created;
- the first span under a valid parent builds Ozone's SDK and continues the
parent's trace;
- a `GlobalOpenTelemetry` that the application registers after init is
adopted; a recording exporter shows that
the child span went to the application's SDK;
- with tracing enabled, the SDK is still built at init.
A mutation check (always building the SDK at init) fails three of the four
tests.
- **Existing tests:** all `TestTracing*` and `TestSpanSampling` tests in
hdds-common (43), and
`TestFailoverWithSCMHA`, which wraps SCM clients with
`TracingUtil.createProxy`.
- **Measurement**, on JDK 17 (17.0.20.1), same build. The change has no
switch back to the eager behaviour, so the
eager arm enables tracing, which builds the same SDK at init:
- `TracingUtil.initTracing()` in a fresh JVM, 9 runs: 98 ms and 772 extra
classes when the SDK is built at init →
**16 ms and 149 classes** in application-aware mode now (−82 ms). The
rest is the tracing configuration and the
OpenTelemetry API.
- Cold `ofs://` client on the secure `ozonesecure` compose cluster (create
the client, getFileStatus, read 64 KB,
close), 10 interleaved rounds: the default application-aware mode takes
**1,244 ms**, against **1,239 ms** with
`ozone.tracing.client.application-aware=false` (tracing off). The 5 ms
difference is within noise, so the default
no longer pays for tracing.
| JVM | change |
|---|---|
| localizer: localization time (main band of 63 localizations at about
1.6 s) | −78 ms median, −81 ms mean (standard error about 0.015 s) |
| AppMaster start-up | −54 ms |
| map start-up | −38 ms median, −53 ms mean |
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
