The big change is the new storage engine, which is completely rewritten and combined with changes in the retrieval system brings substantial performance gains. Prometheus servers ingesting millions of samples per second is now conceivable. This is due to optimisations tied to the text exposition format. If you are using one of the extremely rare exporters that only supports the protobuf exposition format, you’ll need to add support for the text format. This new storage engine is not backwards compatible, however there’s a way to transparently access your older data that’s still stored in 1.x.
The new storage engine requires no tuning via flags. It works via mmaped files and thus relies on the page caches of modern kernels. This design also permits snapshots to be taken, for those that wish to make backups.
The second biggest change is the new staleness semantics in PromQL. No longer in common cases will you have to wait a full 5 minutes for a time series to go stale after it is removed from service discovery, now it takes around one scrape interval.
The rules file format has changed to YAML, we’ve previously looked at how to convert it using promtool. Rules are now organised in groups, which are executed sequentially.
There’s been some minor changes to PromQL. A
timestamp function was added, while
keep_common were removed.
For security reasons the admin and lifecycle APIs are now disabled by default. You can reenable them with the
--web.enable-lifecycle flags. Speaking of flags, Kingpin is now in use so all flags are prefixed with double rather than single hyphens. The command line flags for specifying the Alertmanager have been removed, the config file options added back in 1.4 are now the only way to specify the Alertmanagers to use.
If you’re using remote read with something that is not a remote storage, you’ll want to enable the new
read_recent option. By default remote read no longer requests data that it should already have locally.
Wondering when and how to upgrade to Prometheus 2.0? Contact us.