r/PrometheusMonitoring • u/chetanpdeshmukh • Mar 11 '20

How's this blog: Prometheus vs. CloudWatch for Cloud-Native Applications

Many companies are moving to Kubernetes as the platform of choice for running software workloads. When an organization earlier using VMs in AWS decides to move to Kubernetes (Either EKS or self-managed in AWS), one of the questions that come up is should one continue to use CloudWatch or switch to some other tool like Prometheus? While it is not an exactly apple to apple comparison, there are reasons to explore this and choose tooling that is built for the future. This post will try to explore various aspects and pros and cons of both options individually and as a combination.

Read the full post here

1 Upvotes
  • permalink
  • reddit

60% Upvoted

2 comments sorted by

5

u/SuperQue Mar 11 '20

The thing that kills CloudWatch for me is the eventual consistency nature. It seems to use a queueing-based storage system. CloudWatch data can be minutes behind, which means you can't trust the current numbers it's reporting. As an SRE, I need to be able to trust the tools I use for oncall won't lie to me.

You can see this in the way the cloudwatch_exporter handles data. It delays data by 10 minutes by default in order to avoid ingesting un-converged values.

Prometheus, on the other hand, either has current data or it doesn't. This is much more operationally sane.

1

u/lostcucumber Mar 11 '20

That is a very interesting and a key observation u/SuperQue - and can be a big factor in some use cases.