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).
continuation of #109595
pkgconfig was aliased in 2018, however, it remained in
all-packages.nix due to its wide usage. This cleans
up the remaining references to pkgs.pkgsconfig and
moves the entry to aliases.nix.
python3Packages.pkgconfig remained unchanged because
it's the canonical name of the upstream package
on pypi.
This package[1] is a replacement for the old phantomjs-integration[2]
which is practically EOL. It is basically used to render PNGs of panels
that triggered an alert in Grafana.
This package internally uses `puppeteer`[3] to control a headless
Chromium instance. Even though puppeteer recommends to use a fixed
revision of `chromium`, I checked that our default `pkgs.chromium` works
fine as well. Also, I don't think it's a good idea to use outdated
browser versions[4].
I used the latest revision from `master` on purpose since compiling the
code with `tsc` from `v2.0` didn't work and I couldn't figure out why.
[1] https://grafana.com/grafana/plugins/grafana-image-renderer
[2] https://grafana.com/blog/2020/05/07/grafana-7.0-preview-new-image-renderer-plugin-to-replace-phantomjs/
[3] https://github.com/puppeteer/puppeteer
[4] currently, puppeteer v2.0.0 is used which recommends revision 706915
(v79.0.3945.130).
This contains the base infrastructure (including a basic update script)
for maintaining Grafana plugins inside Nix, which, in a subsequent
commit, will be used for allowing the NixOS Grafana module to
automatically install plugins.
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`.
