Behind the Code: Design Choices in OpenTelemetry .NET Metrics API and SDK
summary
OpenTelemetry .NET Metrics API and SDK aim for zero heap allocation by adding overloads for 1–3 attributes, a stack-only ReadOnlySpan handoff and a struct TagList that stays allocation-free up to eight tags. The SDK uses a read-optimized dictionary that points to separate metric points updated with atomic ops, avoids costly attribute sorting by caching the first-seen attribute order, and runs long stress tests. Results show roughly 50M measurements/sec on a 16‑core machine with per-measurement latency as low as ~10 ns for simple cases.
AI-written summary · about
chapters (11)
- 0:00Introduction
- 1:45Design goals for OpenTelemetry .NET Metrics
- 4:57Zero-allocation API design
- 6:21SDK architecture challenges
- 8:48Dictionary contention in SDK
- 11:38Attribute sorting optimization
- 14:05Zero-allocation data transfer
- 15:48Benchmark results
- 16:52Testing reliability
- 17:14Best practices for SDK
- 18:19Future challenges
related talks
01h 01mPractical OpenTelemetry in .NET 8
01h 00mPractical OpenTelemetry for .NET
53mOpenTelemetry Metrics: observability’s holy grail
01h 01mPractical OpenTelemetry for .NET
43mWhat is this OpenTelemetry thing?
21mNative Instrumentation for Open Source Software with OpenTelemetry
26mScaling OpenTelemetry for Modern Workloads: From Mobile To Ma...
20mObservability and Open Telemetry