commit
1cafe34db7
|
@ -0,0 +1,30 @@
|
||||||
|
<!--
|
||||||
|
|
||||||
|
For bug reports, please provide the version or the Git commit hash for
|
||||||
|
which you have observed the behavior in question.
|
||||||
|
|
||||||
|
Note that we use GitHub issues for bugs and (uncontroversial) feature
|
||||||
|
requests (see below for details).
|
||||||
|
|
||||||
|
Please do *NOT* ask usage questions in GitHub issues. Usage questions make
|
||||||
|
most sense on the users mailing list, where more people are available to
|
||||||
|
potentially respond to your question, and the whole community can benefit
|
||||||
|
from the answers provided (perhaps your question has already been answered,
|
||||||
|
search the archive to find out):
|
||||||
|
https://groups.google.com/forum/#!forum/prometheus-users
|
||||||
|
|
||||||
|
While a GitHub issue is fine to track progress on an uncontroversial
|
||||||
|
feature request, many feature requests touch the best practices and
|
||||||
|
concepts of Prometheus as a whole and need to be discussed with the wider
|
||||||
|
developer community first. This is in particular true for a request to
|
||||||
|
reconsider a prior rejection of a feature request. Those overarching
|
||||||
|
discussions happen on the developer mailing list (GitHub issues, in
|
||||||
|
particular closed ones, are not tracked by the wider developer community
|
||||||
|
and thus inadequate):
|
||||||
|
https://groups.google.com/forum/#!forum/prometheus-developers
|
||||||
|
|
||||||
|
You can find more information at: https://prometheus.io/community/
|
||||||
|
|
||||||
|
-->
|
||||||
|
|
||||||
|
|
52
CHANGELOG.md
52
CHANGELOG.md
|
@ -1,3 +1,55 @@
|
||||||
|
## 0.9.0 / 2018-10-15
|
||||||
|
* [CHANGE] Go1.6 is no longer supported.
|
||||||
|
* [CHANGE] More refinements of the `Registry` consistency checks: Duplicated
|
||||||
|
labels are now detected, but inconsistent label dimensions are now allowed.
|
||||||
|
Collisions with the “magic” metric and label names in Summaries and
|
||||||
|
Histograms are detected now. #108 #417 #471
|
||||||
|
* [CHANGE] Changed `ProcessCollector` constructor. #219
|
||||||
|
* [CHANGE] Changed Go counter `go_memstats_heap_released_bytes_total` to gauge
|
||||||
|
`go_memstats_heap_released_bytes`. #229
|
||||||
|
* [CHANGE] Unexported `LabelPairSorter`. #453
|
||||||
|
* [CHANGE] Removed the `Untyped` metric from direct instrumentation. #340
|
||||||
|
* [CHANGE] Unexported `MetricVec`. #319
|
||||||
|
* [CHANGE] Removed deprecated `Set` method from `Counter` #247
|
||||||
|
* [CHANGE] Removed deprecated `RegisterOrGet` and `MustRegisterOrGet`. #247
|
||||||
|
* [CHANGE] API client: Introduced versioned packages.
|
||||||
|
* [FEATURE] A `Registerer` can be wrapped with prefixes and labels. #357
|
||||||
|
* [FEATURE] “Describe by collect” helper function. #239
|
||||||
|
* [FEATURE] Added package `testutil`. #58
|
||||||
|
* [FEATURE] Timestamp can be explicitly set for const metrics. #187
|
||||||
|
* [FEATURE] “Unchecked” collectors are possible now without cheating. #47
|
||||||
|
* [FEATURE] Pushing to the Pushgateway reworked in package `push` to support
|
||||||
|
many new features. (The old functions are still usable but deprecated.) #372
|
||||||
|
#341
|
||||||
|
* [FEATURE] Configurable connection limit for scrapes. #179
|
||||||
|
* [FEATURE] New HTTP middlewares to instrument `http.Handler` and
|
||||||
|
`http.RoundTripper`. The old middlewares and the pre-instrumented `/metrics`
|
||||||
|
handler are (strongly) deprecated. #316 #57 #101 #224
|
||||||
|
* [FEATURE] “Currying” for metric vectors. #320
|
||||||
|
* [FEATURE] A `Summary` can be created without quantiles. #118
|
||||||
|
* [FEATURE] Added a `Timer` helper type. #231
|
||||||
|
* [FEATURE] Added a Graphite bridge. #197
|
||||||
|
* [FEATURE] Help strings are now optional. #460
|
||||||
|
* [FEATURE] Added `process_virtual_memory_max_bytes` metric. #438 #440
|
||||||
|
* [FEATURE] Added `go_gc_cpu_fraction` and `go_threads` metrics. #281 #277
|
||||||
|
* [FEATURE] Added `promauto` package with auto-registering metrics. #385 #393
|
||||||
|
* [FEATURE] Add `SetToCurrentTime` method to `Gauge`. #259
|
||||||
|
* [FEATURE] API client: Add AlertManager, Status, and Target methods. #402
|
||||||
|
* [FEATURE] API client: Add admin methods. #398
|
||||||
|
* [FEATURE] API client: Support series API. #361
|
||||||
|
* [FEATURE] API client: Support querying label values.
|
||||||
|
* [ENHANCEMENT] Smarter creation of goroutines during scraping. Solves memory
|
||||||
|
usage spikes in certain situations. #369
|
||||||
|
* [ENHANCEMENT] Counters are now faster if dealing with integers only. #367
|
||||||
|
* [ENHANCEMENT] Improved label validation. #274 #335
|
||||||
|
* [BUGFIX] Creating a const metric with an invalid `Desc` returns an error. #460
|
||||||
|
* [BUGFIX] Histogram observations don't race any longer with exposition. #275
|
||||||
|
* [BUGFIX] Fixed goroutine leaks. #236 #472
|
||||||
|
* [BUGFIX] Fixed an error message for exponential histogram buckets. #467
|
||||||
|
* [BUGFIX] Fixed data race writing to the metric map. #401
|
||||||
|
* [BUGFIX] API client: Decode JSON on a 4xx respons but do not on 204
|
||||||
|
responses. #476 #414
|
||||||
|
|
||||||
## 0.8.0 / 2016-08-17
|
## 0.8.0 / 2016-08-17
|
||||||
* [CHANGE] Registry is doing more consistency checks. This might break
|
* [CHANGE] Registry is doing more consistency checks. This might break
|
||||||
existing setups that used to export inconsistent metrics.
|
existing setups that used to export inconsistent metrics.
|
||||||
|
|
|
@ -1,8 +0,0 @@
|
||||||
<!--
|
|
||||||
|
|
||||||
If you are unhappy how your favorite Go dependency management tool deals
|
|
||||||
with this repository, please do not file an issue but read
|
|
||||||
https://github.com/prometheus/client_golang#important-note-about-releases-versioning-tagging-stability-and-your-favorite-go-dependency-management-tool
|
|
||||||
instead. Thank you very much.
|
|
||||||
|
|
||||||
-->
|
|
70
README.md
70
README.md
|
@ -11,7 +11,7 @@ Prometheus HTTP API.
|
||||||
|
|
||||||
__This library requires Go1.7 or later.__
|
__This library requires Go1.7 or later.__
|
||||||
|
|
||||||
## Important note about releases, versioning, tagging, stability, and your favorite Go dependency management tool
|
## Important note about releases, versioning, tagging, and stability
|
||||||
|
|
||||||
While our goal is to follow [Semantic Versioning](https://semver.org/), this
|
While our goal is to follow [Semantic Versioning](https://semver.org/), this
|
||||||
repository is still pre-1.0.0. To quote the
|
repository is still pre-1.0.0. To quote the
|
||||||
|
@ -22,38 +22,42 @@ 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.
|
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
|
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
|
state. We occasionally tag versions and track their changes in CHANGELOG.md,
|
||||||
[v0.9.0](https://github.com/prometheus/client_golang/milestone/1). After that,
|
but this happens mostly to keep dependency management tools happy and to give
|
||||||
a number of ”hard” breaking changes are planned, see the
|
people a handle they can talk about easily. In particular, all commits in the
|
||||||
[v0.10.0 milestone](https://github.com/prometheus/client_golang/milestone/2),
|
master branch have passed the same testing and reviewing. There is no QA
|
||||||
which should get the library much closer to 1.0.0 state.
|
process in place that would render tagged commits more stable or better tested
|
||||||
|
than others.
|
||||||
|
|
||||||
Dependency management in Go projects is still in flux, and there are many tools
|
There is a plan behind the current (pre-1.0.0) versioning, though:
|
||||||
floating around. While [dep](https://golang.github.io/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
|
- v0.9 is the “production release”, currently tracked in the master
|
||||||
release. If your dependency management tool expects strict post-1.0.0 semver
|
branch. “Patch” releases will usually be just bug fixes, indeed, but
|
||||||
semantics, you have to wait. Sorry.
|
important new features that do not require invasive code changes might also
|
||||||
- If you want absolute certainty, please lock to a specific commit. You can
|
be included in those. We do not plan any breaking changes from one v0.9.x
|
||||||
also lock to tags, but please don't ask for more tagging. This would suggest
|
release to any later v0.9.y release, but nothing is guaranteed. Since the
|
||||||
some release or stability testing procedure that simply is not in place. As
|
master branch will eventually be switched over to track the upcoming v0.10
|
||||||
said above, we are aiming for stability of the tip of master, but if we
|
(see below), we recommend to tell your dependency management tool of choice
|
||||||
tagged every single commit, locking to tags would be the same as locking to
|
to use the latest v0.9.x release, at least for your production software. In
|
||||||
commits.
|
that way, you should get bug fixes and non-invasive, low-risk new features
|
||||||
- If you want to get the newer features and improvements and are willing to
|
without the need to change anything on your part.
|
||||||
take the minor risk of newly introduced bugs and “mild” breakage, just always
|
- v0.10 is a planned release that will have a _lot_ of breaking changes
|
||||||
update to the tip of master (which is essentially the original idea of Go
|
(despite being only a “minor” release in the Semantic Versioning terminology,
|
||||||
dependency management). We recommend to not use features marked as
|
but as said, pre-1.0.0 means nothing is guaranteed). Essentially, we have
|
||||||
_deprecated_ in this case.
|
been piling up feature requests that require breaking changes for a while,
|
||||||
- Once [v0.9.0](https://github.com/prometheus/client_golang/milestone/1) is
|
and they are all collected in the
|
||||||
out, you could lock to v0.9.x to get bugfixes (and perhaps minor new
|
[v0.10 milestone](https://github.com/prometheus/client_golang/milestone/2).
|
||||||
features) while avoiding the “hard” breakage that will come with post-0.9
|
Since there will be so many breaking changes, the development for v0.10 is
|
||||||
features.
|
currently not happening in the master branch, but in the
|
||||||
|
[dev-0.10 branch](https://github.com/prometheus/client_golang/tree/dev-0.10).
|
||||||
|
It will violently change for a while, and it will definitely be in a
|
||||||
|
non-working state now and then. It should only be used for sneak-peaks and
|
||||||
|
discussions of the new features and designs.
|
||||||
|
- Once v0.10 is ready for real-life use, it will be merged into the master
|
||||||
|
branch (which is the reason why you should lock your dependency management
|
||||||
|
tool to v0.9.x and only migrate to v0.10 when both you and v0.10 are ready
|
||||||
|
for it). In the ideal case, v0.10 will be the basis for the future v1.0
|
||||||
|
release, but we cannot provide an ETA at this time.
|
||||||
|
|
||||||
## Instrumenting applications
|
## Instrumenting applications
|
||||||
|
|
||||||
|
@ -62,8 +66,8 @@ recommended course of action with dependency management tools is the following:
|
||||||
The
|
The
|
||||||
[`prometheus` directory](https://github.com/prometheus/client_golang/tree/master/prometheus)
|
[`prometheus` directory](https://github.com/prometheus/client_golang/tree/master/prometheus)
|
||||||
contains the instrumentation library. See the
|
contains the instrumentation library. See the
|
||||||
[best practices section](http://prometheus.io/docs/practices/naming/) of the
|
[guide](https://prometheus.io/docs/guides/go-application/) on the Prometheus
|
||||||
Prometheus documentation to learn more about instrumenting applications.
|
website to learn more about instrumenting applications.
|
||||||
|
|
||||||
The
|
The
|
||||||
[`examples` directory](https://github.com/prometheus/client_golang/tree/master/examples)
|
[`examples` directory](https://github.com/prometheus/client_golang/tree/master/examples)
|
||||||
|
|
Loading…
Reference in New Issue