Summaries as implemented cannot be aggregated in a meaningful
way. Partitoning them by status code and method only made sense if we
were interested in the individual latency and size of e.g. GET request
that result in status 503. In general, that's not the case. Most of
the time, the user will be interested in the latency and size of _all_
HTTP requests.
(With future changes to client_golang, we will consider making the
HTTP instrumentation configurable, e.g. to handle the case where the
user is only interested in the latency of successful requests.)
Both are interface changes I want to get in before public
announcement. They only break rare usage cases, and are always easy to
fix, but still we want to avoid breaking changes after a wider
announcement of the project.
The change of Register() simply removes the return of the Collector,
which nobody was using in practice. It was just bloating the call
syntax. Note that this is different from RegisterOrGet(), which is
used at various occasions where you want to register something that
might or might not be registered already, but if it is, you want the
previously registered Collector back (because that's the relevant
one).
WRT error reporting: I first tried the obvious way of letting the
Collector methods Describe() and Collect() return error. However, I
had to conclude that that bloated _many_ calls and their handling in
very obnoxious ways. On the other hand, the case where you actually
want to report errors during registration or collection is very
rare. Hence, this approach has the wrong trade-off. The approach taken
here might at first appear clunky but is in practice quite handy,
mostly because there is almost no change for the "normal" case of "no
special error handling", but also because it plays well with the way
descriptors and metrics are handled (via channels).
Explaining the approach in more detail:
- During registration / describe: Error handling was actually already
in place (for invalid descriptors, which carry an error anyway). I
only added a convenience function to create an invalid descriptor
with a given error on purpose.
- Metrics are now treated in a similar way. The Write method returns
an error now (the only change in interface). An "invalid metric" is
provided that can be sent via the channel to signal that that metric
could not be collected. It alse transports an error.
NON-GOALS OF THIS COMMIT:
This is NOT yet the major improvement of the whole registry part,
where we want a public Registry interface and plenty of modular
configurations (for error handling, various auto-metrics, http
instrumentation, testing, ...). However, we can do that whole thing
without breaking existing interfaces. For now (which is a significant
issue) any error during collection will either cause a 500 HTTP
response or a panic (depending on registry config). Later, we
definitely want to have a possibility to skip (and only report
somehow) non-collectible metrics instead of aborting the whole scrape.
I intentionally left out the Makefile infrastructure that we had
previously for this, as it's not strictly needed and adds
complexity/maintenance burden.
This change adds two new collectors to the prometheus package which
export metrics about a given or the current process.
* ProcessCollector exports metrics about cpu time, vss, rss, fd usage as
well as the start time of a given process.
* GoCollector exports currently only the number of active goroutines.
This is still from my own fork as there are still critical PRs that
bmizerany hasn't responded to yet.
Change-Id: Ib46e68ec9ecbae9423b1bfe1311569426dfc7ba0
- Change Fingerprints to be simple uint64s.
- Deal sensibly with missing metric names.
- Enable finer-grained time resolution.
Merge this concurrently with the merge of the new storage backend into
prometheus/prometheus.
Change-Id: Idd82f137aa0c4286df422c53ce3c62e0de285360
computeApproximateRequestSize is run in a goroutine, but the
handlerFunc that runs in parallel may modify the URL, which is also
needed by computeApproximateRequestSize. So get the URL length
beforehand.
Change-Id: Idb84735845afe7be4ef79b3d642d5764f6d26a7c
Also, remove quotes from the Content-type header. It's not illegal to
have quotes there, but they are not needed, and at other places, we
are not using them. So fewer characters and more consistency.
Change-Id: If7a78bde85154163e4426daec493d973213e83e9
Since we prepare the whole content in a buf before sending, we can as
well set the Content-Length explicitly.
Change-Id: Ifd91764c90af53be49f93f0b33032138130b6f96
This is actually the intended behavior, and (as a nice side effect)
makes things cheaper to calculate.
Also, introduce a separator character to avoid hash collisions
(like label values {"ab","c"} vs {"a", "bc"}).
Apply the same principles to signature.go.
Change-Id: I607db544f278ed89684fe5fa11abdbc3e03d3061
Also, fix seconds to microseconds fot the http instrumentation to
match the metric name.
Fix Desc.String().
Simplify http error display.
Change-Id: Ib7397f4eac1eeed92b291e1c9cc88c080aee99ca
This rewrite had may backs and forths. In my git repository, it
consists of 35 commits which I cannot group or merge into reasonable
review buckets. Gerrit breaks fundamental git semantics, so I have to
squash the 35 commits into one for the review.
I'll push this not with refs/for/master, but with refs/for/next so
that we can transition after submission in a controlled fashion.
For the review, I recommend to start with looking at godoc and in
particular the many examples. After that, continue with a line-by-line
detailed review. (The big picture is hopefully as expected after
wrapping up the discussion earlier.)
Change-Id: Ib38cc46493a5139ca29d84020650929d94cac850
Björn Rabenstein