From 08f6a43619688ddb6003170f2108ccc8ecbc9fe2 Mon Sep 17 00:00:00 2001 From: Chris Marchbanks Date: Tue, 9 Jul 2019 10:33:59 -0600 Subject: [PATCH] Add documentation for the WAL compression flag Signed-off-by: Chris Marchbanks --- docs/storage.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/storage.md b/docs/storage.md index 3adf59185..243b46c20 100644 --- a/docs/storage.md +++ b/docs/storage.md @@ -56,6 +56,7 @@ Prometheus has several flags that allow configuring the local storage. The most * `--storage.tsdb.retention.time`: This determines when to remove old data. Defaults to `15d`. Overrides `storage.tsdb.retention` if this flag is set to anything other than default. * `--storage.tsdb.retention.size`: [EXPERIMENTAL] This determines the maximum number of bytes that storage blocks can use (note that this does not include the WAL size, which can be substantial). The oldest data will be removed first. Defaults to `0` or disabled. This flag is experimental and can be changed in future releases. Units supported: KB, MB, GB, PB. Ex: "512MB" * `--storage.tsdb.retention`: This flag has been deprecated in favour of `storage.tsdb.retention.time`. +* `--storage.tsdb.wal-compression`: This flag enables compression of the write-ahead log (WAL). Depending on your data, you can expect the WAL size to be halved with little extra cpu load. Note that if you enable this flag and subsequently downgrade Prometheus to a version below 2.11.0 you will need to delete your WAL as it will be unreadable. On average, Prometheus uses only around 1-2 bytes per sample. Thus, to plan the capacity of a Prometheus server, you can use the rough formula: