As a SysOps Administrator, another core AWS Service which needs to be monitored is the Elastic Load Balancers you use on the AWS Account for example when you are delivering High Availability services for your web server farm. This article, monitoring and metrics for Elastic Load Balancers looks at some key concepts and hints on what to study for your AWS Certified SysOps Administrator – Associate Exam.
Monitoring Tools
The following are some monitoring tools you can use to manage your Elastic Load Balancers:
- CloudWatch – Elastic Load Balancers can publish metric data to CloudWatch about your load balancers as well as the back-end instances. You can then analyse traffic flow and store statistical data on performance as well as identify issues over a period.
- Elastic Load Balancer Access Logs – The access logs will capture requests made to the load balancers and store them as log files in S3 buckets you specify. Information like date and time of request and source IP as well as latency information and server responses are included in the logs
- CloudTrail Logs – enables you to track requests made to the Elastic Load Balancer APIs by or on behalf of your AWS Account. The information can be used to provide auditing data and determine which requests were made, source IP etc.
CloudWatch Metrics for Classic Load Balancers
Various metrics are available to enable you to analyse your load balancer performance and health. You can also use these metrics to trigger CloudWatch alarms or initiate an action like launching a new instance via an Autoscaling group.
Important Note – Elastic Load Balancers will report metrics to CloudWatch every 60 seconds if there are requests flowing through the load balancer, Elastic Load Balancing measures and sends its metrics in 60-second intervals. It will not report if no requests are flowing through the Load Balancer.
Metrics
- BackendConnectionErrors – Number of connections that were not successfully established between the load balancer and the registered instances. The primary useful value here is Sum
- HealthyHostCount – This is the number of healthy instances registered with your load balancer. An instance is marked as healthy when passes the first health check. If you enable cross-zone load balancing, the number of healthy instances for the Load Balancer Name dimension is calculated across all Availability Zones.
- HTTPCode_Backend_2XX, 3XX, 4XX, 5XX – The number of HTTP response codes generated by registered instances.
- HTTPCode_ELB_4XX – The number of HTTP 4XX client error codes generated by the load balancer. These errors relate to clients’ requests which may be malformed or incomplete
- HTTPCode_ELB_5XX – The metric is reported if there are no healthy instances registered to the load balancer, or if the request rate exceeds the capacity of the instances and has resulted in a spillover
- Latency – The time taken in seconds, after the request leaves the load balancer until the headers of the response are received. Usual symptoms include page load issues
- RequestCount – The number of requests completed or connections made during the specified interval (1 or 5 minutes)
- SpilloverCount – The total number of requests that were rejected because the surge queue is full
- SurgeQueueLength – This is the total number of requests that are pending routeing. The load balancer queues a request if it is unable to establish a connection with a healthy instance in order to route the request and the maximum size of this queue is 1024. Additional requests are rejected when the queue is full
- UnHealthyHostCount – The number of unhealthy instances registered with your load balancer. An instance is considered unhealthy after it exceeds the unhealthy threshold configured for health checks.
Elastic Load Balancer – Access Logs
You can use Elastic Load Balancer Access Logs to collect information about requests sent to your load balancer. Information such request time, client’s IP address, latency, request paths, and server responses are part of the logs.
- Access logging is disabled by default
- Once enabled, Elastic Load Balancing captures the logs and stores them in the Amazon S3 bucket that you specify.
- You can disable access logging at any time.
- Logs can be published at 5 minutes or 60 minutes intervals
- Default publishing of logs is every 60-minute intervals
- Elastic Load Balancers can deliver multiple logs for the same period if you have high traffic, multiple load balancer nodes, and a short log publishing interval.
You can also use Cloud Trail to collect information such as what API call was made, what source IP address was used, who made the call when it was made. CloudTrail captures information about the calls to the Elastic Load Balancing API made by or on behalf of your AWS account.
Elastic Load Balancer – Stickiness
By default, an Elastic Load Balancer will route traffic to an instance independently based on load. However, you can configure an Elastic Load Balancer for session stickiness which is disabled by default. This is also known as session affinity which enables the load balancer to associate a user’s session to a specific instance. This ensures that all requests from the user during the session are sent to the same instance and is particularly useful if an instance needs to keep sessions live with an application on a specific instance so that transactions can have sufficient time to complete. Often used when applications store session data rather than have cookies on client side storing the data for the session.
You can manage the sticky sessions by configuring how long your load balancer should consistently route the user’s request to the same instance. Applications that use their own session cookie require you to configure Elastic Load Balancing so that the session cookie follows the duration specified by the application’s session cookie. If your application does not have its own session cookie, then you can configure Elastic Load Balancing to create a session cookie by specifying your own stickiness duration.
There are two types of sticky sessions:
- Duration Based Sticky Session – Elastic Load Balancer first checks if there is a cookie for a request from a user. If there is a cookie, it sends the user to the instance specified in the cookie. If there is no cookie, the ELB treats this as a new request and based on its load balancing algorithm forwards the user to a particular instance. At the same time, it generates a cookie and includes it in the response to the request so that the user is now bound to a particular instance for the session. The stickiness policy configuration dictates when the cookie will expire and after expiry, the session is no longer sticky.Note that in the event of an instance becoming unhealthy, the load balancer stops routeing requests to that instance, and chooses a new healthy instance. The request is then routed to the new instance and the session is no longer sticky.
- Application Based Sticky Sessions – With this configuration, the Elastic Load Balancer still configures a session cookie to bind the user’s request to a particular instance, but the duration of the cookie is determined by an application cookie specified in the policy configuration. Note that with this setup, the ELB will only insert a stickiness cookie if the application also includes an application cookie in the response to a request. When configuring this type of stickiness, you need to provide the name of the application-generated cookie. If the application cookie is explicitly removed or expires, the session stops being sticky until a new application cookie is issued.
Note that in the event of an instance becoming unhealthy, the load balancer stops routeing request to that instance and choose a new healthy instance. The load balancer treats the session as now “stuck” to the new healthy instance and will continue to routeing requests to it even if the failed instance comes back.
