Add non-goals

[beorn7]

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:

• Rule templating language.
• Strings as sample values (and neither ints...).
• Support event logging / become a log db.

More?

[brian-brazil]

• Supporting JSON as a scrape format
• Long term storage in prometheus (hopefully)
• Per-host aggregators
• SSL and auth for our http frontends (use a reverse proxy)

[brian-brazil]

• Retention policies/rollups (use remote storage for that)

[juliusv]

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.

[brian-brazil]

• Configurable logging (use a pipe)

[brian-brazil]

• A single exporter per machines/service reporting in node exporter

[brian-brazil]

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.

[RichiH]

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.

[fabxc]

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.

[RichiH]

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.

[beorn7]

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.

[brian-brazil]

• Non-HTTP scraping

[brian-brazil]

• Metrics expiry/timeout in pushgateway

[brian-brazil]

• Configuration being provided any way other than files on disk

[juliusv]

• Anomaly detection (besides manually defined rules)

[beorn7]

"Anomaly detection" is a very general term. How about "Machine learning, data mining, business intelligence"?

[brian-brazil]

• For client libraries: non-blocking APIs for the pushgateway

[brian-brazil]

• Anything to do with timezones (but local time as reported by your browser may be used in places)

[brian-brazil]

• Anything that tracks/manages human responses to alerts (Use pagerduty&friends)

[brian-brazil]

• Adding math to Prometheus console/alert templates (put it in the expression)

[brian-brazil]

• Alertmanager permitting every single alert/resolution being turned into a notification (use alert stream from Prometheus directly)

[brian-brazil]

• Non-standard and/or vendor specific authentication mechanisms for scraping

[zgfh]

TLS and authentication in HTTP serving endpoints should delete from roadmap docs (https://prometheus.io/docs/introduction/roadmap/)?

[beorn7]

It's the other way round. The roadmap is more up to date than this.