Basic health reporting
This topic explains the functionality offered by Elastic Beanstalk basic health.
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, and is displayed on the environment overview page of the Elastic Beanstalk console. It's also available from the DescribeEnvironments API and by calling eb status with the EB CLI.
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.
Topics
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:
Color | Description |
---|---|
Grey |
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 checks
In a load-balanced environment, Elastic Load Balancing sends a request to each instance in an environment every 10 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 check.
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 User Guide.
Note
Configuring 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 Amazon EC2 Auto Scaling unless you configure Amazon EC2 Auto Scaling to use the Elastic Load Balancing health check as a basis for replacing instances. To configure Amazon EC2 Auto Scaling to replace instances that fail an Elastic Load Balancing health check, see Auto Scaling health check setting.
Single instance and worker tier environment health checks
In a single instance or worker tier 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 these environment types.
For more information on Amazon EC2 instance status checks, see Monitoring Instances with Status Checks in the Amazon EC2 User Guide.
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 Scaling group 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:
Namespace | Topic |
---|---|
AWS::ElasticLoadBalancing::LoadBalancer | Elastic Load Balancing Metrics and Resources |
AWS::AutoScaling::AutoScalingGroup | Amazon Elastic Compute Cloud Metrics and Resources |
AWS::SQS::Queue | Amazon SQS Metrics and Resources |
AWS::RDS::DBInstance | Amazon 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, the environment's instance profile must have
permission to call cloudwatch:PutMetricData
. This permission is included in the
default instance profile. For more information, see Managing Elastic Beanstalk instance profiles.