No Dependencies. No Plugins. Just Native OpenTelemetry
summary
Azure SDKs for Java implement an optional runtime dependency pattern: library code calls an internal abstraction and uses reflection to enable OpenTelemetry only if otel API is on the classpath, avoiding transitive conflicts (demo shows Maven picking 1.42 vs 1.51 causes runtime errors). The client-core is dependency-free, instrumentation activates when OTel is present, and when not present the SDK emits logs-based tracing fallback. Measured overhead is about ~100 ns per span.
AI-written summary · about
chapters (10)
- 0:00Native OpenTelemetry intro
- 1:06Why libraries need observability
- 2:35OpenTelemetry dependency challenges
- 5:45Diamond dependency demo
- 8:58Shading and plugins limits
- 10:46Optional dependency solution
- 12:12Java optional dependency demo
- 14:20Testing and robustness
- 15:44Reflection performance overhead
- 16:27Graceful degradation without OTel
related talks
21mNative Instrumentation for Open Source Software with OpenTelemetry
19mUsing Native OpenTelemetry Instrumentation to Make Client Libraries Better
32mOpenTelemetry feat. logs, metrics and traces
30mInstrument Your Java Applications with OpenTelemetry!
20mObservability and Open Telemetry
22mOpenTelemetry – An Observability Framework for Cloud-Native Software
27mBuilt-in OpenTelemetry support in Elasticsearch clients
36mObservability For You and Me with OpenTelemetry