c06fb788be
Also, clarify in the doc comment. Previously, the assumption was that inconsistent label dimensions are violating the exposition format spec. However, especially with the knowledge that OpenMetrics will explicitly allow inconsistent label dimensions in expositions, we should allow it in client_golang, too. Note that registration with proper Descs provided will still check for consistont label dimensions. However, you can "cheat" with custom Collectors as you can collect metrics that don't follew the provided Desc (this will be made more explicit and less cheaty once #47 is fixed). You can also create expositions with inconsistent label dimensions by merging Gatherers with the Gatherers slice type. (The latter is used in the Pushgateway.) Effectively, normal direct instrumentation will always have consistent label dimensions in this way, but you can cover special use cases with custom collectors or merging of different Gatherers. Signed-off-by: beorn7 <beorn@soundcloud.com> |
||
---|---|---|
api | ||
examples | ||
prometheus | ||
.gitignore | ||
.travis.yml | ||
CHANGELOG.md | ||
CONTRIBUTING.md | ||
ISSUE_TEMPLATE.md | ||
LICENSE | ||
MAINTAINERS.md | ||
NOTICE | ||
README.md | ||
VERSION |
README.md
Prometheus Go client library
This is the Go client library for Prometheus. It has two separate parts, one for instrumenting application code, and one for creating clients that talk to the Prometheus HTTP API.
This library requires Go1.7 or later.
Important note about releases, versioning, tagging, stability, and your favorite Go dependency management tool
While our goal is to follow Semantic Versioning, this repository is still pre-1.0.0. To quote the Semantic Versioning spec: “Anything may change at any time. The public API should not be considered stable.” We know that this is at odds with the widespread use of this library. However, just declaring something 1.0.0 doesn't make it 1.0.0. Instead, we are working towards a 1.0.0 release that actually deserves its major version number.
Having said that, we aim for always keeping the tip of master in a workable state and for only introducing ”mildly” breaking changes up to and including v0.9.0. After that, a number of ”hard” breaking changes are planned, see the v0.10.0 milestone, which should get the library much closer to 1.0.0 state.
Dependency management in Go projects is still in flux, and there are many tools floating around. While dep might develop into the de-facto standard tool, it is still officially experimental. The roadmap for this library has been laid out with a lot of sometimes painful experience in mind. We really cannot adjust it every other month to the needs of the currently most popular or most promising Go dependency management tool. The recommended course of action with dependency management tools is the following:
- Do not expect strict post-1.0.0 semver semantics prior to the 1.0.0 release. If your dependency management tool expects strict post-1.0.0 semver semantics, you have to wait. Sorry.
- If you want absolute certainty, please lock to a specific commit. You can also lock to tags, but please don't ask for more tagging. This would suggest some release or stability testing procedure that simply is not in place. As said above, we are aiming for stability of the tip of master, but if we tagged every single commit, locking to tags would be the same as locking to commits.
- If you want to get the newer features and improvements and are willing to take the minor risk of newly introduced bugs and “mild” breakage, just always update to the tip of master (which is essentially the original idea of Go dependency management). We recommend to not use features marked as deprecated in this case.
- Once v0.9.0 is out, you could lock to v0.9.x to get bugfixes (and perhaps minor new features) while avoiding the “hard” breakage that will come with post-0.9 features.
Instrumenting applications
The
prometheus
directory
contains the instrumentation library. See the
best practices section of the
Prometheus documentation to learn more about instrumenting applications.
The
examples
directory
contains simple examples of instrumented code.
Client for the Prometheus HTTP API
The
api/prometheus
directory
contains the client for the
Prometheus HTTP API. It allows you
to write Go applications that query time series data from a Prometheus
server. It is still in alpha stage.
Where is model
, extraction
, and text
?
The model
packages has been moved to
prometheus/common/model
.
The extraction
and text
packages are now contained in
prometheus/common/expfmt
.
Contributing and community
See the contributing guidelines and the Community section of the homepage.