Our approach resulted in a doubling of our log ingestion at an ingest cost increase of only 10%, saving us around $1 million.”
Iwan Eising
Team Lead of Service Reliability Architecture
BY OBSERVABILITY USE CASE
BY SECURITY USE CASE
BY INITIATIVE
BY COMPETITION
March 28, 2018
Configuring health checks for the AWS Elastic Load Balancer (ELB) is an important step to ensure that your cloud applications run smoothly.
In this article, we’re going to look specifically at how to configure the health checks on an ELB.
In addition, we’re going to look at what factors you should consider when creating and configuring efficient and useful health checks for your services. Our goal is to ensure we have an environment which operates efficiently and minimizes downtime and degraded performance due to increased load.
Machine data holds hidden secrets that deliver true insights about the operational health of your AWS infrastructure. Learn more about operational visibility from AWS today!
Contents
Why the Sumo Logic App for AWS ELB?
The ELB Health Check is used for AWS monitoring to determine the availability of registered EC2 instances and their readiness to receive traffic. Any downstream server that does not return a healthy status is considered unavailable and will not have any traffic routed to it.
The ELB Health Check is configured with a protocol and port number to call on the target instances. A healthy EC2 instance is one that issues a response to a health check call with a 200 response code. Healthy machines are given a balanced portion of the traffic being directed through the ELB.
Instances that return a status code which is not within the 200 range or which time out are designated as being unhealthy and will not receive traffic from the ELB. Health Checks are conducted with all downstream services on a period basis, allowing unhealthy instances to recover, and healthy instances to confirm their capacity to continue receiving traffic.
Before we delve into how to configure your ELB health check, let’s consider all of the options which are available for configuration.
You have the option to choose the protocol, port and path you would like to target for the health check. Supported protocols include TCP, HTTP, HTTPS and SSL, and you can use any port in the range of 1 to 65535. (The default for a web application would be HTTP on port 80 and a path of /index.html.)
The response timeout is measured in seconds and must fall in the range of two to 60 seconds, with a default of five seconds. Instances are struck with a failed health check if they don’t respond within this period.
A health check is conducted every 30 seconds by default. The period between each check can be shortened to every five seconds or extended up to 300 seconds/5 minutes between calls.
Threshold counts in place for the number of consecutive health checks which an instance must pass or fail to be marked as healthy or unhealthy respectively. Two successive failures will mark an instance as unhealthy. Ten consecutive passing health checks are required before an unhealthy instance will be marked as healthy again. Both thresholds support a range of between two and 10 successive health checks of the same state.
The health check is configured for an ELB when you first create your ELB. This process is completed through the AWS console from the Load Balancer Section of the EC2 home page. (Since we’re only considering health check configuration in this article, we’ll skip configuration of the ELB itself, but AWS provides excellent instructions on how to do this in the ELB documentation.)
Step 4 of the configuration deals directly with the health check for the instances registered with the ELB.
1 .Configuration of the ELB Health Check
In most cases, the default values will work adequately. If you are exposing an API through the ELB, or you have a health check running on a different port, you have the option to select a different protocol, port, and path for that health check.
The timeout value, health check interval, and threshold can be adjusted to match the needs of your application, and all can be edited at a later time to better tune the health check for optimal performance.
Once you have created the ELB, you can edit the health check values. You can do this by selecting the ELB on the ELB dashboard and then clicking on the Health Check tab below. Clicking on the Edit Health Check button will open a modal window for you to edit the configuration options.
2. The ELB Dashboard Showing the Health Check Tab and Modal for Editing Values
You also have the option of creating and configuring the ELB through the AWS CLI if you find this approach more natural or faster than logging in to the AWS Console.
To create a new ELB with a name of TestELB, using the sg-86545 security group and supporting subnets subnet-000111222 and subnet-333444555, enter the following command.
Once you have your ELB, you can configure the health check with a command similar to that below. This command can be used to set the initial values or to update the ELB with a revised configuration.
Any experienced software engineer will know that applications seldom function independently of other services. I’m ashamed to admit that in the past, I’ve added health check endpoints to my web services which accept a request and immediately respond with an HTTP status of 200. This approach provides for a fast health check, but the results are worth very little in most real-world scenarios!
Why? Because if your application depends on a database, SQS queue, or another service vital to its functionality, you need to ensure that you include health checks for these components when determining the health of your service. At the same time, you’ll want to strike a balance between a highly performant, but essentially worthless health check endpoint and a slower, but more thorough check of the health of your service or application. Even healthy services will fail a health check if they fail to respond before the call times out.
Reduce downtime and move from reactive to proactive monitoring.
Build, run, and secure modern applications and cloud infrastructures.
Start free trial
Mike Mackrory is a Global citizen who has settled down in the Pacific Northwest — for now. By day he works as a Lead Engineer on a DevOps team, and by night, he writes and tinkers with other technology projects. When he's not tapping on the keys, he can be found hiking, fishing and exploring both the urban and rural landscape with his kids. Always happy to help out another developer, he has a definite preference for helping those who bring gifts of gourmet donuts, craft beer and/or single-malt Scotch.
More posts by Mike Mackrory.
No credit card required. Up and running in minutes.
More than 2,100 enterprises around the world rely on Sumo Logic to build, run, and secure their modern applications and cloud infrastructures.
