Prometheus-AI Platform Reviews

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.

The solution is used for monitoring the metrics of applications. The applications have multiple functions, and each function should be monitored. I contact the developer teams to add the solution to the applications. I also use Alertmanager. If, for a specific test, a required metric is below the expected rate, the alert manager will fire a notification to the users.

The solution is useful to collect huge metrics. We have multiple applications. Collecting metrics from all the environments in my data center using the solution is very simple. The dashboards are very useful.

The product must allow users to run multiple instances to get metrics. Thanos is a bit complicated to deploy. It would be better if the solution provided a tool similar to Thanos natively.

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

The product is stable, but sometimes, when we run heavy queries like line data for the previous 24 hours, the CPU and memory utilization are very high. So, we use the product for shorter queries, like line data for the previous 30 minutes or an hour.

The scalability must be improved. More than 20 people use the tool indirectly.

My colleagues use Grafana. Grafana is integrated into Prometheus in our organization.

The initial setup is very easy. It took us an hour to deploy the tool.

It is not difficult to maintain the solution because I run it on Kubernetes.

The tool is open-sourced.

Prometheus is a famous solution. It is a useful product for monitoring application metrics. It needs a developer team to monitor the application functions completely. There are different dashboards like SLO and SLI dashboards. It also has an alert manager tool. The tool is important for modern applications because modern applications employ microservices. The product helps monitor all the functions, but it lacks scalability. Overall, I rate the solution an 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 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. 

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 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.

I am responsible for looking after the security part of my company, for which I received Prometheus from the operational and IT teams. I am not a direct user of the solution, and I am responsible for the decisions regarding the security part.

The solution fixes system health issues while offering features like operational monitoring of our company's current infrastructure and business applications.

I do not have an opinion on the most valuable features of the solution since, in our company, we are not concerned with comparing Prometheus, Grafana, and Wazuh. My company wants to see how the internal tools and processes we have in place could be augmented or expanded to cover security monitoring before deciding to move to an outsourced solution from a managed service provider.

The solution has shortcomings regarding security monitoring-oriented features to support custom use cases, like out-of-the-box test scenarios and threat-related use cases of its users. The aforementioned area can be improved in future releases of Prometheus.

I have been using Prometheus for three years.

It is a stable solution.

The users of the solution in my company are between the range of 50 to 100.

I have experience with Zabbix and Grafana, mainly for operational purposes like monitoring. Now, my company wants to focus on security monitoring, for which we need something more robust, like Wazuh.

Based on the feedback I have received from my colleagues in our company's IT department, the setup phase of the solution is relatively easy. Rather than focusing on the maintenance of the solution, my company focuses on the flexibility of the new features and the customization capabilities introduced.

The solution is deployed on the cloud.

My company doesn't need to pay for the licensing cost of the solution.

My company is in the process of deciding whether or not to proceed with an in-house SIEM and SOC structure source services completely to a managed service provider. In my company's evaluation process, we have assessed tools like Wazuh considering the scenarios, like our in-house resources and capabilities.

I would say Prometheus needs a very low maintenance effort from a maintenance perspective.

I recommend the product to those planning to use it.

Based on the fact that my company has been using the solution for the last couple of years, I rate the overall solution a seven 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.