---
title: Roadmap
sort_rank: 6
---

# Roadmap

The following is only a selection of some of the major features we plan to
implement in the near future. To get a more complete overview of planned
features and current work, see the issue trackers for the various repositories,
for example, the [Prometheus
server](https://github.com/prometheus/prometheus/issues).

**Hierarchical federation**

Hierarchical federation will allow higher-level Prometheus servers to collect
aggregated time series data from subordinated servers. This will enable more
scalable monitoring topologies. For example, a setup might consist of
per-datacenter Prometheus servers that collect data in high detail, and a set
of global Prometheus servers which collect and store only aggregated data from
those local servers. This allows you to have an aggregate global view and
detailed local views.

GitHub issue: [#480](https://github.com/prometheus/prometheus/issues/480)

**Aggregatable histograms**

The current client-side [summary
types](http://localhost:3000/docs/concepts/metric_types/#summaries) do not
support aggregation of quantiles. For example, it is [statistically
incorrect](http://latencytipoftheday.blogspot.de/2014/06/latencytipoftheday-you-cant-average.html)
to average over the 90th percentile latency of multiple monitored instances.
We plan to implement server-side histograms which will allow for this use case.

GitHub issue: [#9](https://github.com/prometheus/prometheus/issues/9)

**More flexible label matching in binary operations**

[Binary operations](/docs/querying/operators/) between time series vectors
currently require exact matches of label sets on both sides of the operation
in order for paired vector elements to propagate into the result. We plan to
add more flexible label-matching features to support advanced query use cases.
This applies to 1-to-1 element matches as well as for 1-to-n matches.

GitHub issues: [#488](https://github.com/prometheus/prometheus/issues/488) and [#393](https://github.com/prometheus/prometheus/issues/393)

**Support for more types of service discovery**

Currently Prometheus supports configuring static HTTP targets, as well as
discovering targets dynamically via [DNS SRV
records](http://en.wikipedia.org/wiki/SRV_record). We plan to support more
types of service discovery (e.g. Consul or Zookeeper) in the future. Some will
be implemented natively, but we may also add a plugin system for arbitrary
discovery mechanisms.

**Restartless configuration changes**

Currently Prometheus requires a restart after any configuration or rule file
change. This can mean monitoring interruptions for short periods of time. In
the future, we want to support reloading configuration changes without having
to restart Prometheus.

GitHub issue: [#108](https://github.com/prometheus/prometheus/issues/108)

**Long-term storage**

Currently Prometheus has support for storing samples on local disk, as well as
experimental support for writing data into OpenTSDB. We plan to improve
long-term storage support, although the details are not determined yet. This
might include read-back support from OpenTSDB in Prometheus, or support for
other long-term storage backends.

GitHub issue: [#10](https://github.com/prometheus/prometheus/issues/10)

**Server-side metric metadata support**

At this time, metric types and other metadata are only used in the client
libaries and in the exposition format, but not persisted or utilized in the
Prometheus server. We plan on making use of this metadata in the future. For
example, we could suggest automatic rates over counters, warn users if they
take the rate of a gauge, or display metric documentation strings. The details
of this are still to be determined.
