Prometheus Group Reviews

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.

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 the product for financial transaction monitoring.

Prometheus provides a flexible and adjustable querying and describing time, allowing for more responsive monitoring. The integration with long-term storage solutions like VictoriaMetrics is a valuable feature.

There is a need for a more comprehensive overview of exporters, especially when dealing with many of them. We currently deal with 20 exporters; sometimes, the labels don't match. Clarity and detailed information on relabeling would benefit users, including explanations on enabling different behaviors and understanding labeling methods.

There could be more granular UI and integration with Grafana. The metric inventory and dictionary could be simpler to understand with a flexible UI. Additionally, they should provide support drill-down selection for Grafana, similar to Azure Monitor.

We have been using Prometheus for more than three years.

It is a stable platform. However, sometimes we encounter stability issues with Kubernetes environment configuration.

The product is suitable for enterprise businesses.

I found a lot of good support articles and case studies. I have a positive opinion about the technical support services.

My previous company used InfluxDB. In comparison, Prometheus has a much better and more scalable monitoring system.

The complexity of the initial setup depends on the particular task. The deployment time varies from a few minutes to a few days per project requirement, including development, staging, and production. The time for data pipeline creation also varies as per different parameters. We have a team of more than 20 executives to monitor the process. Further, it is easy to maintain.

We evaluated Dynatrace or other APM solutions.

We managed services in Azure and AWS. Prometheus is a better product than other native monitoring systems. It provides an efficient bridge between multi-cloud infrastructure. I rate it a nine out of ten.

We use the solution to understand different metrics: RAM usage, CPU usage, application utilization, application performance, container metrics, port metrics, and network metrics.

Prometheus is an open-source product that helps mold and improve it per our requirements. It is a lightweight solution that gives you many different metrics you can use in your application. The product offers complete granularity of your infrastructure. 

It integrates seamlessly with other tools like Grafana, which offers dashboard visibility. Prometheus is an extensively used product. I haven't seen any organization that is not using it. 

Prometheus can be initially difficult for users since it has its query language, PromQL. The minimalistic interface is complicated to understand. They need to improve their interface so that users who don't know PromQL can also use it. You can only leverage the tool when you know PromQL. 

I have been using the product for a year. 

Prometheus is very stable. 

The solution is lightweight, and you can scale it however you want. It is used mainly by our DevOps team, which consists of 10-20 people. 

We haven't contacted the tech support team yet. The tool has rich documentation and a good Slack community. It is a mature tool, and there are a lot of people who have used it. You can get answers to any query or confusion from them. 

Prometheus' deployment is easy and can be completed in seconds. 

Prometheus has both licensed and open-source versions. Most people use the open-source version. The licensing costs are not expensive. 

I rate the product a nine out of ten. 

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. 

My company uses Prometheus because Zabbix is only useful for server machines.

In Prometheus, users can see the logs and containers while also getting to do HTTP monitoring under a single platform.

The most valuable feature of the solution stems from the fact that the HTTP monitoring capabilities offered by the solution help our company monitor SSL certificates while also helping us know if a site can be reached or not. The aforementioned details can be easily acquired with the help of the tool. On the normal desktop, you can create a dashboard from Grafana by using Loki's console.

The services offered by the product are good. Zabbix's site needs improvement.

In Prometheus, everything is query-based. Users can write up queries based on the metrics. In Prometheus, everything is fully for query-based applications. If you want to collect details of metrics, you should be able to write a query for it directly. I want the product to offer better queries for the metrics.

I have three years of experience with Prometheus. I am a user of the tool.

Right now, I don't see any bug-related issues in the product. In the performance part, everything seems to be good.

My company has opted for a centralized setup of the tool, so we have one dashboard set up for multiple applications. Our company's main goal of using the tool is to monitor our applications.

The product's initial setup phase is very easy.

The solution is deployed on an on-premises model.

It is an open-source tool.

Whether I would suggest the product to others or not is something that depends on the applications they use. If you use applications in the government sector or any other sector, then you need to know that the tool fully monitors the applications, and if there are any issues, the details of such problems can be directly acquired through the solution.

The tool is easy to learn and use.

I rate the tool a ten out of ten.

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.

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.