mirrors/statsd_exporter
1
0
Fork 1
mirror of https://github.com/prometheus/statsd_exporter.git synced 2025-01-08 21:45:26 +00:00
Code Issues Projects Releases Packages Wiki Activity

Add changelog & readme entries for #281

Browse source 
explain the tradeoffs for the cache strategies based on this comment:

https://github.com/prometheus/statsd_exporter/pull/281#issuecomment-573103251

Signed-off-by: Matthias Rampke <mr@soundcloud.com>
This commit is contained in:
Matthias Rampke 2020-03-05 09:34:47 +00:00
parent 60fbaf5e27
commit 2ad8989cd2
No known key found for this signature in database
GPG key ID: 2CDE413A9BD0A5BC
2 changed files with 4 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
CHANGELOG.md
View file

@ -1,6 +1,7 @@
## 0.15.0 / unreleased
* [ENHANCEMENT] Allow setting granularity for summary metrics ([#290](https://github.com/prometheus/statsd_exporter/pull/290))
* [ENHANCEMENT] Support a random-replacement cache invalidation strategy ([#281](https://github.com/prometheus/statsd_exporter/pull/281)
To facilitate the expanded settings for summaries, the configuration format changes from

5
README.md
View file

@ -431,10 +431,11 @@ There is a cache used to improve the performance of the metric mapping, that can
The cache has a default maximum of 1000 unique statsd metric names -> prometheus metrics mappings that it can store.
This maximum can be adjust using the `statsd.cache-size` flag.
If the maximum is reached, entries are rotated using the [least recently used replacement policy](https://en.wikipedia.org/wiki/Cache_replacement_policies#Least_recently_used_(LRU)).
If the maximum is reached, entries are by default rotated using the [least recently used replacement policy](https://en.wikipedia.org/wiki/Cache_replacement_policies#Least_recently_used_(LRU)). This strategy is optimal when memory is constrained as only the most recent entries are retained.
If you are using this exporter to reduce the cardinality of your data, a high maximum cache size can be a costly use of memory.
Alternatively, you can choose a [random-replacement cache strategy](https://en.wikipedia.org/wiki/Cache_replacement_policies#Random_replacement_(RR)). This is less optimal if the cache is smaller than the cacheable set, but requires less locking. Use this for very high throughput, but make sure to allow for a cache that holds all metrics.
The optimal cache size is determined by the cardinality of the _incoming_ metrics.
### Time series expiration