All-in-one serverless DevOps platform.
Full-stack visibility across the entire stack.
Detect and resolve incidents in record time.
Conform to industry best practices.
In the 21st century, it’s quite easy to manipulate machines and computers. Our worries are no longer if something is doable, but if something can be perfected. Therefore, we mostly search for new ideas and ways to make our work impeccable. For example, if you’re using a particular software and you realize that the software is excellent, but it could be better in some ways that would allow you to work even faster, you’ll explore the alternatives. There are all kinds to choose from, and you will search for the one that is most suitable for your own needs. Every one of them has some perks of their own, and in others, you’ll notice some faults.
In this article, we’ll make a brief introduction, and we’ll also talk about the differences between CloudWatch alerts vs. Dashbird alerts. Which one is better and why?
AWS CloudWatch is built for system operators, site reliability engineers (SRE), IT managers, and developers. CloudWatch allows you to monitor your applications via data access and insights it provides. It can also recognize, understand and respond to all changes happening throughout the entire system.
CloudWatch is also collecting monitoring and operational data through metrics, events, and logs which further provides you with a unique view over the AWS resources, services, and apps that run on AWS, as well as in the localized servers. CloudWatch enables you to set alarms (or alerts), troubleshoot for issues, and discover the insights for application optimization which will ensure that the application runs smooth.
A CloudWatch alert (a.k.a. alarm) can watch over a single CloudWatch metric or even a result of math expression found in CloudWatch metrics. Alerts will perform single or multiple actions based on the value of metric or expression which is relative to a threshold over a number of time periods. Adding alarms to AWS CloudWatch dashboard is enabled and that way you’ll be able to monitor them visually. There are three alarm states:
When creating an alarm, you are able to specify three settings which will allow CloudWatch to evaluate when to change the alarm state:
There are a lot of features that apply to all AWS CloudWatch alarms, and we’ll go through some of them. For example, the number of evaluation periods for an alarm if multiplied by the length of every evaluation period can’t surpass the one-day limit. Another feature worth mentioning is that ASCII characters must be included in alarm naming. You are also able to create 5,000 alarms within every region per a single AWS account.
CloudWatch gathers basic metrics, which further allows you to monitor how the entire system performs. The collected metrics for Lambda functions are latency, invocations, errors, and concurrency. Since the chances of you checking the metrics precisely at the same time when something goes wrong are pretty slim, it would be wise to configure alarms upfront (more on this and best practices below). Do this in case an unexpected event meets a condition or threshold so the alarm could notify you in time.
You should first configure a CloudWatch metric alarm to trigger an SNS topic, but only if the predefined condition is fully met. The SNS trigger will then invoke a Lambda function to take action. This action will send notifications so you can further investigate the issue.
Can you recognize the optimal time to configure a metric alarm? The answer depends on whether you’d like to receive alerts only in cases that require your immediate attention or not. Even if you set them up to alert you often, responding to each and every alert is not feasible. It means that it won’t be long before you miss a crucial alert, which is bound to happen either because of the noise or because you began ignoring alerts entirely.
Try to understand all of it this way:
In these cases, you’d probably want to know if your Lambda is reaching a concurrency limit (account-wide). All these settings are completely individual for each application, and it usually takes some time and iterations before you can get it to an acceptable level.
Another thing you should think about is configuring naturally preventive alerts. These alerts will trigger even when nothing has failed yet, but it might happen soon. A good example will be if a Lambda function is close to a timeout or even closer to fill its memory capacity – remember that CloudWatch attains metrics for invocation counts, latency, memory usage, and failures by default.
If you set the alarm on a high-resolution metric, you’re allowed to specify a high-resolution alarm in specific time groups (10 or 30 seconds). Moreover, you can set up a standard 60-second alarm multiple times. It’s also essential to know that high-resolution alarms are charged at a higher rate so be sure to do a cost analysis if that could be a potential issue.
CloudWatch alarms have numerous features, and the ones listed below are common and apply to all alarms:
Dashbird’s instant alerting system will notify you if any issue shows up within any part of your application. Issues such as crashes, cold starts, runtime errors, timeouts, configuration errors, and early exits. Its system offers messages and realistic logs that humans can easily read and understand, which saves you and your company meaningful debugging time. Dashbird monitors your application and is able to detect all kinds of errors in various runtime environments.
The Events page does everything an observability tool should – showcase all errors occurring within your system. With Dashbird, you can customize which events to track and how you want to get notified. Everything mentioned above works for programming languages supported by AWS Lambda, including Node.js, Python, Java, and C#.
All the required data to successfully go through troubleshooting events and resolve any app issues are entirely at your disposal. A human-friendly interface will present you with any previous occurrences, stack traces, etc. Logs and trends for every error or problem are also available. You can use a “more info” button for every single error you face, and that way, you’ll see the error page with all the needed info for debugging the current issue.
To configure an alert policy, simply visit Events from the left navigation menu and click on the Settings tab on the Events panel. From here, click on Alarms and click + ADD:
Dashbird gives you complete control over Alarms as it allows you to choose which error reports you should receive. You’re required to set and configure the Alarms rules. That way, you’re adding a new policy to the list, and from there, you can start configuring how you want to be notified of Alarms.
Defining Alarms for any ‘error overall functions’ is possible, but you can also set the system to alert you when a specific microservice or function experiences invocation timeouts.
Proactive alerts are another one of Dashbird’s features. You could set up an email notification system or seamlessly integrate it with Slack. We also support SNS and webhooks.
All policies require at least one alert condition along with one notification channel. An alert state consists of different functions and error conditions, while a notification channel can either be an email address or even Slack.
Consider alerting as an ongoing process. Therefore, we at Dashbird recommend you to test different policies. These are some basic principles and suggestions on how to handle alerts when they emerge:
Both CloudWatch and Dashbird have their pros and cons, and we’ll wrap up here after mentioning a few.
While Cloudwatch is mostly an excellent choice for users who are already inside the AWS ecosystem, it’s not all that great for the ones who aren’t, and they should find a simpler solution. The alerting options for CloudWatch are not as boundless since they’re available with third-party services.
Moreover, CloudWatch doesn’t offer pre-configured alerts.
It would be best if you create custom alerts by yourself, which means you must be very familiar with how everything works in order to create them properly. On the other hand, Dashbird’s alert notification system is automated and instant, which undoubtedly provides you comfort and ease if something happens within your application.
During the past three years, we’ve heavily invested in the new Dashbird app interface and building the next stages of our platform. We’ve expanded our offer, and it now includes services like API Gateway, Step-Functions, DynamoDB, Kinesis, ECS, and SQS, and many more to come soon.
See how you can set up your own alarms by signing up.
Today we are excited to announce scheduled searches – a new feature on Dashbird that allows you to track any log event across your stack, turn it into time-series metric and also configure alert notifications based on it.
One of the most vital aspects to monitor is the metrics. You should know how your cluster performs and if it can keep up with the traffic. Learn more about monitoring Amazon OpenSearch Service.
Dashbird recently added support for ELB, so now you can keep track of your load balancers in one central place. It comes with all the information you expect from AWS monitoring services and more!
Dashbird was born out of our own need for an enhanced serverless debugging and monitoring tool, and we take pride in being developers.
Dashbird gives us a simple and easy to use tool to have peace of mind and know that all of our Serverless functions are running correctly. We are instantly aware now if there’s a problem. We love the fact that we have enough information in the Slack notification itself to take appropriate action immediately and know exactly where the issue occurred.
Thanks to Dashbird the time to discover the occurrence of an issue reduced from 2-4 hours to a matter of seconds or minutes. It also means that hundreds of dollars are saved every month.
Great onboarding: it takes just a couple of minutes to connect an AWS account to an organization in Dashbird. The UI is clean and gives a good overview of what is happening with the Lambdas and API Gateways in the account.
I mean, it is just extremely time-saving. It’s so efficient! I don’t think it’s an exaggeration or dramatic to say that Dashbird has been a lifesaver for us.
Dashbird provides an easier interface to monitor and debug problems with our Lambdas. Relevant logs are simple to find and view. Dashbird’s support has been good, and they take product suggestions with grace.
Great UI. Easy to navigate through CloudWatch logs. Simple setup.
Dashbird helped us refine the size of our Lambdas, resulting in significantly reduced costs. We have Dashbird alert us in seconds via email when any of our functions behaves abnormally. Their app immediately makes the cause and severity of errors obvious.
End-to-end observability and real-time error tracking for AWS applications.