Project reference ↗

To spot changes in service health, a team needs to collect measurements over time and turn them into useful queries and alerts. Prometheus supplies that metrics system. This entry specifically preserves the former stable/prometheus Helm package, which installed the server and related optional components. Its current community-chart lineage is distinct from the operator-based kube-prometheus-stack. Choose the deployment model first, then preserve the monitoring targets, alert rules and stored history when translating the old chart configuration.

Current guidance

The recovered Project link identifies the archived stable/prometheus package. The current prometheus-community/prometheus chart is a standalone-server deployment with optional Alertmanager, kube-state-metrics, node-exporter and Pushgateway dependencies. It is different from kube-prometheus-stack, which introduces the Prometheus Operator and custom-resource configuration. Decide which deployment model you need before translating values.

Inventory the existing release name, Service selectors, scrape annotations, ConfigMaps, rules and persistent-volume claims. Compare rendered manifests from the exact target chart version, including resource names and dependency enablement. A new release name or changed claim template can attach an empty volume while the previous time-series data remains elsewhere. Do not delete the old claim merely because the new server answers health checks.

Move scrape discovery and alert rules deliberately, then compare discovered targets and metric labels. Avoid accidentally collecting the same exporter through both old and new jobs, and ensure only the intended alerting path sends notifications during the change. Server-major upgrades have their own Prometheus migration requirements. The linked operator guide is relevant only if you choose an operator-based stack; it is not required for a standalone chart update.

Historical upstream link check · 2026-10-09

The recorded upstream address responded successfully (HTTP 200) on 2026-10-09. GitHub confirms that helm/charts is archived: this is a historical chart distribution, not evidence that the application itself is retired. Link availability does not certify the historical installation instructions or current security support.

Source for this check ↗

Website availability is separate from project, chart and image support. Use the current guidance and primary sources on this page to assess the distribution.

The original record

Historical Kubedex content

Preserved for context. Commands, versions, prices and results below reflect the original research.

Prometheus, a Cloud Native Computing Foundation project, is a systems and service monitoring system. It collects metrics from configured targets at given intervals, evaluates rule expressions, displays the results, and can trigger alerts if some condition is observed to be true.

Dimensional data

Prometheus implements a highly dimensional data model. Time series are identified by a metric name and a set of key-value pairs. Prometheus fundamentally stores all data as time series: streams of timestamped values belonging to the same metric and the same set of labeled dimensions. Besides stored time series, Prometheus may generate temporary derived time series as the result of queries.

Powerful queries

A flexible query language allows slicing and dicing of collected time series data in order to generate ad-hoc graphs, tables, and alerts. Prometheus provides a functional expression language that lets the user select and aggregate time series data in real time. The result of an expression can either be shown as a graph, viewed as tabular data in Prometheus’s expression browser, or consumed by external systems via the HTTP API.

Great visualization

Prometheus has multiple modes for visualizing data: a built-in expression browser, Grafana integration, and a console template language.

Efficient storage

Prometheus stores time series in memory and on local disk in an efficient custom format. Scaling is achieved by functional sharding and federation. Prometheus includes a local on-disk time series database, but also optionally integrates with remote storage systems. Prometheus’s local time series database stores time series data in a
custom format on disk.

Simple operation

Each server is independent for reliability, relying only on local storage. Written in Go, all binaries are statically linked and easy to deploy. Prometheus is configured via command-line flags and a configuration file. While the command-line flags configure immutable system parameters (such as storage locations, amount of data to keep on disk and in memory, etc.), the configuration file defines everything related to scraping jobs and their instances, as well as which rule files to load.

Precise alerting

Alerts are defined based on Prometheus’s flexible query language and maintain dimensional information. An alertmanager handles notifications and silencing. Alerting rules allow you to define alert conditions based on Prometheus expression language expressions and to send notifications about firing alerts to an external service.
Whenever the alert expression results in one or more vector elements at a given point in time, the alert counts as active for these elements’ label sets.

Many client libraries

Client libraries allow easy instrumentation of services. Over ten languages are supported already and custom libraries are easy to implement. Before you can monitor your services, you need to add instrumentation to their code via one of the Prometheus client libraries. These implement the Prometheus metric types.

Many integrations

Existing exporters allow bridging of third-party data into Prometheus. Examples: system statistics, as well as Docker, HAProxy, StatsD, and JMX metrics. There are a number of libraries and servers which help in exporting existing metrics from third-party systems as Prometheus metrics. This is useful for cases where it is not feasible to instrument a given system with Prometheus metrics directly (for example, HAProxy or Linux system stats).

Sources & further reading

  1. Current Prometheus chart dependencies and migration notes
  2. Server-major migration guide
  3. Recovered historical source (Common Crawl index)

Spotted something that needs another look?

Help improve this page →