Repository navigation
Conversation
Define two progressive modes for io.prometheus.write.v2.Request: stateless (requiring Exemplars attached to samples/histograms, Histogram messages for histograms, and Metadata.type with optional METRIC_TYPE_GAUGE fallback for unknown types) and stateless-st (extending stateless with mandatory start_timestamp on cumulative metric types). Signed-off-by: Bartek Plotka <bwplotka@gmail.com>
bwplotka
commented
Oct 20, 2026
Signed-off-by: Bartek Plotka <bwplotka@gmail.com>
…TYPE_COUNTER fallback Signed-off-by: Bartek Plotka <bwplotka@gmail.com>
bwplotka
commented
Oct 20, 2026
bwplotka
commented
Oct 21, 2026
Member
Author
|
|
…xemplars Signed-off-by: Bartek Plotka <bwplotka@gmail.com>
bwplotka
commented
Oct 21, 2026
| #### Unsupported Request Content | ||
|
|
||
| Receivers MUST return [415 HTTP Unsupported Media Type](https://www.rfc-editor.org/rfc/rfc9110.html#name-415-unsupported-media-type) status code if they don't support a given content type or encoding provided by Senders. | ||
| Receivers MUST return [415 HTTP Unsupported Media Type](https://www.rfc-editor.org/rfc/rfc9110.html#name-415-unsupported-media-type) status code if they don't support a given content type or encoding provided by Senders. When returning `415 HTTP Unsupported Media Type`, Receivers SHOULD include the `Accept` (listing supported `Content-Type` values, including supported `;proto=` and `;mode=` parameters) and `Accept-Encoding` (listing supported `Content-Encoding` values) response headers as defined in [RFC 7694](https://www.rfc-editor.org/rfc/rfc7694.html) so Senders can determine what the Receiver supports without guessing. |
Member
Author
There was a problem hiding this comment.
FYI: @kgeckhart I think this solves our discoverability of supported modes problem 👍🏽
| For the message introduced in PRW 2.0, identified by `io.prometheus.write.v2.Request`: | ||
|
|
||
| * `Content-Type: application/x-protobuf;proto=io.prometheus.write.v2.Request` | ||
| * `Content-Type: application/x-protobuf;proto=io.prometheus.write.v2.Request;mode=none` (equivalent to omitting `;mode=`; see [Modes](#modes)) |
Member
Author
There was a problem hiding this comment.
addressing #3142 (comment) - I think "none" is a good name
Member
Author
|
Should be ready to go @kgeckhart @krajorama @kgeckhart do you plan to propose gzip (can help with that if you won't have time to do it) in rc.6? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Alternative to #3129 and #3142.
Specify two progressive modes (
statelessandstateless-st) forio.prometheus.write.v2.Requestin Remote-Write2.0-rc.6, following the Prometheus Dev Summit consensus and RFC 9413.By default, when no
;mode=parameter is set onContent-Type: application/x-protobuf;proto=io.prometheus.write.v2.Request, all field permutations permitted by the base specification may be sent.2.0-rc.6adds two optional, progressive modes where sendersMUSTguarantee:statelessmode (Content-Type: application/x-protobuf;proto=io.prometheus.write.v2.Request;mode=stateless):Exemplars are attached to aTimeSeriesthat contains at least one sample or histogram, so no exemplar-onlyTimeSeriesare sent.Histogrammessage, so classic histograms are sent as NHCB instead of_bucket,_sum, and_countfloat series.Metadata.typeis set and notMETRIC_TYPE_UNSPECIFIED. For series with an unknown metric type, such asuntypedscraped metrics or recording rule outputs, sendersMAYassumeMETRIC_TYPE_GAUGE.stateless-stmode (Content-Type: application/x-protobuf;proto=io.prometheus.write.v2.Request;mode=stateless-st):statelessmode.start_timestampis set (non-zero) on every sample and histogram, except stale markers, forMETRIC_TYPE_COUNTER,METRIC_TYPE_HISTOGRAM, andMETRIC_TYPE_SUMMARY_sumand_count.Both modes are optional for senders and receivers and remain valid
io.prometheus.write.v2.Requestpayloads on the wire.Why this split?
statelessmode bundles everything needed for self-contained, typedTimeSeriesmessages: attached exemplars, structured histograms, and an explicitMetadata.type. Any sender can enforcestatelessmode without tracking cross-scrape counter start timestamps, and receivers can validate histogram structure becauseMetadata.typeis always set.stateless-stisolatesstart_timestampinto a second progressive level becausestart_timestampdepends on upstream instrumentation exposing created timestamps or stateful sender-side synthesis, and adds per-sample wire overhead on cumulative series that not all receivers need.default<stateless<stateless-st) give 3 well-defined protocol states rather thanContent-Typematching to a single parameter value, and makestatelessa candidate for a future 3.0 default while keepingstateless-stoptional.Draft of the implementation on Prometheus side: prometheus/prometheus#20098