Elastic Beanstalk
Developer Guide (API Version 2010-12-01)
Did this page help you?  Yes | No |  Tell us about it...
« PreviousNext »
View the PDF for this guide.Go to the AWS Discussion Forum for this product.Go to the Kindle Store to download this guide in Kindle format.

Basic Health Reporting

AWS Elastic Beanstalk uses information from multiple sources to determine if your environment is available and processing requests from the Internet. An environment's health is represented by one of four colors, which is displayed in the environment dashboard, and is also available from the DescribeEnvironments API and by calling eb status with the EB CLI.

Prior to version 2 Linux platform configurations, the only health reporting system was basic health. The basic health reporting system provides information about the health of instances in an Elastic Beanstalk environment based on health checks performed by Elastic Load Balancing for load balanced environments or Amazon Elastic Compute Cloud for single instance environments.

In addition to checking the health of your EC2 instances, Elastic Beanstalk also monitors the other resources in your environment and reports missing or incorrectly configured resources that can cause your environment to become unavailable to users.

Metrics gathered by the resources in your environment is published to Amazon CloudWatch in five minute intervals. This includes operating system metrics from EC2, request metrics from Elastic Load Balancing. You can view graphs based on these CloudWatch metrics on the Monitoring page of the environment console. For basic health, these metrics are not used to determine an environment's health.

Health Colors

Elastic Beanstalk reports the health of a web server environment depending on how the application running in it responds to the health check. Elastic Beanstalk uses one of four colors to describe status, as shown in the following table:

ColorDescription

Gray

Your environment is being updated.

Green

Your environment has passed the most recent health check. At least one instance in your environment is available and taking requests.

Yellow

Your environment has failed one or more health checks. Some requests to your environment are failing.

Red

Your environment has failed three or more health checks, or an environment resource has become unavailable. Requests are consistently failing.

These descriptions only apply to environments using basic health reporting. See Health Colors and Statuses for details related to enhanced health.

Elastic Load Balancing Health Check

In a load balanced environment, Elastic Load Balancing sends a request to each instance in an environment every 30 seconds to confirm that instances are healthy. By default, the load balancer is configured to open a TCP connection on port 80. If the instance acknowledges the connection, it is considered healthy.

You can choose to override this setting by specifying an existing resource in your application. If you specify a path, such as /health, the health check URL is set to http:80/health. The health check URL should be set to a path that is always served by your application. If it is set to a static page that is served or cached by the web server in front of your application, health checks will not reveal issues with the application server or web container. For instructions on modifying your health check URL, see Health Checks.

If a health check URL is configured, Elastic Load Balancing expects a GET request that it sends to return a response of 200 OK. The application fails the health check if it fails to respond within 5 seconds or if it responds with any other HTTP status code. After 5 consecutive health check failures, Elastic Load Balancing takes the instance out of service.

For more information about Elastic Load Balancing health checks, see Health Check in the Elastic Load Balancing Developer Guide.

Note

Congfiguring a health check URL does not change the health check behavior of an environment's Auto Scaling group. An unhealthy instance is removed from the load balancer, but is not automatically replaced by Auto Scaling unless you configure Auto Scaling to use the Elastic Load Balancing health check as a basis for replacing instances. To configure Auto Scaling to replace instances that fail an Elastic Load Balancing health check, see Auto Scaling Health Check Setting.

Single Instance Environment Health Check

In a single instance environment, Elastic Beanstalk determines the instance's health by monitoring its Amazon EC2 instance status. Elastic Load Balancing health settings, including HTTP health check URLs, cannot be used in a single instance environment.

For more information on Amazon EC2 instance status checks, see Monitoring Instances with Status Checks in the Amazon EC2 User Guide for Linux Instances.

Additional Checks

In addition to Elastic Load Balancing health checks, Elastic Beanstalk monitors resources in your environment and changes health status to red if they fail to deploy, are not configured correctly, or become unavailable. These checks confirm that:

  • The environment's Auto Scalinggroup is available and has a minimum of at least one instance.

  • The environment's security group is available and is configured to allow incoming traffic on port 80.

  • The environment CNAME exists and is pointing to the right load balancer.

  • In a worker environment, the Amazon Simple Queue Service (Amazon SQS) queue is being polled at least once every three minutes.

Amazon CloudWatch Metrics

With basic health reporting, the Elastic Beanstalk service does not publish any metrics to Amazon CloudWatch. The CloudWatch metrics used to produce graphs on the Monitoring page of the environment console are published by the resources in your environment.

For example, EC2 publishes the following metrics for the instances in your environment's Auto Scaling group:

CPUUtilization
Percentage of compute units currently in use.
DiskReadBytes, DiskReadOps, DiskWriteBytes, DiskWriteOps
Number of bytes read and written, and number of read and write operations.
NetworkIn, NetworkOut
Number of bytes sent and received.

Elastic Load Balancing publishes the following metrics for your environment's load balancer:

BackendConnectionErrors
Number of connection failures between the load balancer and environment instances.
HTTPCode_Backend_2XX, HTTPCode_Backend_4XX
Number of successful (2XX) and client error (4XX) response codes generated by instances in your environment.
Latency
Number of seconds between when the load balancer relays a request to an instance and when the response is received.
RequestCount
Number of completed requests.

These lists are not comprehensive. For a full list of metrics that can be reported for these resources, see the following topics in the Amazon CloudWatch Developer Guide:

Metrics

NamespaceTopic
AWS::ElasticLoadBalancing::LoadBalancerElastic Load Balancing Metrics and Resources
AWS::AutoScaling::AutoScalingGroupAmazon Elastic Compute Cloud Metrics and Resources
AWS::SQS::QueueAmazon SQS Metrics and Resources
AWS::RDS::DBInstanceAmazon RDS Dimensions and Metrics


Worker Environment Health Metric

For worker environments only, the SQS daemon publishes a custom metric for environment health to CloudWatch, where a value of 1 is Green. You can review the CloudWatch health metric data in your account using the ElasticBeanstalk/SQSD namespace. The metric dimension is EnvironmentName, and the metric name is Health. All instances publish their metrics to the same namespace.

To enable the daemon to publish metrics, you must grant the appropriate permissions to the environment's instance profile. For more information, see Granting IAM Role Permissions for Worker Environment Tiers.

Troubleshooting Health Issues

If the health of your environment changes to red, try the following:

  • Review recent environment events. Messages from Elastic Beanstalk about deployment, load, and configuration issues often appear here.

  • Pull logs to view recent log file entries. Web server logs contain information about incoming requests and errors.

  • Connect to an instance and check system resources.

  • Roll back to a previous, working version of the application.

  • Undo recent configuration changes or restore a saved configuration.

  • Deploy a new environment. If it appears healthy, perform a CNAME swap to route traffic to the new environment and continue to debug the old one.