Prometheus-AI Platform Reviews

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. 

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.

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.

We mainly use it for server monitoring and exposing the metrics format.

I like its lightweight configuration functions.

There are multiple solutions that we use alongside Prometheus while working. These include AM Solutions and Grafana. These are different systems that are logged into and have different technologies and spaces. However, it is difficult to navigate through them at times, so a single dashboard will be something that will be appreciated.

Moreover, there isn’t much clarity regarding the issues that happen at the server end. It is a push model and from the client’s point of view, it needs to look better and solve remote issues.

I have been using Prometheus for more than an year.

The stability is alright and I don’t see any issues. I will give it a seven out of ten as there are some remote issues.

We have a technical department and an internal platform team who contact them on our behalf.

Comparing AppDynamics with Prometheus, AppDynamics has a full suite of solutions, whereas Prometheus is mainly used for monitoring purposes.

We have the solution deployed by a Grafana vendor who made it a cloud version.

It is a good solution overall, so I can rate it a seven 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.

We use Prometheus to gather business and service metrics so that we can export and visualize them through other tools like Grafana.

The solution helps us to scale our products and services, and it helps me by gathering those metrics. 

The DSL could be improved. 

I have been using the solution for three to four years. 

The product is stable. 

The solution is scalable; our engineering team of 80 staff members uses it, and three staff are responsible for maintenance. 

The initial setup is straightforward.

We didn't evaluate other options. We went straight for Prometheus.

I would rate this solution eight out of ten.