Why I Recommend Native Prometheus Instrumentation over OpenTelemetry
summary
Recommendation: use Prometheus client libraries for Prometheus metrics because native instrumentation preserves service discovery + pull semantics and per-target up/health signals, avoids metric-name and label translation surprises, and sidesteps extra Prometheus config like enabling an OTLP receiver must be enabled push endpoint and out‑of‑order sample windows. OpenTelemetry SDKs add complexity and slower hot paths (benchmarks show up to 22x faster counter increments with the Prometheus Go client), and you trade easy text exposition for heavier protocols and config.
AI-written summary · about
chapters (11)
- 0:00Introduction
- 1:04Why this talk
- 3:08Prometheus vs OpenTelemetry
- 5:59Service discovery loss
- 9:10Metric name translation
- 12:47Resource attributes
- 14:11Prometheus config for OTel
- 16:18Complexity and performance of OpenTelemetry SDKs
- 19:08Prometheus exposition simplicity
- 20:11Prometheus open standard
- 21:13Closing thoughts
related talks
24mLeveraging OpenTelemetry for Your Prometheus Pipeline
27mThe State of Prometheus and OpenTelemetry Interoperability
47mGet Instrumented: How Prometheus Can Unify Your Metrics
06mIgnite | Discovering the Magic Behind OpenTelemetry Instrumentation
36mShould I use OTel (collectors), or is Prometheus good enough?
22mBuilding Prometheus Metrics Support in OpenTelemetry
20mObservability and Open Telemetry
30mOpenTelemetry 101