Commit Graph

57 Commits

Author SHA1 Message Date
Julius Volz 765fdaf37e Update protobuf library package name.
The Golang protocol buffer library has now moved to GitHub:

https://github.com/golang/protobuf

Although "go get"-ing the old package name still works, moving
everything to the new one will make vendoring cleaner.

See also https://github.com/matttproud/golang_protobuf_extensions/pull/7
2015-02-14 00:00:34 +01:00
Bjoern Rabenstein d7f8eb1083 Change "Prometheus Team" to "The Prometheus Authors". 2015-02-02 15:14:36 +01:00
Bjoern Rabenstein 15c9ded5a3 Fix the summary decay by avoiding the Merge method.
This makes the Observe method of summaries more expensive. :-(
2015-01-21 13:44:43 +01:00
Bjoern Rabenstein 6b9530d72e Update vendoring of perks to newest (fixed) version.
Adjust the API and usage accordingly.
Make tests stricter.

Since the merging is still faulty, test are broken now.
The next commit will fix it by avoiding merging.
2015-01-20 18:27:10 +01:00
Bjoern Rabenstein 159e96f6c7 Allow error reporting during metrics collection and simplify Register().
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.
2015-01-12 19:16:09 +01:00
Bjoern Rabenstein 010dc1af88 Vendorize perks/quantile.
Change-Id: I2b24bddf5a975a46ceb598db328c317982154466
2014-06-23 19:48:50 +02:00
Bjoern Rabenstein 5d40912fd2 Complete rewrite of the exposition library.
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
2014-06-17 14:08:22 +02:00