Add JSON as a format to the HTTP handler

[ghodss]

The prometheus golang client is very useful as a generic library to measure and expose metrics, even when the consumer is not prometheus. (It's being used in this way in the Kubernetes project.) In this case, or in any case where prometheus is not the sole consumer of an application's metrics, being able to consume the metrics from the HTTP endpoint as JSON dramatically helps the ability for tooling to consume and parse the metrics outputted by the golang client.

prom2json provides this functionality as a Go command-line tool, which only makes the functionality accessible to tools in other languages if you package and install the tool and call it in between HTTP calls to the client library. Integration directly into the client's metrics server would make things much easier.

[brian-brazil]

Hmm, this sounds like a case for a custom bridge. That is to say something that takes samples from the Registry and outputs them in the format of another monitoring system, in this case on a separate endpoint.

[juliusv]

@ghodss Prometheus initially only had JSON and protobuf exposition formats. JSON was a crappy compromise in many ways, so we ended up only supporting the new text-based format and the protobuf one (as opposites of each other in terms of ease of construction and robustness + efficiency).

I do agree that having the option to export Prometheus metrics as JSON directly from the process that generates them would be convenient for users though.

@beorn7, what was the status of making this kind of thing possible via custom output bridges again?

[beorn7]

I don't know about the status of bridges. client_golang/prometheus is already quite big and has a huge backlog of cleanup issues. We really can't put the burden in it right now to support more than the two output protocols we committed to. Once the code is cleaned up and better structured, we might think about some way to plug in bridges.

[matthiasr]

Allowing to get the values out of a metric (cf. #58) would at least allow building the json manually, right?

[beorn7]

@matthiasr That's the plan. After the clean-up, the registry will be independent from exposition. It will simply spit out the canonical representation of Prometheus metrics (which is a slice of MetricFamily protobufs). The http exposition as we have it now will be separate then, encoding the collection of protobufs either into delimited protobufs or into text format, depending on HTTP content type. But the registry interface will be public, so anybody can write their own code, taking the protobuf, doing whatever they desire, e.g. generating JSON from it, and then serve it in any way they see fit.

So yeah, I guess we are already on the right way. Even if we will never support JSON inside client_golang, it will be easy to add support via a 3rd party library.

[ghodss]

So just for my understanding, if I use the io_prometheus_client.MetricFamily struct (and all its descendants) to convert the values to another format, similar to prom2json, that interface should be stable, right? Or will it be changing in the aforementioned cleanup?

[juliusv]

That should be stable. The cleanup would just be a code refactoring that
will allow people to build their own output formatters besides the two
existing ones.
On May 13, 2015 00:43, "Sam Ghods" notifications@github.com wrote:

So just for my understanding, if I use the
io_prometheus_client.MetricFamily struct (and all its descendants) to
convert the values to another format, similar to prom2json, that interface
should be stable, right? Or will it be changing in the aforementioned
cleanup?

—
Reply to this email directly or view it on GitHub
#120 (comment)
.

[beorn7]

The protobuf format as defined in https://github.com/prometheus/client_model/blob/master/metrics.proto is supposed to be the central, canonical data exchange format as used internally by the server and the Go client library. We don't intend to change that fact, and we will change the proto only if needed (and that will mostly be to add new metric types, so it should be backwards compatible as per the protobuf design).

[beorn7]

Closing as there is nothing concretely to be done about this. (A general clean-up of client_golang/prometheus is being worked on already.)