Prometheus Reviews

We use Prometheus for monitoring all aspects of our infrastructure end-to-end. That includes servers, virtual machines, databases, caching servers, ELK stack, and our Kubernetes servers. We are users of Prometheus.

The scraping mechanism is a wonderful feature. I've used many other monitoring systems that were mostly client-server-based models including Nagios, Zabbix, and New Relic, among others. With all of them, the server used to get overloaded when the client sent too much matrix, even in the case of a pull or push mechanism of client-server architecture. In my previous organization, we had to host several Nagios individual servers in case one went down. Prometheus gives us high availability automatically and a stand-alone process; if it doesn't run on one server, it runs on another. It's wonderful that the exports run on different servers. They scrape the matrix and then open it to a particular URL for Prometheus to read those metrics and then store them. 

I very much like the remote write feature. Prometheus bridges the gap for everyone whether they've come from an old monitoring setup or are into microservices. I also like the concept of dynamic conflict which is brilliant. 

We chose Prometheus because it's open source with a lot of documentation and community support which is lacking in other products.  

The Prometheus community says it's not meant to be clusterized so people shift to solutions like Thanos and VictoriaMetrics. Prometheus could have done that too, it's not complicated. Rather than us having to use a different database, Prometheus could develop its own database a little more so that it becomes a one-stop solution. That would be wonderful. 

One of the issues is that dynamic conflict uses regular expressions and it can be confusing for people not familiar with them and the unique specific symbols and line-cut characters. 

I've been using this solution for six years. 

The product is stable. In my previous company, we used Prometheus with Docker Compose and kept high data retention. We didn't have a third database to store the matrix so the container used to go down very often. The issue was not with Prometheus but that there were insufficient resources for the monitoring system. 

40% of those in our company need Prometheus for their daily work, including developers. Indirectly, that number goes to 80% when you include those reliant on the reporting. We do everything through Prometheus. We also use Nagios for monitoring bare metals and in a way Nagios monitors Prometheus and Prometheus monitors Nagios. In that way, we're able to monitor two different monitoring systems.

The solution is not meant to scale.

There is good documentation and the open source community offers good support, so I haven't needed to contact customer support. 

Prometheus is very easy to set up and is user friendly. It just runs and gets you a very simple UI running on export. Where it becomes complicated is people not understanding the configuration because its support of many exporters means a lot of jobs need to be written in order to use it well.

Deployment time depends on the use case. Our present use case is quite complex so implementation took about a week. We wanted to monitor 10 to 15 clusters so we had to deploy Prometheus on a different environment and ensure that our data was placed at a stable central location. We initially carried out a POC which took less than a day.

The solution is open source. 

If a company uses bare metal systems and their product doesn't need significant extensive monitoring, I wouldn't recommend Prometheus. That's not because it's difficult to use but because it doesn't qualify for that use case. If you have a use case where you already have microservices deployed and you want information, then that's a suitable use case. Otherwise, Nagios or any other simple operating system is easier to use. It depends on what kind of product needs monitoring.

In spite of the scaling issue, Prometheus provides almost everything I need. Despite needing to integrate it with other tools, it's seamless and simple to use. I rate this solution 10 out of 10.

Our company is a FinTech financial institution. We expose financial APIs for major FinTechs in the US. Basically, we are a bank and have a lot of applications running behind the scenes. APM is super crucial to our organization. We need to be able to interact, understand, and get a holistic or 360-degree view about everything going on in the organization. This view includes the infrastructure and the application sides. 

The solution helps developers get a holistic view of their application performance under the AKS environment. This is especially important in lower environments where developers need to interact with everything from performance to logging perspectives. In the very early stages, the solution gives developers a quite good overview about how they are developing products and how they can make them work more efficiently. 

The solution is on-premises at our own data centers. We have an additional, hybrid installation with Amazon that includes a private cloud. 

We have 150 engineers who use the solution for applications running under the Kubernetes environment. 

The sky is the limit because the solution is a very flexible open box that can be used vastly to do anything you need to monitor applications. There is nothing that you cannot do with it. Every day, our developers or SRE teams are adding additional features with the ability to think outside the box and configure whatever they want. 

The solution is the most common, major tool for FinTech or high-tech companies. Every technology company using Kubernetes is using the solution. 

The setup could be made easier for new users because it requires a bit of advance knowledge or experience. 

I currently manage our teams that use the solution. Previously, I had hands-on experience with the solution. 

The solution is stable with no reported issues. 

The solution is scalable. 

We have not needed technical support. 

The setup is not too complicated. If you have experience with the solution, then setup is an easy task. I rate setup a five out of ten. 

The basic configuration and deployment parts are easy. The more complicated part is creating the benchmark and alert behind it to make sure it gives us what we need from the application side. Customizing the solution for our needs takes more time. 

We implemented the solution in-house. We have a big devops team and a big SRE or platform engineers team. This is their bread and butter and they create Terraform infrastructures or services for a living.

If you use the solution, then you will definitely realize ROI. 

The solution is not expensive. In comparison to the pricing of New Relic or Datadog, the solution is basically free. 

We use several tools to accomplish our goals including the solution, New Relic APM, Datadog, Elasticsearch, and Amazon OpenSearch. 

New Relic APM and Datadog are closed box legacy tools. You cannot reconfigure them to do whatever you want. We use them because they have certain abilities but they cannot be customized for our specific needs.  

The solution is an open box Kubernetes tool so we have the ability to play with it. 

Make sure that you have dedicated manpower to configure and manage the solution. It requires handling, not necessarily on a daily basis, but it definitely requires someone who is focused and has expertise with the solution. 

Know in advance what you want to gain from the solution. Don't jump in to configuring or deploying before knowing what you expect from it. 

I like the solution very much. I think it is a major tool, especially in advanced environments. The open box provides a lot of flexibility and gives a very holistic view of the entire Kubernetes environment. 

Integrating with the Rancher management tool gives the solution even more abilities. There are several tools that we use behind the scenes to ease the process but the solution on its own is a very good tool. 

I rate the solution an eight out of ten. 

In order to have a visuality from Grafana, we create the metrics using Prometheus. Prometheus pushes all these metrics to Grafana. After scraping all the metrics and plotting them on a graph using Grafana, then we used Prometheus as middleware for getting all the metrics from all our applications and infrastructure.

We use Prometheus with Grafana and without either of them, it would not fit our use case.

The most valuable features of Prometheus are the many functions available. The functions are helpful for understanding the behavior of applications and infrastructure.

A slight alteration to the user interface should be made to increase efficiency and streamline the process. Currently, we are utilizing Prometheus to gather and compile metrics and then utilizing Grafana to display them in the form of a graph. However, I believe that Prometheus has the capability to handle both of these tasks on its own, with perhaps the addition of a supplementary plugin. By doing so, the need for utilizing two separate applications will be eliminated.

I have been using Prometheus for a couple of years.

We have experienced some performance issues, but I cannot say for certain whether it is due to Prometheus or if it is a result of our infrastructure. During these instances, we have noticed that the mix of metrics can become disrupted for a period of time due to high levels of CPU utilization or other factors. As a result, we are unable to retrieve metrics during these instances. This has been a challenge that I have faced while using Prometheus. It is unclear whether there is a solution, such as a resource optimization, that could help to alleviate these issues. However, it is expected that the utilization of resources should improve as the number of metrics that we scrape increases.

I rate Prometheus an eight out of ten.

I rate the scalability of Prometheus a ten out of ten.

The initial setup should be relatively uncomplicated. I haven't personally dealt with the implementation aspect but based on my previous experiences, we utilized Prometheus and Grafana together in our Kubernetes cluster. Thus, we were able to deploy it with ease, all within one unified operation.

We did the implementation of the solution in-house.

We have received a return on investment using Prometheus.

The solution is open source.

Prometheus, similar to Grafana, is incredibly useful and effective, particularly when you become more familiar with its functions and capabilities. By developing a stronger understanding of the functions utilized by Prometheus, it becomes much easier to extract relevant metrics and create visually appealing graphs. Thus, it is recommended that users invest time in learning and mastering these functions for optimal results.

I rate Prometheus an eight out of ten.

Our primary use case for Prometheus is collecting metrics.

The feature I found most valuable is the number of integrations. It is the industry standard for metrics.

If you are not quite technical, it can be pretty hard to understand the way it works and how to query data in Prometheus.

In the next release, I'd like to see a more user-friendly interface where you can have more options on the graphical interface and more integrations that can help with the scalability.

I have been using Prometheus for about five years.

I would rate the stability of Prometheus a nine, on a scale from one to 10, with one being the worst and 10 being the best.

I would rate the scalability of this solution a five, on a scale from one to 10, with one being the worst and 10 being the best.

In case you want to make it more scalable, you can add other open-source projects like Thanos that can integrate with Prometheus.

I have not contacted technical support because there is none. The community is the technical support.

The initial setup of Prometheus was easy.

The deployment time mostly depends on the desired use case for Prometheus.
For example, monitoring a couple of servers would take about one hour to deploy. On the other hand, if you are planning to deploy several clusters or Kubernetes and other managed services, that adds complexity, and then deployment takes days or even weeks.

The reason we didn't go with, for example, AWS X-ray, Azure Monitor, or AppDynamics is that we didn't want to be tied to a specific provider.

I would advise others that before buying this solution they make a good design and think about their use case because the metrics can scale rapidly as can the amount of data you ingest. Without a good design, that might not be possible.

Overall, I would rate the Prometheus solution a nine, on a scale from one to 10, with one being the worst and 10 being the best. The reason for this is because it's open source, so there are no fees. There are no licenses to pay for and it has a great community. 

Prometheus became the standard of the industry for metrics as you can find a lot of documentation, forums, and many answers to any questions online. Also, Prometheus has constant updates to improve applications and to fix either the box or the issues. The ability to integrate with a wide range of other applications makes this solution even better.

We have Prometheus deployed in both the public cloud and on-premises.

There are about 100 users of Prometheus in our company.

Our company uses the solution to scrape values from environments in central or sister premises to ensure safety. 

Kavana serves as our general user interface. The solution is used by developers, not general users by default. Developers access the solution when they want to see more details. 

The solution has very much improved our functionality and productivity. 

The solution offers an easy way to install and scratch values. 

The rest API is really valuable.  

The alert functionality is kind of lackluster. 

I have been using the solution for seven years. 

The solution is stable so far, but it might be interesting to view reports. 

For example, we were advised to check memory because Linux has an OOM killer that needs to be watched or monitored. 

The scalability is okay for the default parameters. It would be beneficial to have some kind of context included with the default parameters. We are pursuing this type of information or reporting right now for our Kefana project. 

Depending on the outcome of our RFP, we may be scaling in the near future. 

I have not contacted technical support. 

I did not use a different solution. 

The setup is pretty easy. 

We partnered with Grafana for implementation. 

One day a week if needed, a team member works with Grafana for any ongoing maintenance or support. There really isn't much to do so sometimes maintenance occurs less often. 

The solution is open source so is free. A paid version is also available. 

I rate the solution a seven out of ten. 

Prometheus can be deployed on-premise and in the cloud.

Prometheus is an open-source network monitoring solution.

Prometheus is very flexible. We use it for network monitoring and we can always add new servers, equipment, or whatever that we want to monitor with it.

I have been using Prometheus for approximately two years.

Prometheus is stable.

The scalability of Prometheus is very good.

We have the solution rolled out across multiple small businesses. We have hundreds of users collectively using the solutions.

I have not used the technical support from Prometheus.

Prometheus has a learning curve when setting it up. It definitely requires a little bit more hands-on than other solutions. It is an open source solution which means you do need to go through and read the literature that they have online for setting it up. The setup could be made easier.

I am the one who manages Prometheus and does the maintenance.

Prometheus is free. We use the solution for monitoring and it has worked well.

The price of Prometheus is good, it is affordable because it is open source and there is no cost to it. You put it on your own server and the costs incurred completely depend on how you set it up.

Prometheus can directly compete against other solutions, such as Zabbix or any other network monitoring solution.

My advice to others is to read all the documentation before usage.

I rate Prometheus an eight out of ten.

I rated it an eight because it is easy to use but the installation can be difficult.

We use all of the metrics of Prometheus as an indicator if something goes wrong with our own applications as part of our on-call service. We represent the data on Grafana because Grafana is tightly integrated with Prometheus.

It has lots of APIs and libraries to integrate with any kind of language, including Python, Perl, PHP, Java, and Kotlin. You can easily plug and play integrating Prometheus with many operators. The official operators can be run on top of Kubernetes. It is a widely known and good solution for monitoring. 

The simplicity of the query language could be improved. The current query language is not easy to work with.

I have been using Prometheus for the past year.

Prometheus is definitely stable.

I do not handle scalability because it is managed by other teams.

I would recommend that you use it with simple applications, by running a Docker inside the Docker. It is a good and robust solution, and it is widely known by many companies across the software domain. I would rate Prometheus a nine out of ten.

Our primary use case is for the integration with Grafana to receive metrics. We use it as a pulling and a pushing mode to send information from applications to servers.

The most valuable feature is that we can receive information in different formats.

I would like to see improvement in the analysis tools and customization features. I would like to see some visualization tools potentially even though it is not their main marketing point for customers.

I have been using Prometheus for the past three years.

There is stability with Prometheus.

There is scalability with Prometheus. We have around three hundred engineers using the solution daily.

Customer support is handled through documentation since it is open source.

The initial setup is somewhere between simple and complex.

This is an open-source solution.

I would rate Prometheus an eight out of ten.