Prometheus-AI Platform 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.

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. 

Prometheus is an open-source monitoring system, but Amazon offers a managed service that takes care of all the setup and maintenance for us. 

We also use Grafana on top of Prometheus to create dashboards that visualize the metrics collected by Prometheus. This is a common setup that many companies use for monitoring their containerized workloads.

We go and see the metrics for any issues with our code. You get to know CPU consumption, memory consumption, all that. That's how we use it for monitoring purposes.

The good thing is it integrates well with the Grafana dashboard. It comes with a UI where you see everything as a graph. And that's similar to what New Relic also gave. So, it's in tandem with Grafana to experience the UI. We have a graph and a software dashboard. We see all the metrics.

There is always room for improvement. 

In future releases, I would like to see more automation. For example, Prometheus automatically picks up some of the metrics from the infrastructure or from the application using its own plugins that it deploys. 

I have been using this tool for around three years.

It is a stable solution.

From a scalability point of view, it's pretty scalable because we are using it for multiple applications and for multiple applications. 

We are on a Kubernetes cluster. We are on a multiple-names basis. So it's pretty scalable. It depends on how you use it. I did a POC long back, so for Amazon, that's pretty much scalable. That's why people use managed services because Amazon or any cloud vendor is responsible for scaling up and scaling down as we are using it. So the management is scalable, for sure.

We have around 200 end-users using this solution in my team.

Prometheus installation is pretty easy. We are using the managed one from Amazon. So that's easy. You don't have to install anything. It comes as a service, like a software service from AWS. But even then, installing that, I've done it long back. It's not complex; it's pretty easy.

The deployment doesn't take more than half an hour. However, for any unmanaged solution, you have to maintain it. For example, there will be updates to the solution on your end. But if you're using the managed ones from Amazon, you don't have to worry about those updates. Maintenance: that mechanism will take care of it. You just have to use it and consume it. 

Prometheus is open source, so you can install it on your own or use a managed service like Amazon Managed Prometheus. We chose to use a managed service because it's easier to manage and scale.

We have the open-source version, so we don't pay for it.

Overall, I would rate the solution an eight 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. 

I use Prometheus to monitor Kubernetes clusters.

The most valuable features of the solution are metrics scraping capabilities and the open source community and support.

Prometheus requires improvement on the query side. When I query the data from last year, it queries within its database. Sometimes, it just crashes it out. They need to improve this feature where the SQL queries take much time and sometimes crash the whole Prometheus cluster.

I have been using Prometheus for one year.

The solution's initial setup is easy and fast.

Prometheus is an open-source solution.

We chose Prometheus because it was easy to install and has wide communities to support us. The solution's alerting functionality has improved our incident response time. We have integrated the alert manager with PagerDuty, which has greatly helped us improve the functionality. Prometheus is an easy-to-use solution, and I would recommend it to other users.

It is easy for a beginner to learn to use Prometheus for the first time. You can integrate it and start using it.

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

The most valuable features of Prometheus are its ability to collect metrics and its integration with Grafana.

The primary area where Prometheus could be improved is in terms of pricing, particularly when used with managed services like AWS. Many clients have found the pricing for managed services steep, prompting them to switch to the open-source version. This switch has led to the adoption of Prometheus with Amazon EKS. Still, it has also resulted in high data transfer costs due to the multitude of microservices and the associated cluster logs. As a result, clients are facing higher bills, primarily driven by increased data transfer rates and bandwidth usage.

We have been using Prometheus for two and a half years.

It is a stable product.

It is a scalable platform.

The initial setup is easy if you have good knowledge of Helm. It requires setting two to three commands. Without using Helm, you have to create custom file deployments. Overall, it is a simple process.

The alerting functionality provided by Prometheus has significantly improved our incident response time. It enables us to gather data from various instances or ports within our environment, such as ETS.

I advise others to gain essential knowledge of query optimization and Grafana. It is an expensive product if utilized with managed services. It would be beneficial to use the open-source version.

I rate it a nine 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 it for monitoring our infrastructure metrics.

It is highly valuable as it serves as the foundation for our infrastructure monitoring tools.

The installation process proved to be exceptionally straightforward.

The interface is not particularly user-friendly and that could be improved.

We have been using it for two years.

I would rate its stability abilities eight out of ten.

I would rate its scalability capabilities eight out of ten.

The initial setup was straightforward, thanks to our utilization of the Kubernetes operator.

In terms of ROI, you can potentially save a few weeks, or perhaps two to three days, depending on the use case.

We evaluated Elastic and Kibana.

I recommend it because it's an incredibly useful tool, and its installation and usage are very straightforward. Overall, I would rate it eight 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.