Prometheus Reviews

I use the solution in my company for monitoring purposes and metrics.

The most valuable feature of the solution stems from its ability to provide metrics and to set up the blackbox exporter to monitor microservices to see whether they are up or down, how requests are coming in, and how much data it can handle.

Setting up the rules in Prometheus can be confusing, making it an area where improvements are required. My company has to rely on a blackbox exporter to get the metrics and make the solution easy for us.

I have been using Prometheus for five years. I am a customer of the tool.

It is a good and stable solution. Stability-wise, I rate the solution an eight and a half out of ten.

Scalability-wise, I rate the solution a seven out of ten.

Once you get to know about the product, the setup phase becomes easy. It would be difficult to handle the product's setup phase for newbies.

Development, DevOps, and QA teams use the product in our company to monitor the application responses. Around 60 people in my company use the product.

I have experience with Grafana. I use Terraform as an IaC tool. I am an open-source contributor to Terraform.

There are no restrictions on whether the solution can be deployed on the cloud or an on-premises model. The deployment model depends on the requirements of the users. The product can be deployed on a cloud server or an on-premises server.

The solution can be deployed in thirty minutes.

My company uses the open-source version of the product.

I have implemented Prometheus for our company's infrastructure monitoring. Our company uses Kubernetes clusters on which we deploy the monitoring stack. The alert management in Grafana helps with the metrics part, which are visual representations. There are also Helm charts available to help with the setup.

The most beneficial features of the solution for our application stem from how we can customize the metrics and rules as per requirements. For microservices, our company can do searches at a CPU level and see how load gets distributed and how requests come into a particular service or application.

The product's alerting capabilities are helpful, but I need to set up the alert manager, and there is a config file where all the configurations need to be mentioned while also setting up the services or API endpoints.

That are a lot of ways to set up the product and use its integration capabilities with the other tools in the monitoring ecosystem of our company. In our company, we can run it as a service over our local servers, and we can also set it up as a monitoring tool using Kubernetes cluster.

The product was used as a monitoring tool in India for Yes Bank's application named Yes Genie.

I would tell the product's potential users that Prometheus is one of the best tools in the market for monitoring purposes.

I rate the overall tool a nine out of ten.

I use Prometheus to monitor my infrastructure and applications by setting up targets for scraping metrics, writing queries in PromQL to analyze the data, and configuring alerts to notify me of any issues. It is great because it can efficiently handle large amounts of metrics.

Prometheus has been incredibly helpful in improving my system's observability and alerting processes. It provides metrics for monitoring various aspects of my infrastructure and applications, helping me identify issues quickly.

The most valuable features of Prometheus for metrics collection and monitoring are its stability, robustness, and rich set of features. Being an open-source product, it offers reliability and flexibility, and if something is missing, it is easy to extend its functionality through integrations or custom solutions.

While Prometheus is an excellent product overall, one potential area for improvement would be fixing the occasional glitches and bugs.

I have been using Prometheus for almost seven years.

I'm generally happy with Prometheus's stability. Although there might be occasional glitches, we usually address them swiftly by reporting issues. Over the past year, we have seen improvements in memory usage.

When we need to scale Prometheus, we do that by using specific products. Considering its purpose, it is fairly scalable. About 1,000 users within our company use Prometheus for monitoring and alerts.

The initial setup was very simple and deployment only took us about 15 seconds. Maintaining Prometheus is just a regular part of our responsibilities, like managing any other system in our infrastructure. It doesn't demand extra effort or special attention beyond our usual routine tasks.

Integrating Prometheus with our existing systems and tools was easy. We seamlessly connected it with VCS, Grafana for visualization, and Slack for notifications, making management and monitoring straightforward.

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.

We use Prometheus to monitor the health of more than 300 to 400 servers, including their uptime, CPU memory usage, and iowait.

The most valuable feature of Prometheus is the ease of pulling the metrics.

The solution's error handling part could be improved. The errors that are sometimes shown are not accurate enough to debug. The code base can be improved so that the debugging part is easy if Prometheus is not working. The error should be so that the user can easily understand where the issue could be, and it would become easy to debug.

I have been using Prometheus for one year.

We had issues with the solution's stability regarding SSL certificates around a year back, but now it's stable.

I rate the solution an eight out of ten for stability.

Whenever a new region comes up on any of the clouds, like Azure, Google, or AWS, we need to add Prometheus servers over there, and the metrics need to be pulled from those new servers. Every month, we increase the number of servers where Prometheus is used. We did not find any challenges, and we are able to view the metrics.

I rate the solution a nine out of ten for scalability.

I joined my current company around one and a half years ago. Since that time, we have been using Prometheus. In my previous organization, we used a separate stack for monitoring solutions, including an open-source solution called Telegraf.

The initial setup of the solution is easy because it has pretty good documentation.

We were able to deploy Prometheus, Grafana, and Loki, and we were able to pull the metrics from more than 300 servers in one week.

Prometheus is an open-source solution.

I would recommend Prometheus to other users. If you have to monitor the health of multiple servers, just write an Ansible playbook or a Salt state, and the ease of deployment of Prometheus to any number of services is really easy. We are also using SSL certificates with the solution. With Prometheus, you will not face any security issues. It's a great monitoring solution for pulling the metrics.

Overall, I rate the solution a nine 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.

For a project I am currently working on in my company, I use Grafana, but for the data source part, I use Prometheus.

I use Prometheus in a Kubernetes cluster. I use Prometheus for the processes attached to Amazon EKS.

The UI and GUI are areas of concern in the product. The UI part of the tool should be more friendly. More GUI should be added to the solution. The UI and GUI should look good.

I have been using Prometheus for a year. I am a customer of the tool.

Stability-wise, I rate the solution a ten out of ten.

I haven't faced any scalability issues in the product. Scalability-wise, I rate the solution a ten out of ten.

Around five to ten DevOps engineers use the product. Other employees in the company don't use the solution because it is a product that is used to monitor other clusters. The DevOps team uses the product to monitor clusters.

I use Prometheus and Grafana.

I used to use Amazon CloudWatch as an in-built proprietary monitoring and alerting tool in my company. Amazon CloudWatch's use had a certain cost attached to it, but Prometheus is an open-source tool.

The product's initial setup phase was easy.

The solution is deployed on the cloud.

The solution can be deployed in three to five minutes.

Prometheus is an open-source tool.

Speaking about how I have implemented the product for my company's infrastructure, I would say that I have a simple Prometheus in my cluster, which is Amazon EKS' cluster using a Helm Chart. Helm Chart is a package manager for Kubernetes-based applications. I have installed Prometheus and Grafana using Helm Chats, which is very easy to install.

In terms of the benefits of the tool attached to the performance monitoring part, I use Prometheus as a data source. Prometheus helps me to pull my Kubernetes cluster data. Basically, Prometheus helps me as it serves as a one-stop destination for my Kubernetes cluster data. I export data from Prometheus to Grafana, which helps me with the visualization part. In general, Prometheus helps me visualize my data and gives me a structure for my clusters.

I would say that I use Grafana for the alerting feature that helps maintain system reliability. I use Prometheus for my data sources and by adding it. From the data, I create email alerts. The first point of contact for me is Prometheus for Grafana's dashboard and for each and every alerting feature as well. I can say that Prometheus is very useful for me if I consider its alerting features.

I have only used Prometheus to monitor my Amazon EC2 servers and Amazon EKS clusters. My use cases indicate that I have been using Prometheus to monitor Amazon EC2 server and Amazon EKS clusters. I don't use the product extensively for anything else apart from the fact that I use it to monitor Amazon EC2 server and Amazon EKS clusters.

I recommend the product to those who plan to use it.

I would like to mention that if you use Prometheus and if you integrate it into other tools, then it will save a lot of costs as it is a free and open-source product with a strong community. Prometheus will be getting an updated version soon, which is very soon.

I rate the tool an eight out of ten.

In Prometheus, the graphs and everything are too complicated. With Prometheus, you need to sit down and study it properly. Though the product offers a pretty interface, if you don't know what you are doing, then the tool doesn't provide you with customized reports. The product sends its users email reports, which they need to look into.

The query language in Prometheus is an area of concern where improvements are required.

The ability to generate customized reports should be made available in the product.

I have been using Prometheus for three years.

Once the product is properly configured and installed, it works perfectly.

It is a scalable solution.

Around 600 people in my company use the product.

I have experience with Sophos. There are some problems with the GUI of Prometheus. The GUI of Sophos is simple and easy to use.

I would recommend others to choose Zabbix over Prometheus.

I rate Zabbix a nine out of ten.

The product's initial setup phase is not easy as one needs to know the Unix language.

Considering that there is a need to update and upgrade the Linux part, the solution can be deployed in an hour. It may take a day for someone who does not know the product's installation phase.

Prometheus is available as an open-source product.

Prometheus for monitoring our company's infrastructure and applications is useful, as it serves as a network monitoring tool that helps you understand the bandwidth capabilities while also ensuring that you get to know who is accessing what at what time of the day. The tool provides details on where the company's network bandwidth is used.

Speaking about how Prometheus has helped in our company's system observability and alerting processes, I think it's just an added tool in our environment because we don't use it as a primary solution. Primarily, my company is dependent on Sophos. The other solutions probably don't give you the results you want, but it all depends on how well you have done your policies. The aforementioned reason may prompt a user to use Prometheus.

Features of Prometheus for metrics collection and monitoring stem from the ability that the product provides to track bandwidth.

It is a task to deal with Prometheus' query language because it is not as clear as you would expect it to be, which poses a challenge.

The integration of Prometheus with Zabbix can be a nightmare, and it can be quite challenging. There are also chances that you may get errors when trying to integrate Prometheus with Zabbix. You have to wait for the next release of Prometheus and Zabbix to be able to install them together.

The product is easy to maintain.

The product works fine in terms of its abilities related to incident detection and resolution, but the product has to do something with the GUI part, which is not appealing enough as someone would not want to sit in front of it and look at graphs.

Those planning to use Prometheus should be aware of the syntax part in programming before using it.

I rate the overall tool a seven out of ten.

We use Prometheus for observability and analyzing data for business metrics and system metrics. It helps us with messaging services observability. It also helps a lot with the architecture and scalability of the services. The solution provides system observability regarding Kubernetes information, CPU usage, memory, and whether the system is scaling or not.

The resilience of the solution's metric collection is very nice. Although it's very strict about the number of unique metrics for each service, the metrics collection is very powerful.

There is a tool called Prometheus Exporter that doesn't work well. I don't know if Prometheus maintains it or if it's an open-source service. When we have Cron jobs from our services, Prometheus needs a live endpoint to collect the metrics.

Since Cron jobs have a time limit, I rely on Prometheus Exporter to collect metrics. When I send metrics for Prometheus Exporter, it doesn't work very well.

I have been using Prometheus for four to five years.

I’ve never had any stability issues with the solution.

I rate the solution’s stability ten out of ten.

Prometheus is a scalable solution.

I would recommend the solution to other users.

Overall, I rate the solution an eight out of ten.