It also includes an update of RELEASE.md since this version simplifies a
bit the release process: promu will take care of drafting the GitHub
release.
Signed-off-by: Simon Pasquier <spasquie@redhat.com>
With v0.16.0 Alertmanager introduced a new API (v2). This patch adds a
configuration option for Prometheus to send alerts to the v2 endpoint
instead of the defautl v1 endpoint.
Signed-off-by: Max Leonard Inden <IndenML@gmail.com>
* web: add prometheus_http_requests_total metrics
Signed-off-by: Simon Pasquier <spasquie@redhat.com>
* Add unit test for requestCounter metric
Signed-off-by: Simon Pasquier <spasquie@redhat.com>
Lots of alerts are based on ratios (eg. disk usage), and humans are used
to values in percentage in textual descriptions.
Signed-off-by: Jens Erat <email@jenserat.de>
The version on goreleaser is broken and different from the one in
Github: golangci/golangci-lint#575 – use the direct Github URL as a
workaround.
Additionally, the installer script attempts to `install -d /go/bin` on
CircleCI, which doesn't work due to permissions. Patch that line out –
we don't need it because we make sure the directory exists anyway.
Signed-off-by: Matthias Rampke <mr@soundcloud.com>
With the next release of client_golang, Summaries will not have
objectives by default. To not lose the objectives we have right now,
explicitly state the current default objectives.
Signed-off-by: beorn7 <beorn@grafana.com>
For my benchmarks on aggregation this reduces allocations by ~5% (~10%
time improvement):
```
benchmark old ns/op new ns/op delta
BenchmarkEvaluations/benchdata/aggregators.test/promxy-4 727692 649626 -10.73%
benchmark old allocs new allocs delta
BenchmarkEvaluations/benchdata/aggregators.test/promxy-4 2566 2434 -5.14%
benchmark old bytes new bytes delta
BenchmarkEvaluations/benchdata/aggregators.test/promxy-4 162760 148854 -8.54%
```
Signed-off-by: Thomas Jackson <jacksontj.89@gmail.com>
This codifies how 2.10 was released. It removes the inconsistency of
freezing master for pre-releases but handling post-release bug fixes
in a separate branch.
The previous instructions came from a time where master was often in
bad shape. However, that's a problem of its own, which should be
avoided at all times and not only when a release is imminent. On other
words, freezing master can still happen if it is in bad shape and we
need a break from feature development and just fix the bugs for a
while. However, it should not happen as a formal step during the
release of a release candidate. On the contrary, a release candidate
is not really a release candidate if we already know it is in such a
bad shape that we need bug fixes. On the other hand, if we truly
believe the RC could be identical to the final release, there is no
need to freeze master.
I can explain more of the concept if there is still a need for
clarification.
Signed-off-by: beorn7 <beorn@grafana.com>
