Managed Prometheus

One line of remote_write, and you’re done.

A Prometheus-compatible endpoint that takes your metrics, keeps them as long as you say, and answers PromQL, so your dashboards, rules and alerts carry over unchanged.

Standard on the way in, standard on the way out.

Your infrastructure

  • Prometheus
  • Prometheus Agent
  • OpenTelemetry Collector
  • Grafana Alloy

No agent of ours deployed here.

remote_write write, push-only

Your ClusterNest cluster

  • POST /api/v1/push
  • GET /prometheus/api/v1/query
  • GET /prometheus/api/v1/query_range

Dedicated bare metal in Europe, kept as long as you say.

PromQL read-only

Your tools

  • Grafana
  • AI agents
  • Ad-hoc PromQL
  • Autoscalers

Yours to choose and yours to run.

Remote write on the way in and PromQL on the way out, both of them open protocols with more than one implementation. The two paths take separate credentials: the one your shippers hold can’t read anything back, and the one your dashboards hold can query every series and change none of them.

Point your existing setup at it.

There’s no agent of ours to deploy and no format to convert to. If it speaks Prometheus remote write, version 1.0 or 2.0, and nearly everything does, it can write here. Local Prometheus servers can keep scraping exactly as they do now and forward the result, authenticated by the write password or by a token your own cluster already issues them.

  • Prometheus remote_write from an existing server
  • Prometheus Agent scrape and forward, no local storage
  • OpenTelemetry Collector via the Prometheus remote write exporter
  • Grafana Alloy or any agent speaking remote write
prometheus.yml remote write
remote_write:
  - url: https://metrics-42-cm.c9t.io/api/v1/push
    authorization:
      credentials_file: /var/run/secrets/tokens/metrics
    protobuf_message: io.prometheus.write.v2.Request

High availability

Up when everything else is down.

Metrics are what you reach for in an incident, so the store that holds them can’t go down with everything else. Every cluster is distributed from the start: each sample is stored on multiple replicas, so losing a machine costs no data and no downtime. Rule evaluation and alert delivery are shared across the replicas too, so a failure moves the work rather than stopping it.

On every tier

  • Every sample written to multiple replicas
  • Writes and queries carry on through the loss of a machine
  • Maintenance takes one replica at a time
  • Older data kept in durable object storage

Alerts fire from where the metrics live.

Every cluster runs its own rule evaluator and its own Alertmanager. Upload the rule groups you already have, route alerts to wherever your pages go today, and there’s nothing of yours to run in between.

  • Alerting and recording rules the YAML rule groups you already write
  • Alertmanager routing to PagerDuty, Slack, webhooks and more
  • Silences in the Alertmanager UI, served from the cluster
  • Rule state in Grafana through the same data source as your dashboards
checkout.yaml rule group
name: checkout
rules:
  - alert: CheckoutErrors
    expr: |
      sum(rate(http_requests_total{code=~"5.."}[5m]))
        / sum(rate(http_requests_total[5m])) > 0.05
    for: 10m
    labels:
      severity: page

Long retention, without the invoice surprise.

Retention you decide

Ninety days by default, set to whatever you need in hours, days, weeks or years. Because ingest isn’t metered, keeping a year of metrics is a storage question rather than a billing one.

No passwords to hand out

Trust your identity provider, or any Kubernetes cluster’s own service account tokens, and workloads push with the identity they already have. Tokens refresh on their own, and each grant names exactly who gets which access.

Three credentials, three jobs

Write can push and never read back. Read-only can query and never push. Admin manages rules and Alertmanager. Hand each one only to what needs it.

PromQL, unchanged

The query API is Prometheus-compatible, so your existing rules, dashboards and alerts keep working. Nothing to port, no dialect to learn, and nothing an agent has to be taught before it can query your metrics.

Remote write 2.0

Clusters accept remote write 2.0 as well as 1.0. It is still experimental upstream, but on two of our own clusters running the full kube-prometheus stack it cut egress by about two thirds.

Custom hostname and allowlist

Serve the endpoint on your own domain, and restrict it to the networks your workloads actually come from.

Rotate on demand

Rotate the credentials from the console, the API or Terraform, whenever you need to. No ticket, no coordination with us.

Reading it back

Your dashboards don’t move.

Add the endpoint as a Prometheus data source in Grafana with the read-only credential and everything you’ve already built keeps working. Recording and alerting rules are PromQL, so they transfer as they are.

Scale

Tier Per node Nodes
Basic 1 vCPU · 2 GiB · 10 GB NVMe 3
Standard 2 vCPU · 16 GiB · 250 GB NVMe 3
Advanced 8 vCPU · 64 GiB · 2 TB NVMe 3–10

Priced per node, per month, exactly as OpenSearch is. Pricing

Grafana’s Node Exporter Full dashboard with a ClusterNest Prometheus endpoint selected as its data source, showing CPU, memory, network and disk panels for one host under varying load. Grafana’s Node Exporter Full dashboard with a ClusterNest Prometheus endpoint selected as its data source, showing CPU, memory, network and disk panels for one host under varying load.
Stock Grafana showing the Basic panels of the community Node Exporter Full dashboard, its data source pointed at a running cluster’s endpoint. Nothing on the Grafana side is specific to ClusterNest.

Pick the version you run.

The storage engine is Cortex, which is why these version numbers don’t match Prometheus’s own. The API you talk to is Prometheus-compatible either way. New clusters default to 1.20.1.

  • 1.20.1
  • 1.21.1

Start with one cluster.

Ten days on a Basic cluster, no card. Point a test Prometheus at it and see what the queries feel like.