Exposition format: Termination marker for scrapes
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 717
- Forks
- 1.2k
- Avg merge
- 3d 15h
- Merged PRs (30d)
- 19
Description
Taken from the original issue https://github.com/prometheus/common/issues/14 :
To positively confirm the completion of a scrape (rather than only negatively detect an incomplete scrape by a connection error), a termination marker is needed.
Proposal:
If an exposition is meant to be terminated by a termination marker, it's content-type contains an additional parameter termination=marked. (It will still be possible to not use termination markers so that trivial one-line expositions are still possible by default.) Termination can be requested via the usual content-type negotiation, and should only be applied if requested.
With termination=marked, the following termination marker has to end the payload:
- A line
# END\nfor the text format. - A uvarint-encoded value of MaxUint32 in case of protobuf. (Has a length of 5 bytes - protobufs of that size cannot be encoded anymore but the value is any waymeant to be larger than a protobuf can reasonably be. Some protobuf implementation limit the size of a proto message at 64MiB anyway.)
An exposition with termination=marked and no termination marker is considered incomplete, which should be treated the same as an ingestion interrupted by a connection error.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading the linked original issue in prometheus/common and the proposal here, focusing on content-type negotiation and the text and protobuf termination markers. No files, tests, or entry points are named; completion would require a maintainer decision on scope and where this protocol change belongs.
Written by the indexing model from the issue text.
Assessment
- Domain
- api
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100