OTEL delta temporality support in Prometheus
summary
Prometheus accepts OpenTelemetry delta metrics natively behind a feature flag instead of rejecting or converting them to cumulative, which avoids out‑of‑order rewrite problems but breaks Prometheus’ increase/rate semantics. Queries must use sum_over_time to total deltas, or rely on synthetic zero injection or the planned created timestamp per sample to detect resets and let increase work. The created‑timestamp approach is pursued next; function overloading is rejected for now.
AI-written summary · about
chapters (12)
- 0:00Introduction
- 1:06Cumulative temporality
- 5:02Delta temporality in OpenTelemetry
- 6:48First delta iteration
- 9:19Native delta ingestion
- 10:47Querying delta challenges
- 13:12Temporality metadata proposal
- 16:03Function overloading future
- 16:43Deltas as cumulative case
- 19:30Sample timestamp per delta
- 20:34Summary
- 22:00Q&A
related talks
11mTime Matters: Choosing Between Delta and Cumulative Metric Temporalities for Effective Monitoring
23mDoes It Add Up? Exploring the Delta Temporality in OpenTelemetry & Beyond
28mObservability Project Updates
27mThe State of Prometheus and OpenTelemetry Interoperability
03mPrometheus Project Updates
42mPrometheus Intro and Deep Dive
28mPrometheus 3.0 Overview
22mBuilding Prometheus Metrics Support in OpenTelemetry