You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
otlp: refactor config API and deprecate legacy handler
This commit improves the OTLP handler API and prepares for v6 by
deprecating the legacy alpha handler implementation.
Breaking Changes:
- Rename SDKConfig.Endpoint to EndpointURL to clarify it requires
a full URL with scheme (http:// or https://)
- Use WithEndpointURL instead of WithEndpoint to avoid known gRPC bug
when using http:// scheme
- Remove enforced defaults for ExportInterval and ExportTimeout,
allowing SDK to use its own defaults (60s and 30s respectively)
Deprecations:
- Deprecate otlp.Handler (Alpha since 2022, minimal usage)
- Deprecate otlp.HTTPClient
- Deprecate otlp.NewHTTPClient()
All will be removed in v6.0.0. Migration path provided in deprecation
notices with code examples.
Improvements:
- Add Example_fullyConfiguredByEnvironment showing empty SDKConfig usage
- Enhance IMPLEMENTATION_NOTES.md with user-focused temporality explanation
- Clarify instrument caching is internal implementation detail
- Update all examples and tests to use EndpointURL with proper scheme
- Add blank lines around markdown lists to fix linting warnings
Documentation:
- Update HISTORY.md with comprehensive v5.9.0 release notes
- Document breaking changes and migration path
- Add notes about exponential histograms and temporality configuration
- Update all code examples throughout documentation
All tests pass. No functional changes to SDKHandler behavior.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
**Why**: Instruments are created once per metric name and reused. This pattern minimizes lock contention in the hot path (metric recording) while ensuring thread-safety during instrument creation.
71
+
**Why**: OpenTelemetry instruments are expensive to create but cheap to reuse. This pattern:
72
+
73
+
-**Minimizes lock contention** in the hot path (metric recording uses fast read locks)
74
+
-**Ensures thread-safety** during instrument creation (write locks only when needed)
75
+
-**Scales well** under concurrent load (multiple goroutines can look up instruments simultaneously)
76
+
77
+
The double-check pattern prevents duplicate instrument creation when multiple goroutines race to create the same instrument for the first time.
70
78
71
79
### 4. Attribute Handling
72
80
@@ -227,38 +235,90 @@ if config.ExponentialHistogram {
227
235
228
236
## Temporality Configuration
229
237
230
-
### Default: Cumulative Temporality
238
+
### What is Temporality?
231
239
232
-
**Decision**: Use cumulative temporality for all metric instruments (Prometheus-compatible)
240
+
Temporality determines whether metrics are reported as **cumulative totals** (since application start) or **deltas** (change since last export).
233
241
234
-
**Implementation**: OTLP exporters use `DefaultTemporalitySelector` by default
235
-
```go
236
-
// If no TemporalitySelector is provided, the exporter uses:
237
-
// DefaultTemporalitySelector -> CumulativeTemporality for all instruments
238
-
```
242
+
**Example - Request Counter**:
243
+
-**Cumulative**: Export "1000 total requests" → "1150 total requests" → "1320 total requests"
244
+
-**Delta**: Export "1000 new requests" → "150 new requests" → "170 new requests"
-`sdkmetric.DefaultTemporalitySelector` - Cumulative for all (default, recommended)
317
+
-`sdkmetric.CumulativeTemporalitySelector` - Cumulative for all (explicit)
318
+
-`sdkmetric.DeltaTemporalitySelector` - Delta for all
319
+
-`sdkmetric.LowMemoryTemporalitySelector` - Delta for Counters/Histograms, Cumulative for UpDownCounters
320
+
321
+
**⚠️ Warning**: Changing temporality requires updating your backend configuration and queries. Most users should stick with the default cumulative temporality.
0 commit comments