Developer at a tech services company with 11-50 employees
Real User
Top 20
2024-10-02T15:34:00Z
Oct 2, 2024
There is some delay in logging that they need to improve on. While CloudWatch is good, when compared to Dynatrace, there are several areas for improvement. For instance, Dynatrace has better distributed tracing and a feature like back trace, which CloudWatch lacks. In terms of alerts, we use PagerDuty, but composite alarms and similar features need more work.
The solution should provide human-readable metrics. Amazon CloudWatch should add custom metrics, like static metrics or any data relevant to our use case.
Senior Performance Architect at a tech services company with 501-1,000 employees
Real User
Top 10
2023-10-30T11:07:01Z
Oct 30, 2023
There is a need for seamless integration with databases, whether they are open-source or proprietary like InfluxDB. Incorporating a straightforward method or a plug-and-play solution for integrating these databases with our systems, facilitating smooth data transfer, and enabling the creation of dashboards for monitoring and analysis would be beneficial.
There is room for improvement in the pricing because they have a premium version, but it's not really a premium version. It's just an enhanced monitoring version, and it can be a bit expensive depending on your usage.
When you set up CloudWatch, you can't even take a lot without checking on them or without going through the whole configuration because we're configuring. It's not a frequent feature you always work on. The integration requires a lot of permissions and the tool delays in providing notifications. Sometimes, receiving a notification after an update takes a long time. So, we prefer using a monitoring tool like New Relic or Grafana. Another area of improvement is scheduling. CloudWatch is complicated when it comes to scheduling. If you want to monitor the component, the configuration is not straightforward. You need good knowledge for something to be added there.
Head of Engineering - Data and Machine Learning at a financial services firm with 51-200 employees
Real User
Top 20
2023-04-13T10:38:32Z
Apr 13, 2023
The dashboard and the UI could improve in Amazon CloudWatch. Additionally, they should focus on visibility inside the servers with AI and machine learning integrations. This would allow users who are using the solution to see what is happening within the system better.
Some of our customers want to use Kubernetes to monitor their CICD flow but Amazon CloudWatch does not support it. We need to use another solution, such as Datadog or Dynatrace has the needed capability. In a future release, the vendor could add automation for quicker integration and improve the visualization similar to other solutions.
The graphical interface has room for improvement. CloudWatch only gives you a breakdown of what's wrong. However, it would be nice if it could automatically remedy the problems it identifies. You should be able to configure it so that when a specific condition arises, it will take a predefined action.
I think something that can be improved are the alerts and alerting mechanism based on no rejects. We want to have it more flexible and that is one of the key things that is required.
What would make Amazon CloudWatch better is if it includes more on-site checks, particularly status checks on the CPU, network input/output, etc. It would also be helpful if there's built-in swap space, disk, and memory monitoring in Amazon CloudWatch because, at the moment, my team has to configure it manually through a shell script. Amazon CloudWatch is a pretty complete tool with many features, so apart from the improvements I mentioned, there isn't anything else I want to change in Amazon CloudWatch.
I found several areas for improvement in Amazon CloudWatch. First is that it's tough to track issues and find out where it's going wrong. The process takes longer. For example, if I get an exception error, I read the logs, search, go to AWS Cloud, then to the groups to find the keyword to determine what's wrong. Another area for improvement in Amazon CloudWatch is that it's slow in terms of log streaming. It requires an entire twenty-four hours for scanning, rather than just one hour. This issue can be solved with Elasticsearch streaming with Kibana, but it requires a lot of development effort and integration with Kibana or Splunk, and this also means I need a separate developer and software technical stack to do the indexing and streaming to Kibana. It's a manual effort that you need to do properly, so log streaming should be improved in Amazon CloudWatch. The AWS support person should also have a better understanding of the logs in Amazon CloudWatch. What I'd like added to the solution is a more advanced search function, particularly one that can tell you more information or special information. Right now, the search function is difficult to use because it only gives you limited data. For example, I got an error message saying that the policy wasn't created. I only know the amount the customer paid for the policy, the mobile number, and the customer name, but if I use those details, the information won't show up on the logs. I need to enter more details, so that's the type of fuzzy matching Amazon CloudWatch won't provide. If this type of search functionality is provided, it will be very helpful for businesses and companies that provide professional services to customers, like ours.
Even though the product works well with most AWS, it is a nightmare to use with Snowflake. Snowflake is a SaaS product hosted on AWS, but using it with CloudWatch still doesn't give us the support we need so we rely on separate monitoring. We have many databases such as MongoDB and SQL Server, RDS, and PostgreSQL. For these, CloudWatch is good but a little basic and additional monitoring tools are required. It's challenging to use one monitoring tool for S3 and another monitoring tool for Snowflake. It would be beneficial for CloudWatch to provide an API interface and some kind of custom configuration because everybody uses APIs now. Suppose Snowflake says we'd get all the same things with MongoDB such as APIs, hookups, or even monitoring. That would allow us to build our own custom solution because that is the biggest limitation of CloudWatch. If you go a bit beyond AWS products even if they're hosted on AWS, CloudWatch doesn't work very well. I'd also like an improved UI because it hasn't significantly improved in a few years and we want to see it at a more granular level. I get my KPIs in a bucket usage for yesterday but I'd like to see them by a particular date and week. We have three buckets rolled by hundreds of people and I want to see use cases for an individual to determine where I need to customize and provide more room. I want aggregation on multiples, not one terameter.
I haven't heard any complaints about the product. It would be nice if they could make it in such a way that we wouldn't have to rely on Datadog as much. We'd like the interface to be as easy as Datadog.
Architect - Database Administration at Mitra Innovation
Real User
Top 5
2022-06-03T16:35:32Z
Jun 3, 2022
We haven't come across any shortcomings. The costs could always be cheaper. I do not know whether or not CloudWatch can be integrated with on-prem services. I would like to see, for example, if it's a hybrid environment, that potential, however, I'm not quite sure whether it's available or not.
I would like to monitor inbound and outbound transfer. I would also like to control the traffic for load balancing. It would be good to see the transfer inbound per EP or per load balancing. This is a useful metric to have another review of your solution. It can also provide information on from where the clients enter and how they consume our data and solution.
An area for improvement that we want to see in Amazon CloudWatch is a more realistic monitoring. It's real-time data stream monitoring we are looking for. Our application is a huge application that will run on AWS. It has a lot of services that are running, so we want to monitor those services, e.g. message review and frontend application in ELB (Elastic Load Balancing). It's not only monitoring that we want to do. We also want to visualize that monitoring data through dashboards. This is the main reason we plan to try Datadog because in Datadog, we can create a dashboard and we can visualize the log data through the dashboard. We are not happy about the dashboards. In Amazon CloudWatch, they can fetch all the logs, but the service is not good at delivering the data into the dashboard, plus there's the lack of real data, e.g. in application performance monitoring. We find this product lacking and this is why we want to look for a new service that can cover our needs. Additional features we would like to see in the future on this product include more API performance features, e.g. application performance monitoring. We also want live dashboards and well-designed workflows. We also want integrative services, e.g. custom logs we can check, as we are not satisfied with what Amazon CloudWatch currently has. We are looking for more competency on these services: dashboards, real-time monitoring, real user monitoring, and application performance monitoring. We also have more and more mobile apps, so mobile app monitoring is also important. These are the key areas that people are looking for, and what we'd like to see on this product in the future.
For monitoring applications or for APM, CloudWatch has some limitations. You cannot monitor application performance from CloudWatch, and you have to go for a third-party tool. A major drawback of CloudWatch is that you cannot create reports. They should add the functionality for creating some reports so that the users can download those reports. Currently, you can see the old data, but you cannot generate reports. So, if some of our customers ask us for monthly or weekly reports, there is a limitation, and we have to go for a third-party tool to generate reports.
The portability of the Datadog is much more flexible for us. The client does not need to have Amazon services for the entire life of the project, unfortunately. They can change. But for Amazon to move over to Google Cloud, for example, that it's very important for the client. They are not investing in a particular single cloud service. The panel should be better. Datalog's is much more visual. The configuration capabilities could be better. We've found it to be quite good on Datalog, for example. They should emulate that.
I think the machine learning aspect of it probably does help because machine learning is not really machine learning. That needs some help. Better reporting is always something needed. That could be an answer to just about anything. But you always want better reporting, better dashboards, things that are just more dynamic and more accessible.
I haven't really thought about how the solution could be improved and I'm not sure what features are lacking. The solution should adjust its pricing. We tend to find the costs for using it are a little high. Right now, in relation to monitoring services, there are too many services and too many metrics per service. I understand that it's per service but some complex acronyms, etc., make it kind of hard to understand the solution sometimes.
Acquisitions Leader at a healthcare company with 10,001+ employees
Real User
2020-02-20T06:38:01Z
Feb 20, 2020
The drill-down aspect on the dashboard of the solution needs improvement. We get a very good high-level overview, but when we drill down, it becomes a little less clear. We have given this feedback to AWS as well and hope they will improve this in the future.
Amazon CloudWatch is used for monitoring, tracking logs, and organizing metrics across AWS services. It detects anomalies, sets dynamic alarms, and automates actions to optimize cloud utilization, troubleshoot, and ensure service availability.
Organizations leverage Amazon CloudWatch for collecting and analyzing logs, triggering alerts, and profiling application performance. It's also employed for monitoring bandwidth, virtual machines, Lambda functions, and Kubernetes clusters. Valuable...
There is room for improvement in setting up custom metrics in CloudWatch. Adding conditional expressions would enhance its functionality.
There is some delay in logging that they need to improve on. While CloudWatch is good, when compared to Dynatrace, there are several areas for improvement. For instance, Dynatrace has better distributed tracing and a feature like back trace, which CloudWatch lacks. In terms of alerts, we use PagerDuty, but composite alarms and similar features need more work.
The integration with third-party tools must be made easier.
CloudWatch doesn’t monitor disk throughput by default. It is part of EC2. If EC2 forwards the logs, then we can do it.
The solution should provide human-readable metrics. Amazon CloudWatch should add custom metrics, like static metrics or any data relevant to our use case.
There is a need for seamless integration with databases, whether they are open-source or proprietary like InfluxDB. Incorporating a straightforward method or a plug-and-play solution for integrating these databases with our systems, facilitating smooth data transfer, and enabling the creation of dashboards for monitoring and analysis would be beneficial.
The solution's pricing is a bit higher.
The technical support must be improved.
Improvement of SSSD logs would be beneficial.
CloudWatch's scalability could be improved.
There is room for improvement in the pricing because they have a premium version, but it's not really a premium version. It's just an enhanced monitoring version, and it can be a bit expensive depending on your usage.
When you set up CloudWatch, you can't even take a lot without checking on them or without going through the whole configuration because we're configuring. It's not a frequent feature you always work on. The integration requires a lot of permissions and the tool delays in providing notifications. Sometimes, receiving a notification after an update takes a long time. So, we prefer using a monitoring tool like New Relic or Grafana. Another area of improvement is scheduling. CloudWatch is complicated when it comes to scheduling. If you want to monitor the component, the configuration is not straightforward. You need good knowledge for something to be added there.
The product should provide more features.
There's a learning curve with Amazon CloudWatch since we have to learn to write the queries to extract the keys and logs.
The dashboard and the UI could improve in Amazon CloudWatch. Additionally, they should focus on visibility inside the servers with AI and machine learning integrations. This would allow users who are using the solution to see what is happening within the system better.
Some of our customers want to use Kubernetes to monitor their CICD flow but Amazon CloudWatch does not support it. We need to use another solution, such as Datadog or Dynatrace has the needed capability. In a future release, the vendor could add automation for quicker integration and improve the visualization similar to other solutions.
It's not an advanced way of monitoring.
The graphical interface has room for improvement. CloudWatch only gives you a breakdown of what's wrong. However, it would be nice if it could automatically remedy the problems it identifies. You should be able to configure it so that when a specific condition arises, it will take a predefined action.
I think something that can be improved are the alerts and alerting mechanism based on no rejects. We want to have it more flexible and that is one of the key things that is required.
What would make Amazon CloudWatch better is if it includes more on-site checks, particularly status checks on the CPU, network input/output, etc. It would also be helpful if there's built-in swap space, disk, and memory monitoring in Amazon CloudWatch because, at the moment, my team has to configure it manually through a shell script. Amazon CloudWatch is a pretty complete tool with many features, so apart from the improvements I mentioned, there isn't anything else I want to change in Amazon CloudWatch.
I found several areas for improvement in Amazon CloudWatch. First is that it's tough to track issues and find out where it's going wrong. The process takes longer. For example, if I get an exception error, I read the logs, search, go to AWS Cloud, then to the groups to find the keyword to determine what's wrong. Another area for improvement in Amazon CloudWatch is that it's slow in terms of log streaming. It requires an entire twenty-four hours for scanning, rather than just one hour. This issue can be solved with Elasticsearch streaming with Kibana, but it requires a lot of development effort and integration with Kibana or Splunk, and this also means I need a separate developer and software technical stack to do the indexing and streaming to Kibana. It's a manual effort that you need to do properly, so log streaming should be improved in Amazon CloudWatch. The AWS support person should also have a better understanding of the logs in Amazon CloudWatch. What I'd like added to the solution is a more advanced search function, particularly one that can tell you more information or special information. Right now, the search function is difficult to use because it only gives you limited data. For example, I got an error message saying that the policy wasn't created. I only know the amount the customer paid for the policy, the mobile number, and the customer name, but if I use those details, the information won't show up on the logs. I need to enter more details, so that's the type of fuzzy matching Amazon CloudWatch won't provide. If this type of search functionality is provided, it will be very helpful for businesses and companies that provide professional services to customers, like ours.
Even though the product works well with most AWS, it is a nightmare to use with Snowflake. Snowflake is a SaaS product hosted on AWS, but using it with CloudWatch still doesn't give us the support we need so we rely on separate monitoring. We have many databases such as MongoDB and SQL Server, RDS, and PostgreSQL. For these, CloudWatch is good but a little basic and additional monitoring tools are required. It's challenging to use one monitoring tool for S3 and another monitoring tool for Snowflake. It would be beneficial for CloudWatch to provide an API interface and some kind of custom configuration because everybody uses APIs now. Suppose Snowflake says we'd get all the same things with MongoDB such as APIs, hookups, or even monitoring. That would allow us to build our own custom solution because that is the biggest limitation of CloudWatch. If you go a bit beyond AWS products even if they're hosted on AWS, CloudWatch doesn't work very well. I'd also like an improved UI because it hasn't significantly improved in a few years and we want to see it at a more granular level. I get my KPIs in a bucket usage for yesterday but I'd like to see them by a particular date and week. We have three buckets rolled by hundreds of people and I want to see use cases for an individual to determine where I need to customize and provide more room. I want aggregation on multiples, not one terameter.
I haven't heard any complaints about the product. It would be nice if they could make it in such a way that we wouldn't have to rely on Datadog as much. We'd like the interface to be as easy as Datadog.
We haven't come across any shortcomings. The costs could always be cheaper. I do not know whether or not CloudWatch can be integrated with on-prem services. I would like to see, for example, if it's a hybrid environment, that potential, however, I'm not quite sure whether it's available or not.
I would like to monitor inbound and outbound transfer. I would also like to control the traffic for load balancing. It would be good to see the transfer inbound per EP or per load balancing. This is a useful metric to have another review of your solution. It can also provide information on from where the clients enter and how they consume our data and solution.
An area for improvement that we want to see in Amazon CloudWatch is a more realistic monitoring. It's real-time data stream monitoring we are looking for. Our application is a huge application that will run on AWS. It has a lot of services that are running, so we want to monitor those services, e.g. message review and frontend application in ELB (Elastic Load Balancing). It's not only monitoring that we want to do. We also want to visualize that monitoring data through dashboards. This is the main reason we plan to try Datadog because in Datadog, we can create a dashboard and we can visualize the log data through the dashboard. We are not happy about the dashboards. In Amazon CloudWatch, they can fetch all the logs, but the service is not good at delivering the data into the dashboard, plus there's the lack of real data, e.g. in application performance monitoring. We find this product lacking and this is why we want to look for a new service that can cover our needs. Additional features we would like to see in the future on this product include more API performance features, e.g. application performance monitoring. We also want live dashboards and well-designed workflows. We also want integrative services, e.g. custom logs we can check, as we are not satisfied with what Amazon CloudWatch currently has. We are looking for more competency on these services: dashboards, real-time monitoring, real user monitoring, and application performance monitoring. We also have more and more mobile apps, so mobile app monitoring is also important. These are the key areas that people are looking for, and what we'd like to see on this product in the future.
For monitoring applications or for APM, CloudWatch has some limitations. You cannot monitor application performance from CloudWatch, and you have to go for a third-party tool. A major drawback of CloudWatch is that you cannot create reports. They should add the functionality for creating some reports so that the users can download those reports. Currently, you can see the old data, but you cannot generate reports. So, if some of our customers ask us for monthly or weekly reports, there is a limitation, and we have to go for a third-party tool to generate reports.
The portability of the Datadog is much more flexible for us. The client does not need to have Amazon services for the entire life of the project, unfortunately. They can change. But for Amazon to move over to Google Cloud, for example, that it's very important for the client. They are not investing in a particular single cloud service. The panel should be better. Datalog's is much more visual. The configuration capabilities could be better. We've found it to be quite good on Datalog, for example. They should emulate that.
I think the machine learning aspect of it probably does help because machine learning is not really machine learning. That needs some help. Better reporting is always something needed. That could be an answer to just about anything. But you always want better reporting, better dashboards, things that are just more dynamic and more accessible.
I haven't really thought about how the solution could be improved and I'm not sure what features are lacking. The solution should adjust its pricing. We tend to find the costs for using it are a little high. Right now, in relation to monitoring services, there are too many services and too many metrics per service. I understand that it's per service but some complex acronyms, etc., make it kind of hard to understand the solution sometimes.
The drill-down aspect on the dashboard of the solution needs improvement. We get a very good high-level overview, but when we drill down, it becomes a little less clear. We have given this feedback to AWS as well and hope they will improve this in the future.