-
Notifications
You must be signed in to change notification settings - Fork 306
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't handle federation text output #54
Comments
As said in the discussion, this is a problem on the generation side, not on the parse side, see https://prometheus.io/docs/instrumenting/exposition_formats/#text-format-details I guess the problem is that the federation code creates one metric family per time series and doesn't bundle them. That's already wrong in the protobuf representation, and the text parser mirrors that. |
With the storage having no notion of metric families, that seems tricky to On Thu, Sep 8, 2016, 12:26 PM Björn Rabenstein notifications@github.com
|
I'll look into how much effort that is. I could imagine it's worth the savings in bandwidth and the reduced effort on the receiving side. We can also approach the problem from the other side (not mutually exclusive) by loosing the requirement of not repeating the TYPE and HELP lines (last mention wins). |
Instead of ordering, keeping a list of already-exposed metric TYPEs might be more efficient. Last one wins would not save any bandwidth. |
Yes, that's what I tried to say. There are two solutions to the problem, any would solve it, but both could be applied:
|
This acknowledges the fact that duplicate metrics in the slice passed to MetricFamilyToText will result in invalid text format. This is meant to document the status quo and bears no implication for the possible loosening of the text format spec, cf. #54.
This restriction has been annoying to deal with when writing exporters, as it prevents streaming. Especially for federation where some users are trying to dump entire Prometheus servers I think we should be going for approaches that don't require collating millions of time series. Duplicate time series we'll catch anyway due to out-of-order sample detection. |
"Last TYPE or HELP wins" will once more prevent streaming on the ingestion side. |
I don't think the exact semantics matter, and tbh I'd leave this explicitly unspecified. |
After another read of the spec, I ran into an explicit requirement to have unique metric family names even in the protobuf format: "Each MetricFamily within the same exposition must have a unique name." Also, we have more about the text format: "The TYPE line for a metric name has to appear before the first sample is reported for that metric name." I'd say even if we want to be more lenient, we have to clearly specify how to deal with dupes, and the above points more towards "first wins". Conclusion: The spec is more explicit than initially thought. The current federation exposition is clearly in breach of the spec. Making the requirements more lenient (or even "unspecify" them, about which I would have a really bad feeling) would be a change of the format, breaking existing consumer implementations. That needed to be expressed in a version bump. We should anyway think about versioning a bit more, the 0.0.4 we have right now appears inappropriate for a stable API. In any case, the course of action would be to first change and set the spec and then create implementations compliant with it (rather than creating non-compliant implementation and then adjust the spec to them). |
We have a number of issues around the exposition format by now. How about moving them all into the docs repo, with a dedicated label? We should have clarity on the spec before starting any work, and the spec lives in the docs repo. So it might be the best point to track those issues. |
This is for now a specification issue. I have filed prometheus/docs#547 for that. Closing this for now, as the course of action in prometheus/common heavily depends on the decision made there. |
Prometheus can't scrape the text version of it's own federation output, e.g.
From https://groups.google.com/forum/#!topic/prometheus-developers/ZVb2NjjUJ5A
The text was updated successfully, but these errors were encountered: