This commit finally unlocks the ability for the Prometheus client
users of the Summary metric type to automatically get total counts
and sums partitioned by labels. It exposes them through two
synthetic variables, if the underlying data is present.
The following is the base case:
foo_samples{quantile=0.5} = <?>
foo_samples{quantile=0.99} = <?>
The following results with this change:
foo_samples{quantile=0.5} = <?>
foo_samples{quantile=0.99} = <?>
foo_samples_sum = <?>
foo_samples_count = <?>
Change-Id: I75b5ea0d8c851da8c0c82ed9c8ac0890e4238f87
Colliding labels can happen e.g. when an exporter job is scraped and already
includes "job" labels for its samples in /metrics. In this case, a
collisionPrefix of "exporter_" is added to the colliding target labels, but the
specifics (the collision prefix) are managed by Prometheus, not the client
library.
This commit introduces an incomplete processor that decodes varint
record length-delimited streams of io.prometheus.client.MetricFamily
Protocol Buffer messages. The Go client presently does not support
generation of said messages, but this will unblock a number of Java
changes.
This commit introduces all relevant server-side artifacts such that the
Result streams can be used by external parties for one-off tools and
such. This will ultimately better enable us to support additional
wireformats with much more ease.
Bernerd had suggested extracting the value decoders and bundling them
into the client library. After some reflection, I tend to agree with
this, since we can start breaking the onion of Prometheus itself and
localize the protocol management into its own scope.
A couple of major changes since moving:
- Protocol 0.0.2 has moved to a struct{} so that our tests can perform
value matching, which cannot be done against function literals.
- Processing now acquires options to dictate behavioral changes of
metrics bodies.
- Processing no longer closes the stream, thusly returning this to the
hands of the caller.
- Process() has been renamed to ProcessSingle to better convey that it
works on complete message bodies. This paves the way for better
streaming payload support that the next API version will offer.
* Drop `AsMarshallable()` from the Metric interface. Use
`json.Marshaler` and `MarshalJSON()`, and leverage JSON struct tags
where possible.
* Add `MarshalJSON()` to Registry and remove `dumpToWriter`, which
makes the registry handler much simpler.
In addition to simplifying some of the marshalling behavior, this also
has the nice side effect of cutting down the number of
`map[string]interface{}` instances.
Matt T. Proud