As web applications scale, the risk of returning a 500 Internal Server Error also increases. Developers usually tend to monitor such problems by occasional spot checks of websites after a user has tweeted a problem with accessing a page, or by monitoring load balancer metrics to determine if there is an issue.
AWS Elastic Beanstalk has now incorporated a new application health monitoring tool to automatically detect instances of errors (such as 500 internal server errors), created new workflows that ensure new deployments pass health checks, and increased granularity of reporting (from three values of health status to seven).
For those new to AWS Beanstalk, here’s a brief summary of what it offers. Beanstalk is an abstraction on top of the AWS infrastrucure. Stackshare, has a summary of Beanstalk’s features. The AWS service uses familiar software stacks such as the Apache HTTP Server for Node.js, PHP and Python, Passenger for Ruby, IIS 7.5 for .NET, and Apache Tomcat for Java. Docker also runs on Beanstalk. It is comparable to several services but its distinguished by how it configures with the AWS infrastructure. Here is how Stackshare sees the landscape:
At the core of the new feature is an automatic health monitoring process that is displayed in the AWS Management Console dashboard. For this, Elastic Beanstalk monitors the EC2 and ELB statuses alongside application and proxy processes, and tracks “essential metrics” like CPU, memory, disk space.
These datapoints are then run through a set of AWS Management Console business rules to detect anomalies and flag them in the application manager’s dashboard showing the error rate. For example, a yellow warning indicates 1 out of 5 service instances are impaired. A more detailed coding system for rating application health has been released as part of the new AWS Elastic Beanstalk feature.
Users can monitor the new health reports via the AWS Management Console or directly through the Elastic Beanstalk Command Line Interface.
The introduction of the feature is a further building block in reaching the real-time, automated bar for web-scale applications. In Amazon’s feature announcement, the fact that this means application health status is now in “near real-time” (that is, monitored every ten seconds rather than every minute) is a recognition of the demand from both application developers, but more importantly an application’s users. As web applications scale, there becomes increasing pressure for them to be stable and available in any given moment. To help achieve this, the Elastic Beanstalk feature automatically adds the health check as a necessary requirement in reviewing rolling deployments before a version deployment is documented as successful.
Developers could even integrate from the AWS Management Console or Command Line to trigger automated alerts in a format suited to their work practices: sending a text message to an engineer or automatically adding tasks to an engineering team’s project management tool, for example. This is the next line in the health checking. Now that the health check itself is more timely and more granular, it then needs to move out of the context of being a dashboard metric and become an automated, triggerable action.
Docker is a sponsor of The New Stack.