Open beorn7 opened 9 years ago
I personally wouldn't rule out retention policies (deleting certain series completely after a configurable time, not talking about downsampling here). It shouldn't be too hard to add and could be quite useful.
Thinking last night this is probably also the place to list our assumptions about the minimum state of your infrastructure (machine database, service database, configuration management), and that we won't add features solely to workaround the lack of same.
While I strongly disagree with the "no long-term storage" bit, a constraints section which lists design non-goals, anti-patterns, and basic requirements would make sense.
To clarify, the long-term storage part means we do not intend for the storage layer to become one. We do however intend to provide better integrations with existing storage solutions to serve as a LTS for Prometheus data. Compared to what we have now, this especially means read-back support.
Just to make sure: The plan is to put historic data into some other storage engine at a magic cut-off point to maintain performance for near-time metrics while retaining full information for old data?
Sounds good to me :)
As an aside, it might make sense to detect frequently-accessed historical data to keep that in warm storage.
As an aside, it might make sense to detect frequently-accessed historical data to keep that in warm storage.
I was thinking about a simple query cache here. Queries to the LTS backend only have to be repeated if the most recent sample (per timeseries) is now beyond the rentention period of the Prometheus server (or if the query result has been evicted from the cache due to memory constraints).
But note that there a lot of more urgent features to implement before we'll tackle read-back from LTS.
"Anomaly detection" is a very general term. How about "Machine learning, data mining, business intelligence"?
TLS and authentication in HTTP serving endpoints
should delete from roadmap docs (https://prometheus.io/docs/introduction/roadmap/)?
It's the other way round. The roadmap is more up to date than this.
Perhaps next to the road map, add a "non-road-map" with the non-goals, i.e. things that sound like nice features but which we do not intend to implement for reasons to be stated in the new section.
Ideas so far:
More?