Monitoring platform for keeping systems up and running at all times.
Full stack visibility across the entire stack.
Detect and resolve any incident in record time.
Conform to industry best practices.
When building systems that need to scale above a certain number of users, we usually can’t stay on one machine. This is where cloud providers like AWS usually come into play. They allow us to rent VMs or containers for small intervals. This way, we can start a few different machines when more traffic hits, and when it goes down later, we can simply turn off our extra capacity and save money.
The question is, how does all this traffic get to our new machines?
AWS Elastic Load Balancing!
Elastic Load Balancing, or short ELB, is a set of services provided by AWS. They give you one address via IP or DNS, to which you can direct all your traffic. They’re proxy servers that use algorithms or measurements to decide which downstream service should handle the traffic.
For example, a load balancer could send the first request to the first server, the second to the second, and so on. Then when it sends a request to all available servers, it starts from the beginning.
ELB comes with three kinds of load balancing services:
There is a fourth kind, called Classic Load Balancer, but it’s only used for EC2 servers inside classic (pre-VPC) networks. If you don’t have legacy systems on AWS, you won’t need it.
This article will discuss monitoring Application Load Balancers.
As we learned before, load balancers manage the traffic between multiple servers. This makes them a critical part of your infrastructure. If one is overwhelmed, misconfigured, or crashes, your users can’t access the systems it’s sending traffic to.
In the end, a load balancer is just one or more servers so that it can get overwhelmed like any other system in your architecture. The modern ones from AWS aren’t too susceptible to such problems, but it’s always important to look out.
The same is valid for the configuration. You have to configure it just like any other service; if you do it wrong, you might pay more than you want or make your architecture vulnerable to the outside.
And finally, like any other service, a load balancer can crash. AWS might have a good track record for service uptime, but they aren’t perfect. If your load balancer goes down, you want to get notified as soon as possible.
So, while load balancers don’t execute business logic and are more or less generic support services inside your architecture, you still need to know how they perform. Otherwise, your business could be at risk.
Since a load balancer is a proxy server installed on a VM in the cloud, you can monitor everything you could watch in a generic VM. Starting from such low-level metrics doesn’t yield easily digestible and actionable information. So, let’s look at more focused metrics.
The most basic metric is requests in a specific period. It gives you a coarse view of a load balancer, how much is happening, and if issues are occurring.
If things go wrong, you want to know how often an error transpired and the related error code. If you only get 4XX errors once in a while, chances are good your services aren’t to blame, but some fluctuations on your user’s clients. If you get regular 5XX, you might have to look deeper into your downstream services to find out if they are misconfigured or if you need to provide them with more potent hardware.
Connections tell you how many clients are connected to your ALB at any time. They give you an idea of how many users are active simultaneously. If you get connection spikes at specific times of the day or week, you might want to provision additional instances in those periods.
AWS bills you by Load Balancer Capacity Units (LCUs), an aggregate metric used to calculate how much you used your load balancer. It consists of new connections per second, active connections per minute, processed bytes per hour, and rule evaluations per second.
Since this more or less complicated aggregate is what will end up on your monthly bill, you want to have an eye on this without manually calculating it.
AWS offers several ways to monitor your ALB. They include CloudWatch Metrics, request tracing, and CloudTrail Logs.
CloudWatch has a technical focus. It allows you to check how your endpoints are performing, if some downstream services can’t keep up, or if there are errors. It’s all about finding answers to a developer’s questions when trying to improve service.
CloudTrail is about resource access. It will tell you who accessed what and when. For lawsuits, it can help prove someone accessed some information. CloudTrail can help you with post mortems. When things go wrong, you need to reconstruct what happened.
Request tracing is helpful to see what services your requests used. In serverless architectures, you’ll have dozens of services, and it can be hard to keep up with their interactions. The trace created by X-Ray will give you a step-by-step view of all points in your architecture touched by requests.
These monitoring services give you a complete view over your serverless system in the cloud, but as you can imagine, looking at all these different places to knit together what’s going on can become quite cumbersome, especially if you have to do it regularly. Also, services like CloudWatch aren’t exactly known for their excellent UX.
This is where Dashbird comes into play!
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!
With Dashbird’s Well-Architected Insights, you get helpful notifications about your deployed services. This includes information about misconfigurations and tips to optimize your deployments to save money, improve reliability, and secure your systems in the cloud.
Dashbird also reports consumed LCUs so that you won’t be surprised by an enormous bill at the end of the month.
Dashbird helps you monitor serverless applications at any scale
Load balancers are the entry point to your cloud services, so it’s essential to monitor them all the time; otherwise, you can’t be sure what’s going in and out of your systems.
But they are also services of their own, so they can have issues, and you have to pay for them, so you shouldn’t treat them like an implicit link between your clients and your services, but ensure that they are configured correctly and don’t cost you more than required.
Application load balancers can be an excellent alternative to API Gateways if you have minimal feature requirements. So, it’s terrific news that Dashbird now provides monitoring out-of-the-box for all ELB-related services.
Today we are announcing a new, updated pricing model and the end of free tier for Dashbird.
In this article, we’re covering 4 tips for AWS Lambda optimization for production. Covering error handling, memory provisioning, monitoring, performance, and more.
In this article we’ll go through the ins and outs of AWS Lambda pricing model, how it works, what additional charges you might be looking at and what’s in the fine print.
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.