Hello and welcome to this lecture, where I shall be looking at how Elastic Beanstalk performance monitoring in both your web and work environments. As we just saw in the demonstration in a previous lecture, there are a number of configurable elements when setting up your environment that will affect what monitoring and logging takes place. There are two different levels of monitoring within Elastic Beanstalk that you can choose from. This being basic health reporting and then enhanced health reporting and monitoring. Let's look at both of them to see how they differ. 

Starting with basic health reporting, as expected, basic health reporting will not provide as granular measures as enhanced health reporting and monitoring would. However, it does still provide information and data to relay to you a high-level overview of how your environment is performing. Any resources running in your environment will send metrics to Amazon Cloudwatch in five minute intervals, as if there would be if you'd deployed them without Elastic Beanstalk. These metrics would cover a range of resources. For example, if you are running a Web Tier, it would include metrics on EC2 or ELB request rates. If you were running in a Worker Tier, then you would have metrics associated to SQS. However, these Cloudwatch metrics collated are not actually used in the process to determine how healthy the environment is. The health of the environment is actually determined by other checks, as I'll explain. And results of these checks are presented by four colors within the Elastic Beanstalk dashboard as shown. For an environment using Elastic Low Balances, typically a Web Tier, then every 10 seconds, the ELB will send a health check request to every instance in the Auto Scaling group and wait for a response to confirm its health. If a response is received, the instance is considered healthy. For environments that do not necessarily have an ELB, for example, an environment with a single instance or Worker Tier, then the health of its instance is determined by its EC2 instance status check. 

These status checks are controlled by EC2 and used to check the health of the status of your EC2 instance. And understanding what common faults could trigger these checks to fail can help you troubleshoot issues with your resources. There are two types of status checks. Firstly, the system status check. If this fails, then it's likely to be an issue with the underlying host, rather than a configuration issue with your EC2 instance itself. Common issues that trigger system status checks to fail are loss of power, loss of network connectivity, and hardware and software issues on the underlying host. Basically, a system status check failure is out of our control, but the fault lies with components that are managed by AWS. The best way to resolve this would be to stop the instance and restart it. This is likely to cause the instance to launch on another physical host, resolving the issue. And then we have the instance status check. Now these differ from the system status checks, as if this fails, then it would likely require our input to help resolve the issue. This check looks at the EC2 instance itself, rather than focusing on the underlying host. Common issues that trigger this check to fail are incorrect network configuration, corrupt file systems, exhausted memory, or an incompatible kernel. And these faults will require you to troubleshoot and resolve the issue. For example, changing the network configuration. 

Elastic Beanstalk also provides high-level monitoring of your other resources as well that might have been identified as red. Elastic Beanstalk will ensure that in a web environment, if an Auto Scaling group is being used, that it is operational and it has a minimum of one instance running that is healthy. It will also ensure that the correct settings in Route 53 are being used, ensuring that the C name is redirected to the correct ELB. Finally, it will check to ensure that the security group for your EC2 instances allows port AT inbound and for work environments, Elastic Beanstalk will check to make sure that the SQS queue being used is being pulled every three minutes at a minimum. Let me now look at enhanced health reporting and monitoring. The color index signifying the health of the environment when using enhanced health reporting has a different meaning to the color index used in basic monitoring. As a recap, basic health reporting looks as follows. Whereas enhanced can be summarized as shown. As you can see, the enhanced health monitoring displays additional information to that over the basic. In addition to this, where environments are configured for enhanced monitoring, the AMIs used for your EC2 instances also have a health agent installed and running, where supported, while a platform's selected. And this allows Elastic Beanstalk to capture additional information, such as system metrics and web server logs. This allows Elastic Beanstalk to determine at a deeper level the overall health of the environment, while correlating it with data, also taken from the ELBs and Auto Scaling groups. These additional metrics captured by Elastic Beanstalk can also be sent to Cloudwatch as custom metrics. However, this feature does incur an additional cost. 

By sending data to Amazon Cloudwatch, it allows you to view the health of your environment over time and also allows you to set thresholds and notifications that you would with any other Cloudwatch metric. For more information on Amazon Cloudwatch, please see our existing course here. The health agent is simply a demon or service installed onto your deployed EC2 instances, with a sole purpose of reporting statistics and metrics from your instance RS and applications running on that instance. The main difference between the metrics of the health agent and those that Cloudwatch collect is that the health agent probes the instance at a deeper level and more frequently over Cloudwatch. In fact, Elastic Beanstalk gets data from its resources every 10 seconds and assesses the results to determine the health of the instances, based on the color indicators I explained earlier. 

That now brings me to the end of this lecture. Coming up next, I shall be providing an overview of some of the key points taken throughout the previous lectures.