Björn Rabenstein

Let's reimplement Prometheus in Rust… :duck:

> `rate(my_counter[]) * ` That's the same as `increase(my_counter[])`, isn't it? And generally, yes, I think this is pretty much what we discussed earlier, which would also allow burn-down graphs...

Would `[since TIMESTAMP]` be fundamentally different from the already suggested `[@TIMESTAMP]`?

> The @ symbol would suggest an instantaneous point in time Which we already support, i.e. `my_metric @ TIMESTAMP`. Since `[...]` is well known already as a range selector, `[@...]`...

I would say the conclusions we came up here are still too vague to inform an actual implementation. Thus, I would expect if someone just came up with a PR,...

> Nothing jumps out at me as being at all similar to this integration idea. Maybe I have misunderstood something, but isn't the section about [Richer syntax for range selectors...

Strictly speaking, the support has to be added to https://github.com/prometheus/common in the expfmt package. Note, however, that OpenMetrics is not very well suited for the text file collector because it...

> That's probably a client_golang bug then […] I can see this happening if you have a gzipped response, and then there's a problem encoding a metric family. Sorry for...

How about `+Inf` in that case? It looks we have no way of determining the true value. We cannot use the string "unlimited" as the value of the metric, but...

How many fields in the `ProcLimits` could have that "unlimited" string in their source field? If that's common, perhaps change the value from `uint64` to a struct `{uint64, bool}` where...