This release adds support for TimescaleDB 2.0 multinode. This means all of TimescaleDB 2.0 features are now fully supported. This also means that Promscale now supports horizontal scalability across the entire stack!
This release also includes performance improvements and bug fixes.
At a high-level, this release:
- Adds support for Multinode TimescaleDB.
- Improved promQL query latency by 4x in some cases.
- Reduced I/O used by the PostgreSQL stats collector substantially by changing autovacuum settings.
- Fixed metrics produced by Promscale itself
- PromQL engine supports @ modifier which is disabled by default. (see promql-evaluation-flags)
- Added configuration for query timeout and default step interval
- Improved UX
Notes for people upgrading from 0.1.4 and before
- The CLI and ENV option install-timescaledb was renamed to install-extension
- Two new flags are added upgrade-extensions by default set to true will upgrade extensions if newer versions are available and upgrade-prerelease-extensions by default set to false enabling it will upgrade extensions to pre-prelease versions if pre-release versions are available.
- We have changed the namespace of the metrics Promscale itself exposes from ts_prom to promscale. We have also updated the PromQL engine based metrics to have namespace as promscale instead of prometheus. So, metrics like prometheus_engine_query_duration_seconds will now be promscale_engine_query_duration_seconds.
Prom-Migrator
- Adds support for concurrent pulling and pushing to improve migration throughput. (Please note concurrent push is disabled by default as we've seen some issues migrating data to Thanos concurrently, which we are still working out).
This release contains official support for TimescaleDB 2.0 (single-node) as well as various bug fixes and code cleanup.
Please note that multinode support is still in alpha and automatic upgrades of multinode deployments to future versions is not yet guaranteed (we hope to support this starting with the next release). Please only use multimode deployments for testing only.
Notes for people upgrading from 0.1.3:
- The dropChunk property in the Promscale Helm chart is renamed to maintenance. The drop-chunks CRON job is now renamed to maintenance, you will need to replace the dropChunk.schedule value with maintenance.schedule.
Notes for multinode deployments
- This should only be used for testing, not production deployments
- In particular, we are not guaranteeing upgrades from 0.1.4 to future versions in multinode deployments.
- All nodes have to be added to the cluster before starting Promscale; adding nodes afterwards is not yet supported.
Apparently the handling of `buildFlagsArray` in `buildGo*` is blatantly
broken since it doesn't quote flags specified as list elements properly.
Because of that, the `-ldflags` are not interpreted properly and
`prometheus --version` doesn't output anything useful. By specifying
flags in both `buildFlags` and `buildFlagsArray` the issue gets fixed
since both variables are passed to `go install`.
Changelog:
- Add QueryRow to our connection interface
- Add SQL API for managing metric compression setting
- Add code documentation for query/read path of the connector
- Adds support for checking pg version on startup
- BUGFIX reset pendingBuffer epoch when we're done
- Epoch-Based cache validation
- First pass documenting the write path
- Fix bug with deletion of metric name labels.
- Fix erroneous PromQL query in end-to-end tests
- Fix error reporting to prevent panic
- Fix golden file tests
- Fix logging output to match rest of the project
- Fix views on Vanilla PG and add tests
- Make example docker-compose clearer (#305)
- Mask password while printing config
- Prepare for the 0.1.1 release
- Prepare for the next development cycle
- REFACTOR rearrange mocks
- REFACTOR switch TestPGXInserterInsertData to the new mock
- REFACTOR switch TestPGXInserterInsertSeries to the new mock
- Start a pgmodel Readme
Source: https://github.com/timescale/promscale/releases/tag/0.1.1
* treewide Drop unneeded go 1.12 overrides
* Fix packr to be go module compatible.
I updated to version 2.8.0 which is the latest on master.
Then due to the 2 different sets of go modules which are used, I split
the build into two different derivations, then merged them togethor
using symlinkJoin to have the same output structure as the existing derivation.
* Remove consul dependency on go1.12
I updated the consul version to 1.7.2 and flipped it to building using
modules.
* Remove go1.12 from perkeep.
Update the version to the latest unstable on master.
* Update scaleway-cli to not be pinned to go1.12
Switched the version to 1.20
* Update prometheus-varnish-exporter to not depend on go1.12
* Update lnd to build with go1.12
Updated the version
Forced only building subpackages with main to prevent panics over
multiple modules in one repo
* Remove go1.12 from openshift
Had to update the version to 4.1.0 and do a bit of munging to get this
to work
* Remove go1.12 completely.
These are no longer needed.
* Update bazel-watcher and make it build with go 1.14
* prometheus-nginx-exporter: 0.5.0 -> 0.6.0
* nixos/prometheus-nginx-exporter: update for 0.6.0
Added new option constLabels and updated virtualHost name in the
exporter's test.
Changes the default fetcher in the Rust Platform to be the newer
`fetchCargoTarball`, and changes every application using the current default to
instead opt out.
This commit does not change any hashes or cause any rebuilds. Once integrated,
we will start deleting the opt-outs and recomputing hashes.
See #79975 for details.
v2.14 introduced a new experimental React UI and changed how web assets
are bundled with Prometheus. A separate pre-build command is required to
generate an asset bundle that gets statically linked into the Prometheus
binary.
https://github.com/MindFlavor/prometheus_wireguard_exporter/releases/tag/3.2.0
Previously, the exporter used `wg show all dump` by default to retrieve
information about wireguard peers. If a wireguard config is set, the interface is
now extracted automatically and the exporter runs `wg show <interface> dump`[1].
The cargo hash didn't change as no dependency updates were done in this
release.
[1] 4e332cb73f
