Cortex Metrics
By Cortex Metrics contributors (CNCF)
Cortex Metrics is an open-source, horizontally scalable system that provides long-term storage for Prometheus metrics, letting organizations retain and query monitoring data far beyond what a single Prometheus server can hold on local…
Definition
Cortex Metrics is an open-source, horizontally scalable system that provides long-term storage for Prometheus metrics, letting organizations retain and query monitoring data far beyond what a single Prometheus server can hold on local disk. It runs as a set of independently scalable microservices that ingest samples via the Prometheus remote-write protocol and persist them to durable object storage. Cortex presents a multi-tenant, horizontally scalable Prometheus-compatible backend rather than a replacement for Prometheus itself, which continues to handle local scraping and alerting rules.
Overview
Prometheus servers are intentionally simple and store data locally, which means retention is bounded by disk capacity and a single server cannot easily serve queries across many teams or clusters at once. Cortex Metrics was created to remove that ceiling by decoupling ingestion, storage, and querying into separate services that can each scale independently, while remaining compatible with the PromQL query language and remote-write protocol that Prometheus users already know. Mechanically, Cortex splits its workload across components: distributors receive incoming samples and shard them across ingesters, ingesters buffer recent data in memory before flushing it to long-term storage, and queriers reconstruct results from both recent in-memory data and historical chunks pulled from object storage such as S3 or GCS. A compactor periodically merges and deduplicates blocks to keep storage efficient, and an index layer tracks which time series live in which blocks so queries do not need to scan the entire dataset. Multi-tenancy is built in, with each tenant's series isolated by a tenant identifier attached to every request. Cortex sits alongside other Prometheus long-term storage backends such as Thanos and Mimir, all of which solve a similar problem with different architectural choices; Cortex was in fact the original project from which Grafana Mimir was later forked, and it shares conceptual DNA with Thanos's sidecar-based approach while differing in deployment topology. Compared to a general column store retrofitted for metrics, Cortex's design is purpose-built around Prometheus's data model and query semantics from the outset. In practice, organizations run Cortex as a central metrics backend for many Prometheus instances across teams, clusters, or regions, giving every team long-term retention and centralized dashboards without operating their own storage infrastructure. Remote-write configuration in each Prometheus server forwards samples to Cortex, and Grafana or other PromQL-compatible tools query it directly for both recent and historical data. The operational cost of this capability is real: a full Cortex deployment involves many interacting microservices, each requiring its own scaling, monitoring, and upgrade path, which is considerably more complex than running a single Prometheus binary. Smaller organizations without multi-team or multi-cluster monitoring needs may find the complexity outweighs the benefit, and many teams now default to Grafana Mimir, Cortex's more actively maintained successor, for new deployments rather than Cortex itself. Upgrading between Cortex versions or migrating an existing deployment to Mimir also requires careful planning, since schema and configuration details differ enough between the two projects that a naive swap can disrupt ingestion or break existing dashboards and alert rules until the migration is fully validated in a staging environment first.
Key Features
- Horizontally scalable, multi-tenant long-term storage for Prometheus metrics
- Ingests data via the standard Prometheus remote-write protocol
- Splits ingestion, storage, and querying into independently scalable services
- Persists historical data to object storage like S3 or GCS
- Compactor merges and deduplicates blocks to control storage growth
- Fully compatible with PromQL for querying recent and historical data
- Built-in tenant isolation for shared, multi-team deployments
Use Cases
Alternatives
Frequently Asked Questions
From the Blog
How to Evaluate LLMs: Benchmarks and Metrics
Evaluating a language model means measuring how well it does the job you need, using benchmarks, task-specific metrics, and human or model-based judgment together.
Read More Data ScienceKPIs and Metrics Every Analyst Should Understand
Master the KPIs and metrics every analyst should understand: north-star metrics, vanity versus actionable metrics, and how to design metrics that actually drive decisions.
Read More AI & Technology8 Metrics for Evaluating RAG and Agent Systems
No single metric tells you whether a RAG or agent system works, because retrieval, grounding, task completion and cost fail independently. These eight metrics cover the distinct failure modes, what each one catches that the others miss, and how to compute each on your own data.
Read More Projects & Case StudiesProject: Build a Data Dashboard with Python and Streamlit
Streamlit turns a Python script into an interactive web app in minutes — no frontend knowledge required. In this project you'll build a live sales dashboard with filters, KPI metrics, and Plotly charts from a CSV dataset, then share it online for free.
Read More