Pingdom vs Prometheus: What are the differences?
Pingdom: Uptime and performance monitoring made easy. Pingdom is an uptime monitoring service. When problems happen with a site that Pingdom monitors, it immediately alerts the owner so the problem can be taken care of; Prometheus: An open-source service monitoring system and time series database, developed by SoundCloud. Prometheus is a systems and service monitoring system. It collects metrics from configured targets at given intervals, evaluates rule expressions, displays the results, and can trigger alerts if some condition is observed to be true.
Pingdom and Prometheus are primarily classified as "Website Monitoring" and "Monitoring" tools respectively.
Some of the features offered by Pingdom are:
- Uptime & Response time reports
- Multi-step transaction monitoring
- Email, text & twitter alerts
On the other hand, Prometheus provides the following key features:
- a multi-dimensional data model (timeseries defined by metric name and set of key/value dimensions)
- a flexible query language to leverage this dimensionality
- no dependency on distributed storage
"Simple and reliable" is the top reason why over 224 developers like Pingdom, while over 32 developers mention "Powerful easy to use monitoring" as the leading cause for choosing Prometheus.
Prometheus is an open source tool with 24.6K GitHub stars and 3.49K GitHub forks. Here's a link to Prometheus's open source repository on GitHub.
Twitter, Pinterest, and Mozilla are some of the popular companies that use Pingdom, whereas Prometheus is used by Uber Technologies, Soundcloud, and DigitalOcean. Pingdom has a broader approval, being mentioned in 855 company stacks & 218 developers stacks; compared to Prometheus, which is listed in 235 company stacks and 84 developer stacks.
What is Pingdom?
What is Prometheus?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to add, upvote and see more prosMake informed product decisions
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions
We recently implemented Thanos alongside Prometheus into our Kubernetes clusters, we had previously used a variety of different metrics systems and we wanted to make life simpler for everyone by just picking one.
Prometheus seemed like an obvious choice due to its powerful querying language, native Kubernetes support and great community. However we found it somewhat lacking when it came to being highly available, something that would be very important if we wanted this to be the single source of all our metrics.
Thanos came along and solved a lot of these problems. It allowed us to run multiple Prometheis without duplicating metrics, query multiple Prometheus clusters at once, and easily back up data and then query it. Now we have a single place to go if you want to view metrics across all our clusters, with many layers of redundancy to make sure this monitoring solution is as reliable and resilient as we could reasonably make it.
If you're interested in a bit more detail feel free to check out the blog I wrote on the subject that's linked.
Why we spent several years building an open source, large-scale metrics alerting system, M3, built for Prometheus:
By late 2014, all services, infrastructure, and servers at Uber emitted metrics to a Graphite stack that stored them using the Whisper file format in a sharded Carbon cluster. We used Grafana for dashboarding and Nagios for alerting, issuing Graphite threshold checks via source-controlled scripts. While this worked for a while, expanding the Carbon cluster required a manual resharding process and, due to lack of replication, any single node’s disk failure caused permanent loss of its associated metrics. In short, this solution was not able to meet our needs as the company continued to grow.
To ensure the scalability of Uber’s metrics backend, we decided to build out a system that provided fault tolerant metrics ingestion, storage, and querying as a managed platform...
(GitHub : https://github.com/m3db/m3)
We have Prometheus as a monitoring engine as a part of our stack which contains Kubernetes cluster, container images and other open source tools. Also, I am aware that Sysdig can be integrated with Prometheus but I really wanted to know whether Sysdig or sysdig+prometheus will make better monitoring solution.
Great service, gives me piece of mind. One thing I really don't like: they set the default notification downtime to 2 min or greater. I missed a total of 13 minutes of downtime for our blog over a three month period back before we moved it over to the rails app because there was basically one minute here, one minute there. I was pretty angry when I found out they weren't notifying me. But then I realized that it probably makes sense. But they should be more transparent and make it clear that there is a 2 minute window when you first set up alerts.
We primarily use Prometheus to gather metrics and statistics to display them in Grafana. Aside from that we poll Prometheus for our orchestration-solution "JCOverseer" to determine, which host is least occupied at the moment.
Pingdom is a tool I use close to deployment of new apps or sites and periodically used to check the health of an app or site over time. The analysis of request times, assets and more is second to none.
For making sure everything is up, and telling us when it's not. We tested a few services and pingdom is still the quickest to recognise downtime.
Monitoring for Coolfront Mobile, Coolfront Agreements and Coolfront Books. Alerts Coolfront IT team when systems can not be reached.
Nice 1min monitoring time that will show us if something went down. Best visualisation and fastest downtime detection.
Gather metrics from systems and applications. Evaluate alerting rules. Alerts are pushed to OpsGenie and Slack.
We primarily use Prometheus to gather metrics and statistics to display them in Grafana.