From 924e8ec7a4f6a596bc8ce55b032b962a73163d54 Mon Sep 17 00:00:00 2001 From: Dieter Plaetinck Date: Fri, 3 Feb 2017 16:35:32 +0100 Subject: [PATCH 1/2] clarify. chunk-cache is also in memory --- metrictank-sample.ini | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/metrictank-sample.ini b/metrictank-sample.ini index b70cf8360c..4d159a5a4c 100644 --- a/metrictank-sample.ini +++ b/metrictank-sample.ini @@ -25,7 +25,7 @@ ttl = 35d # max age for a chunk before to be considered stale and to be persisted to Cassandra chunk-max-stale = 1h -# max age for a metric before to be considered stale and to be purged from memory +# max age for a metric before to be considered stale and to be purged from in-memory ring buffer. metric-max-stale = 6h # Interval to run garbage collection job gc-interval = 1h From 833847e6848685610a34dc78f592824e8be4b441 Mon Sep 17 00:00:00 2001 From: Dieter Plaetinck Date: Fri, 3 Feb 2017 16:36:05 +0100 Subject: [PATCH 2/2] add FAQ --- README.md | 1 + docs/faq.md | 27 +++++++++++++++++++++++++++ 2 files changed, 28 insertions(+) create mode 100644 docs/faq.md diff --git a/README.md b/README.md index 82223ae806..4110fced68 100644 --- a/README.md +++ b/README.md @@ -79,6 +79,7 @@ So we can do consolidation (combined runtime+archived) accurately and correctly, * [Development](https://github.com/raintank/metrictank/blob/master/docs/development.md) * [Community](https://github.com/raintank/metrictank/blob/master/docs/community.md) * [Roadmap](https://github.com/raintank/metrictank/blob/master/docs/roadmap.md) +* [Faq](https://github.com/raintank/metrictank/blob/master/docs/faq.md) ## Releases and versioning diff --git a/docs/faq.md b/docs/faq.md new file mode 100644 index 0000000000..000d334841 --- /dev/null +++ b/docs/faq.md @@ -0,0 +1,27 @@ +# Frequently asked questions + +## Does it work well with transient data, e.g. new metrics constantly appearing and other metrics becoming inactive, such as those from docker containers ? + +For any metric, we only store data that is received, as well as an entry into the index. So the overhead of a shortlived metric is low. + +Furthermore, we have optimizations for this use case: + +* Index filtering: when you request data, we exclude items from the result set that have not been updated in 24hours before the "from" of the request (as the data will be all null anyway) +* Index pruning: if enabled, we delete series from the index if no data has been received in "max-stale" time. (but keep data until it expires, in case the same metric gets re-added). This is useful because the query editor does not send a time range. Note that this setting is applied to *all* metrics. +* GC: removes metrics from metrictank's ring buffer if they become stale (see `metric-max-stale`), which means data will most likely come from cassandra or possibly the in-memory chunk-cache, but does not affect the index. + +## What happens when I want to update the resolution / interval of a metric? + +Update the interval tag sent with your data (if using [carbon-relay-ng](https://github.com/graphite-ng/carbon-relay-ng) update your storage-schemas.conf) and send data at the new resolution. +Metrictank will automatically combine the data together like so: +* when a response contains a series for which there is data of multiple resolutions, the higher resolution data will be consolidated down to match the lower resolution. +* when a response contains multiple series of different resolutions, the higher resolution data will be consolidated to the "lowest common denominator" resolution, so the output has a consistent interval. +* when a response contains multiple series of different resolutions, of which at least one series has data of different resolutions, the two mechanisms above work together. +* once a request can be fully satistfied by data with the new resolution, that's the resolution the response will be in. + +## Tag support + +Metrictank aims to provide a proper implementation of [metrics 2.0](http://metrics20.org/) +(it helps that both projects share the same main author) +As such, metrics can have tags and they are indexed as such. However we don't expose this yet through the search or query interface, +but plan to do so in the future.