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>
* move the wal repair logic in db.Open
This is to allow opening a wal in a read oly mode without triggering a
repair.
Signed-off-by: Krasi Georgiev <8903888+krasi-georgiev@users.noreply.github.com>
With the next release of client_golang, Summaries will not have
objectives by default.
As it turns out, for prometheus_tsdb_head_gc_duration_seconds and
prometheus_tsdb_wal_truncate_duration_seconds, the objective-less
default makes more sense then the current default.
To make sure we do the right thing before and after the upcoming
release of client_golang, I have set the objectives explicitly
wherever that was not the case so far:
- prometheus_tsdb_head_gc_duration_seconds and
prometheus_tsdb_wal_truncate_duration_seconds now have no objectives
explicitly.
- prometheus_tsdb_wal_fsync_duration_seconds now explicitly uses the
previous default objectives.
Signed-off-by: beorn7 <beorn@grafana.com>
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>
The WAL repair tests look similar so added some extra comments to
clarify their purpose.
Signed-off-by: Krasi Georgiev <8903888+krasi-georgiev@users.noreply.github.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 reduces disk space usage to not be a minimum of 3 128MB files
in small setups. This will possibly also help debug wal data issues,
by making things a bit more deterministic.
Signed-off-by: Brian Brazil <brian.brazil@robustperception.io>
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>
