Managed Prometheus
Last reviewed by Tyler Eastridge
AceMQ operates Prometheus, the open-source monitoring and alerting toolkit, with Alertmanager and the long-term storage behind it: replicated servers, retention and remote write, cardinality control, upgrades and the pager. We run it in your own cloud account, Kubernetes cluster or data centre (Tier 3), or on infrastructure AceMQ runs (Tier 4). A provider-managed Prometheus can be the better answer, and the table below says when.
Support quotes answered within 1 hour, by a senior engineer.
Planning a build, upgrade or migration instead? See AceMQ Prometheus consulting and services.
Customers
Partners
What's Included
No add-on pricing for incidents. No per-ticket charges. One contract covers the whole surface.
Prometheus local storage is a single node: its own documentation says it is not clustered or replicated. We run the same scrape configuration on two or more servers, tell them apart with external labels, and size memory and disk for the series you actually carry, so one failed node is not a gap in your metrics.
Prometheus is pointed at every Alertmanager, not at a load balancer, which is what the project recommends. We run the Alertmanagers as a cluster, keep routing trees and receivers in code, and send test alerts through every path after a change. A pager that has never been tested is not a pager.
The default retention is 15 days. We set retention by time and by size, plan the disk each server needs, and send samples to long-term storage by remote write where history matters. Retention is decided from the questions people ask of old data, not left at the default.
Most Prometheus outages are series growth in disguise: a label added to a metric, a pod name in a label, a histogram with too many buckets. We watch active series per job, find the metric responsible, and drop or relabel it before the OOM kill and the WAL replay that follows.
Recording rules, alerting rules, scrape jobs, relabelling and Kubernetes service discovery are kept in your repository and rolled out by pipeline or by the Prometheus Operator. We check that targets are being scraped, not just configured, and that rules written in the Prometheus query language (PromQL) still evaluate within their interval.
We read each release against your exporters, rules and remote write targets, rehearse it on a copy, write the rollback down and run it in an agreed window. Prometheus releases a new minor about every six weeks, so we move between long-term support lines on a plan, not in a hurry.
Why AceMQ
Run managed Prometheus in your own account, Kubernetes clusters or data centre (Tier 3) when Prometheus metrics and scrape credentials must stay inside your boundary, or have AceMQ host it (Tier 4) when you want a working platform and no infrastructure to run. Either way the operator is a Prometheus specialist under an AceMQ contract.
AceMQ is not a partner or reseller of Prometheus, the CNCF or any managed Prometheus service. When Amazon, Azure, Google or Grafana Cloud fits better than we do, we say so, and we support the Prometheus side of them at Tier 1 or 2.
One contract covers the Prometheus servers, Alertmanager and the long-term store, so a gap in history is not argued between three owners. AceMQ holds the SLA and brings in partner Prometheus specialists as the work needs them. The 15-minute P1 response is a response time, not a resolution time, and every P1 ends with a written root-cause analysis.
Recording and alerting rules, scrape configuration, Alertmanager routing, Helm values and runbooks sit in your repository. The platform is ours to run and the content is yours, so taking Prometheus in-house later leaves nothing to unpick.
Cloud, Kubernetes, bare metal, hybrid, and air-gapped — including environments where you can't give us outbound network access.
Compared
Amazon Managed Service for Prometheus, Azure Monitor's managed Prometheus, Google Cloud Managed Service for Prometheus and Grafana Cloud run the storage and query layer for you. AceMQ operates Prometheus itself, in your account or ours. These are the differences that decide it, as read on 4 November 2026.
| Question | Provider-managed Prometheus | Self-managed by your team | AceMQ at Tier 3 or 4 |
|---|---|---|---|
| Who runs the storage and query layer | The provider. Amazon, Azure, Google and Grafana Cloud each run a service you send samples to, usually from Prometheus servers or agents in your clusters. | Your team: Prometheus servers, disks, Alertmanager and any Thanos, Mimir or VictoriaMetrics layer. | AceMQ engineers run Prometheus, Alertmanager and the long-term storage layer in your account, cluster or data centre (Tier 3), or on infrastructure we run (Tier 4). |
| How you are charged | On usage. Amazon bills samples ingested, storage and query samples; Grafana Cloud bills active series; Azure and Google bill on their own usage measures. Read each provider's pricing page. | Infrastructure only, plus your engineers' time. There is no licence fee for Prometheus, Thanos, VictoriaMetrics or Cortex (Apache 2.0) or for Mimir (AGPLv3). | Quote only. Your own infrastructure bill plus an operations fee at Tier 3, or a hosted quote at Tier 4. |
| Where a cardinality mistake lands | On the bill as more series or samples, and possibly against a service limit. | On a server as memory growth, an out-of-memory kill and a slow WAL replay. | On our dashboards first. We watch active series per job and tell you which metric grew. |
| Which versions and features you get | The provider decides, and some PromQL, rule or scrape features follow the provider's schedule. | Whatever you choose. Prometheus 3.13 is a long-term support line to 31 July 2027. | The version you choose, planned against the project's long-term support lines. |
| What you still own | Scrape configuration, rules, exporters and collection agents in your clusters. | Everything. | The platform is AceMQ's. Exporters, instrumentation and the meaning of each alert stay with your teams. |
| Who answers when alerts go quiet | Provider support covers the service. Alert design and what you send it stay with you. | Whoever is on call, if the person who set it up is still there. | An AceMQ senior engineer on a live bridge within 15 minutes, 24/7, and a written root-cause analysis after every P1. |
Sources: prometheus.io documentation and release cycle, the aws.amazon.com/prometheus, learn.microsoft.com Azure Monitor and cloud.google.com Managed Service for Prometheus pages, grafana.com pricing, and the project repositories, read 4 November 2026. Providers change terms, so check them before you commit. Provider services are run by their providers: AceMQ supports the Prometheus side of them at Tiers 1 and 2, and operates Prometheus itself only at Tiers 3 and 4.
The same four tiers cover Kafka, Redis, PostgreSQL and RabbitMQ; the escalation-first option is set out in managed open-source operations.
Failure modes
Prometheus is a very good single-node time series database. Most production incidents come from asking one node to do more than that.
Memory follows active series. When the process is killed, the write-ahead log, kept in 128 MB segments, is replayed on restart before Prometheus is ready, and the replay takes longer the more data it holds. During it, nothing is scraped.
Time-based retention does not cap disk use. A size limit can, and the oldest blocks go first. We set both and watch the gap between them.
A second identical server scraping the same targets covers a node failure. Alertmanager deduplicates what the pair both send, which is why the pair is a standard pattern.
An alert rule is only half of paging. If the rule file failed to load, the Alertmanager is unreachable or the receiver token expired, nothing arrives. We test the whole path.
Cardinality and WAL replay are the two faults the support page covers as incidents. Managed operations are about not having them. Prometheus support, Tiers 1 and 2
Retention
Past a few weeks of history, or past what one server can hold, Prometheus sends samples elsewhere. These are the realistic homes, with licences from each project's repository as read on 4 November 2026.
Apache 2.0, a CNCF incubating project. Sidecars or a receiver upload blocks to object storage, and a query layer reads across servers. A good fit when you already run Prometheus and want years of history without replacing it.
From Grafana Labs, under the AGPLv3. Prometheus sends samples by remote write to a multi-tenant cluster. It suits many teams sharing one backend. Ask your own counsel what the AGPL means for your use.
Apache 2.0. It accepts Prometheus remote write and answers PromQL-style queries, and is chosen by some teams for its resource use on modest hardware. It is a different engine, so behaviour is tested, not assumed.
Cortex is Apache 2.0 and CNCF incubating, the project Mimir came from. A provider service is the same remote write pattern with someone else running the far end.
Prometheus's own remote write receiver can be switched on with a flag, but it is a convenience, not a storage architecture. We recommend a layer on purpose. Long-term storage consulting scenario
Releases
The project ships a minor release about every six weeks and patches each for a short time. Its long-term support lines are the ones to plan against.
Released 1 July 2026. Long-term support means selected bug fixes for a year, limited to high-severity (CVSS 7.0 or higher) fixes, as a best-effort commitment by the community.
Estates still on it have no project support line to fall back on. The 3.15 series is the current stable release, and the next long-term support line is expected in June 2027.
We move between long-term lines on a schedule, rehearse each on a copy of your rules and remote write targets, and keep a written rollback.
We do not patch or fork Prometheus. We run the project's releases, track the security fixes that apply to your version and tell you when to move.
Sources: prometheus.io release cycle and the Prometheus release list, read 4 November 2026.
Price drivers
Prometheus has no licence fee, so a managed Prometheus price is mostly engineering time, and that time follows series counts and retention more than server counts. There is no published price list; a written quote comes back within 1 hour of your request.
How many Prometheus servers and clusters, production and non-production, and the order of magnitude of active series and scrape targets.
How long data is kept, and whether it stays local or goes to Thanos, Mimir, VictoriaMetrics or a provider service.
How many Alertmanager receivers and routing trees AceMQ keeps tested end to end, and the cover hours for the platform, from business hours to 24/7 with the 15-minute P1 response.
At Tier 3 the servers, volumes and object storage sit on your cloud bill and AceMQ charges for operations. At Tier 4 AceMQ hosts them and the storage is in the quote, which is where long retention shows up.
Not a fit for
Each of these is cheaper solved another way.
If one team runs a modest estate in a single cloud and its provider's managed Prometheus covers the queries you need, that service is less to run than anything we build.
AceMQ is a contract with senior engineers, not a self-service product. If you want to start collecting metrics in minutes, use a provider service.
A managed platform keeps Prometheus healthy. Adding client libraries, writing exporters and designing alerts is consulting work, scoped separately.
AceMQ is independent of every Prometheus vendor and provider. If your policy requires the storage vendor's own support contract, buy that too. We run alongside it.
Running Grafana on top? Managed Grafana and managed Prometheus can sit under one contract. Managed Grafana
Escalation Path
Every tier reaches a senior Prometheus engineer. There is no tier-1 triage layer to get through.
P1 escalation path
A replay of one P1, from the first page to the written root-cause analysis
15-minute P1 response, 24/7.
A response time, not a resolution time.
P1 opened, on-call engineer paged
Phone, email or Slack reaches the on-call senior engineer directly, whether the incident is in RabbitMQ, Kafka, Redis, PostgreSQL or Kubernetes. No web form, no tier-1 queue.
Senior engineer on your bridge
A senior engineer who already knows your environment joins a live bridge, so nobody has to re-explain your topology.
Specialists across the stack join
When an incident crosses components, the engineers who know each one join. For RabbitMQ, the path runs to the core team.
Written root-cause analysis
Root cause, the fix applied and the prevention steps, delivered after every P1.
Typical engagements
Typical Prometheus support engagements. Each card links to the scenario: the metrics estate, what AceMQ checks or changes, and what the engagement delivers.
SaaS Platform Team
A typical engagement for Java services that restart with exit code 137 after a base image brings a newer JDK: the heap is not full, no OutOfMemoryError appears, and the memory that matters lives outside the heap.
Java
Kubernetes
Docker
Prometheus
Global Aviation Technology Provider
Troubleshooting cluster failover, partition handling, and quorum queue issues in a high-stakes aviation operational environment.
RabbitMQKubernetesQuorum QueuesPrometheus
GrafanaGlobal Telecom Leader
Resolving weekly RabbitMQ crashes, optimizing for 300,000+ connected devices, and architecting horizontal scaling strategy.
RabbitMQKubernetesQuorum QueuesPrometheusGrafanaTelecommunications Operator
Remediation of a Grafana deployment that became unusable during incidents, with dashboards timing out exactly when engineers needed them most.
GrafanaPrometheusKubernetes
PostgreSQLEnergy Utility Operator
Ongoing support for Grafana unified alerting, notification routing, and datasource reliability across an operational monitoring estate.
GrafanaPrometheusAlertmanager
LinuxGlobal Logistics Provider
Assessment of a sprawling Grafana dashboard estate to identify duplication, broken panels, and the small set of dashboards anyone actually uses.
GrafanaPrometheus
Amazon S3
TerraformSupport options
AceMQ offers Prometheus support in four tiers, each handing more of the day-to-day work to AceMQ: 24/7 support and incident management for servers your team runs, proactive monitoring that catches cardinality and alert-routing problems first, managed Prometheus on your own infrastructure, and fully managed Prometheus on AceMQ infrastructure. The 3.x LTS lines and 2.x are covered in all four.
You run it, we back you up
Best for: SRE teams that run Prometheus themselves and need senior cover when monitoring fails.
You run it, we watch it with you
Best for: Teams that want the cardinality spike found in a review, not by an OOM kill.
We run it in your cloud or data centre
Best for: Regulated estates that must keep metrics and scrape access inside their own boundary.
We host it and run it, as a service
Best for: Teams that want Prometheus metrics and alerting without owning the servers or object storage.
| Who does what | Tier 1 24/7 support | Tier 2 Proactive monitoring | Tier 3 Managed, your infrastructure | Tier 4 Fully managed by AceMQ |
|---|---|---|---|---|
| Who runs Prometheus day to day? | Your team | Your team, with AceMQ reviews | AceMQ | AceMQ |
| Where does it run? | Your infrastructure | Your infrastructure | Your cloud account or data centre | AceMQ infrastructure |
| 24/7 incident response | 15-minute P1 response | 15-minute P1 response | 15-minute P1 response | 15-minute P1 response |
| Health checks and CVE alerts | On request | Scheduled | Included | Included |
| Patching and upgrades | Your team, AceMQ advises | Planned with AceMQ | Done by AceMQ | Done by AceMQ |
| Monitoring and on-call | Your team | Your team | AceMQ | AceMQ |
| Data, keys and accounts | Yours | Yours | Yours | Your data, hosted by AceMQ |
Every Tier can start as an ad hoc engagement or an annual partnership, and you can move up or down a Tier as your team changes.
One partner for Prometheus
Support is one part of what AceMQ does for Prometheus. The same engineers deliver consulting, health checks, migrations and end-of-life cover, and support the systems that usually run next to it.
AceMQ operates Prometheus servers, the Alertmanager cluster and the long-term storage layer you choose: replicated servers, retention, remote write, cardinality watching, rule and target rollout, upgrades and the pager. We run it in your account or on AceMQ's infrastructure. Exporters, instrumentation and what each alert means stay with your teams.
Use the provider managed service for Prometheus if one team, one cloud and its query features cover you. Choose AceMQ if you need the metrics inside your own boundary, a version or feature the service lacks, Prometheus outside one cloud, or a predictable cost at high series counts. A provider bills on usage, so a cardinality mistake becomes a bill.
Prometheus local storage is single-node, so we run two or more servers with the same scrape configuration, an Alertmanager cluster, and remote write to Thanos, Mimir, VictoriaMetrics or a provider service when history matters. The choice depends on retention, the number of teams and your appetite for the AGPL; we recommend one on purpose.
No. AceMQ does not ship Prometheus builds and is not a partner of the Prometheus project or the CNCF. We run the project's releases, plan upgrades between its long-term support lines, and track the security fixes that apply to the version you run.
Yes. AceMQ works on Prometheus in two ways: ad hoc engagements for a defined piece of work, such as a health check, an upgrade or an incident, or an annual contract that covers 24/7 support and proactive reviews. Many teams start ad hoc and move to an annual contract once the first engagement is done.
Managed Prometheus is quoted per scope, with no list price: the price depends on the number of environments and nodes, the SLA, whether AceMQ runs Prometheus on your infrastructure (Tier 3) or on ours (Tier 4), and the access and change process you need. Request a quote and AceMQ replies within 1 hour.
Let's talk
Reactive cover, proactive reviews, or AceMQ running Prometheus for you on your infrastructure or ours. A senior engineer scopes it with you, and quote requests are answered within 1 hour.
Production incident right now?Email a Prometheus Architect
Send us a message and we'll follow up within 1 hour — or book a free 30-min consultation directly.
305-204-2607info@acemq.comPrefer to talk now? Call us directly or use the consultation tab to find a time that works.
