AWS Elastic Load Balancing (ELB) dynamically distributes incoming application traffic across multiple EC2 instances and scales resources to meet traffic requirements. Elastic Load Balancing helps optimize the performance of various web and mobile applications by identifying failing EC2 instances before they affect the end-user experience.
Why it’s important to monitor AWS ELB
Various enterprises employ ELB to make their applications highly scalable and available. However, issues in ELB can hinder business-critical operations in the application and can cause the application to go down, resulting in drop in revenue, customer satisfaction, and trust in your brand. It’s essential to proactively monitor your ELB’s performance to detect and resolve potential issues that might occur in your load balancer.
Some common problems encountered in ELB are:
-
Failed EC2 instances
-
Latency
-
Network/connection errors
Tracking load balancer performance in real time helps you easily detect and manage these problems. Applications Manager offers proactive AWS ELB monitoring that helps identify issues in AWS Elastic Application Load Balancer and Network Load Balancer, and offers automated corrective actions to resolve them.
Applications Manager helps you set up thresholds for important AWS Elastic load Balancer metrics and notifies you of breaches by triggering an alarm. For example, an alert on an increased load of an EC2 instance can give you a heads-up to provision your resources appropriately.
In this blog, we’ll take a look at the important metrics that need to be taken into account when monitoring AWS Elastic Load Balancing services.
Latency
It is the single most important metric that gives you overall insight about how well your application is performing. Latency is the time elapsed, in seconds, between when the request leaves the load balancer and when a response from the target/backend instance is received.
Applications Manager tracks the average latency for your applications. If this value is high, you may have to analyze what’s causing the backend instances to give delayed responses. Most likely, it’s a problem in the network, a poor configuration, or an overloaded instance. You can then analyze these issues, and fix them to improve the responsiveness of the application.
Healthy and unhealthy hosts
AWS Elastic load balancers have various target systems/hosts that service the incoming requests. It is important to keep an eye on the healthy and unhealthy hosts count, as having more healthy instances ensures better performance of your applications.
Applications Manager monitors the Healthy Host Count and UnHealthy Host Count. This helps you to ensure that an adequate number of healthy hosts are always available to handle all incoming requests without missing them.
Connections and requests
Elastic load balancers contain listeners that check for new connections. There are three types of connections in a load balancer:
- Active Connections: The total number of concurrent Transmission Control Protocol (TCP) connections active between clients and the load balancer, and between the load balancer and the targets.
- Rejected Connections: The number of connections that were rejected because the load balancer had reached its maximum number of connections.
- New Connections: The total number of new TCP connections established from clients to the load balancer, and from the load balancer to targets.
Applications Manager monitors the Active Connections, Rejected Connections, and New Connections count to help you understand the load on the balancer.
Applications Manager also monitors the Total Requests and Requests/Min. It is the number of requests ELB received and sent to the registered EC2 instances during the selected time period (sum). This helps you to assess the amount of traffic your load balancer is handling. If the number of requests keeps fluctuating, you may have to check for DNS issues. This can also help you provision your instances backing your load balancer.
Errors
There are various types of errors that can occur in ELB. Applications Manager’s AWS Elastic load balancer monitoring capabilities include monitoring the following types of errors:
-
Connection Errors
These are errors that occur during the establishment of a connection. Applications Manager monitors three different connection error metrics: Client TLS Negotiation Errors, Target TLS Negotiation Errors, and Target Connection Errors. This information allows you to gain visibility into the number of client-initiated TLS connections that were not established with the load balancer and the load balancer-initiated TLS connections that were not established with the target.
-
Load Balancer Errors
These are errors that originate from the clients and servers in ELB.
Applications Manager monitors the ELB Client Errors and ELB Server Errors to give you a heads-up about problems in the clients and servers that you can resolve before they affect the user experience of your applications.
-
Error Codes:
HTTP response status codes indicate whether a specific HTTP request has been successfully completed. In ELB, different types of error codes can be generated, depending on the type of problem. Monitoring and tracking these error codes helps you identify problematic areas that degrade the performance of your system.
Applications Manager tracks Target HTTP 5XX, 4XX, 3XX, and 2XX errors along with their respective target groups and other parameters such as the health of the system.
All these errors have their own meanings and probable causes. HTTP 5XX errors indicate the number of requests that could not be managed properly, while HTTP 4XX errors indicate the number of incorrect requests that were sent to the ELB. Each class of these errors can have several errors that can be caused by numerous reasons.
For example, a 502 error indicates a bad gateway, while a 504 error indicates a gateway timeout. You can gain visibility into the efficiency of your servers and backend instances by analyzing these errors and thereby avoiding unnecessary outages.
Target Groups
ELB has Target Groups that route requests to one or more registered targets. Upon creating a listener rule, you can specify a target group and conditions. When a rule condition is met, traffic is forwarded to the corresponding target group. You can create different target groups for different types of requests.
Applications Manager monitors all the targets and the associated target groups along with their statuses. This helps you not only identify which targets are unhealthy, but also why, helping you fix the issues before they affect the performance of your application.
You can use Applications Manager to monitor Amazon EC2 instances, RDS instances, EBS volumes, SNS, S3, DynamoDB, AuroraDB, and AWS Billing services alongside ELB. Applications Manager can monitor over 130 types of applications including on-premises, virtualization, containers, and cloud all from a single console, allowing you to gain full visibility into your stack.
If you’re new to Applications Manager, get started with a free, 30-day trial.
