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!
What is 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:
- Application Load Balancer for HTTP workloads like web servers.
- Gateway Load Balancer for custom servers on EC2 like firewalls or packet inspectors
- Network Load Balancer for TCP and UDP workloads like a game or video servers.
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.
Why Monitor Elastic Load Balancing?
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.
What to Monitor in Elastic Load Balancing?
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.
Consumed Load Balancer Capacity Units
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.
How to Monitor Elastic Load Balancing?
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!
Monitoring with Dashbird
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.
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.