Live data from Hacker News

Amazon Managed Service for Prometheus

aws.amazon.com

11–20 of 77 posts

Re: Amazon Managed Service for Prometheus

#11
post #6

Yeah I dunno about this, and the grafana service. They’re not exactly complicated to run on their own. At this pricing you may as well be on Datadog.

I've commented fairly heavily in the related Grafana thread.

Prometheus is a bit of a different story. It does have some operational overhead when you get to a certain point, and scaling it out is not always trivial.

Assuming it works, there is value-add on this one, and the pricing is more in line with active use (ie, a cost+ model, which is more typical of AWS services)

Re: Amazon Managed Service for Prometheus

#12
post #6

Yeah I dunno about this, and the grafana service. They’re not exactly complicated to run on their own. At this pricing you may as well be on Datadog.

setting up one Prometheus server is easy. scaling, HA, Metrics retention for more than 3 days not so much.

Look at VictoriaMetrics (and the related products vmalert and vmagent) for a much easier and pleasant experience as a drop-in Prometheus replacement.

Re: Amazon Managed Service for Prometheus

#13
From the pricing section:

> AMP counts each metric sample ingested to the secured Prometheus-compatible endpoint. AMP also calculates the stored metric samples and metric metadata in gigabytes (GB), where 1GB is 230 bytes.

Surely that's a typo, right?

Re: Amazon Managed Service for Prometheus

#14
post #3

14 cents per "query processing minute" sounds like it could add up very fast. Prom queries can get somewhat complex and it's not rare at all IME to have a dashboard making several multi-second queries per load (whether that falls into "you're using Prometheus wrong" being a separate discussion of course) Edit: The example from their pricing page: > We will assume you have 1 end user monitoring a dashboard for an aver…

Does it put any limits on cardinality of metrics? Grafana cloud's offering was absolutely awful for my use cases. They charge per-series so if you have metrics with a "pod=..." label your prices go through the roof.

Every managed metrics system will put a limit on cardinality because all mainstream available metrics systems cost more per cardinality to query and store. If they don’t limit that you can assume you or some other customer is going to use up the clusters resources and cause an outage.

Like most metrics systems, under the covers in Prometheus each unique combination of dimensions is the same as a new metric line.

Re: Amazon Managed Service for Prometheus

#15
post #6

Yeah I dunno about this, and the grafana service. They’re not exactly complicated to run on their own. At this pricing you may as well be on Datadog.

I've commented fairly heavily in the related Grafana thread. Prometheus is a bit of a different story. It does have some operational overhead when you get to a certain point, and scaling it out is not always trivial. Assuming it works, there is value-add on this one, and the pricing is more in line with active use (ie, a cost+ model, which is more typical of AWS services)

[deleted]

Re: Amazon Managed Service for Prometheus

#16
post #3

14 cents per "query processing minute" sounds like it could add up very fast. Prom queries can get somewhat complex and it's not rare at all IME to have a dashboard making several multi-second queries per load (whether that falls into "you're using Prometheus wrong" being a separate discussion of course) Edit: The example from their pricing page: > We will assume you have 1 end user monitoring a dashboard for an aver…

Does it put any limits on cardinality of metrics? Grafana cloud's offering was absolutely awful for my use cases. They charge per-series so if you have metrics with a "pod=..." label your prices go through the roof.

I like Weave Cloud’s Prometheus hosting model — it’s per host, which is predictable and forecastable.

Re: Amazon Managed Service for Prometheus

#17
post #6

Yeah I dunno about this, and the grafana service. They’re not exactly complicated to run on their own. At this pricing you may as well be on Datadog.

I've commented fairly heavily in the related Grafana thread. Prometheus is a bit of a different story. It does have some operational overhead when you get to a certain point, and scaling it out is not always trivial. Assuming it works, there is value-add on this one, and the pricing is more in line with active use (ie, a cost+ model, which is more typical of AWS services)

Amazon Managed Service for Prometheus is based on Cortex. It is quite expensive in terms of operational and infrastructure costs compared to VictoriaMetrics [1] according to case studies from VictoriaMetrics users [2]. This may explain quite high costs for AMP.

[1] https://victoriametrics.github.io/FAQ.html#what-is-the-diffe...

[2] https://victoriametrics.github.io/CaseStudies.html

Disclaimer: I'm core developer of VictoriaMetrics, so feel free asking any questions about it or about our competitors :)

Re: Amazon Managed Service for Prometheus

#19

From the pricing section: > AMP counts each metric sample ingested to the secured Prometheus-compatible endpoint. AMP also calculates the stored metric samples and metric metadata in gigabytes (GB), where 1GB is 230 bytes. Surely that's a typo, right?

Likely a casualty of copy and paste that left out the superscript formatting. 1GB is 2^30 bytes.

Re: Amazon Managed Service for Prometheus

#20
post #3

14 cents per "query processing minute" sounds like it could add up very fast. Prom queries can get somewhat complex and it's not rare at all IME to have a dashboard making several multi-second queries per load (whether that falls into "you're using Prometheus wrong" being a separate discussion of course) Edit: The example from their pricing page: > We will assume you have 1 end user monitoring a dashboard for an aver…

Does it put any limits on cardinality of metrics? Grafana cloud's offering was absolutely awful for my use cases. They charge per-series so if you have metrics with a "pod=..." label your prices go through the roof.

Grafana cloud sets high prices for high-cardinality metrics because the underlying system - Cortex - isn't optimized well for storing high number of unique time series. For example, it requires at least 15GB of RAM for processing a million of active time series [1]. This means high infrastructure costs, which increase pricing for end users. Other systems such as VictoriaMetrics require up to 15x lower RAM for the same metrics' cardinality [2].

[1] https://github.com/cortexproject/cortex/blob/67648aabae70f19...

[2] https://victoriametrics.github.io/#capacity-planning

Post reply on HN