159e96f6c7
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. |
||
|---|---|---|
| _vendor | ||
| examples | ||
| extraction | ||
| model | ||
| prometheus | ||
| text | ||
| .gitignore | ||
| .travis.yml | ||
| LICENSE | ||
| Makefile | ||
| README.md | ||
README.md
Overview
This is the Prometheus Go client library. It provides several distinct functions, and there is separate documentation for each respective component. You will want to select the appropriate topic below to continue your journey:
-
See the exposition library if you want to export metrics to a Prometheus server or pushgateway
-
See the consumption library if you want to process metrics exported by a Prometheus client. (The Prometheus server is using that library.)
Getting Started
- The source code is periodically indexed: Go Exposition Client.
- All of the core developers are accessible via the Prometheus Developers Mailinglist.
Testing
$ go test ./...
Continuous Integration
Contributing
See the contributing guidelines for the Prometheus server.