Using Serverless Functions
In this course, we explore some of the common use cases for serverless functions and get started with implementing serverless functions in a simple application.
- [Lecturer] Welcome to this lecture on our getting started with serverless computing learning path, where we're looking at monitoring and debugging. In this lecture, we'll introduce the AWS Lambda CloudWatch metrics that are available to us, we'll outline how CloudWatch metrics can be used to debug an application, and we'll review how CloudWatch metrics can be used to debug and monitor our simple ordering application. CloudWatch is a service that is used to monitor the operation and performance of an AWS environment. With AWS Lambda we can use the log stream functionality of CloudWatch to monitor the execution of our functions. So, AWS Lambda includes a set of metrics that can be used to monitor the overall statistics of our functions. With CloudWatch log strings, we can get insight into the execution of our functions by using console dot log. by using console dot log. Each console dot log message will be written out to the log stream, meaning we can add messages that indicate where we are in the code. We can output the values of variables to see their state at any point during the execution. In the event of an error, we can see what happened and the structures behind it. Each execution of the function writes a minimum of three messages in the log stream. The start of the execution is logged along the time it was launched in a unique identifier called the request ID. The end of the execution is logged, and it contains the request ID along with the time the execution completed. And lastly, there is a report message that indicates the duration of the execution, the milliseconds that will be billed, and the memory allocated, and the memory used during the execution of that function. If we do nothing else and the execution succeeds, this is all we will have in the log string. If the execution fails, there will be an error message included in two messages. One that indicates the task failure with the full stack trace, and another that summarizes the error message. On a test run of our S3 restaurant ordering application, we see the standard messages along with some informational output we thought might be important to include. If there was an error during execution, or the function did not do what we expected, these messages can help. When we upload a order as adjacent file to our history bucket, the informational messages give us some insight into what happened. The first two informational messages are the S3 bucket name, and the name of the file. After these messages are written to the log stream, an error occurs. Combining these messages and the error stack trace can help us track down what went wrong. It would be pretty unfavorable to have a stack trace in production, but no additional information that can pinpoint the problem we need to fix. So the CloudWatch metrics we can get from AWS Lambda include the request account, error count and latency. The request account tells us how many times the function was executed. The error count metric tells us how many of those executions did not succeed. And the latency gives us some insight into the time it takes in milliseconds for the execution to start after it has been invoked. Like other CloudWatch metrics, we can create alarms such as sending a notification when the error count exceeds a value, say, ten times in a five minute window. Alright, that brings us to the close of this lecture. As we can see, CloudWatch provides a great complement to our AWS Lambda functions. So in summary, we've introduced the AWS Lambda CloudWatch metrics, we've outlined how CloudWatch metrics can be used to debug our simple restaurant ordering application.
Andrew is fanatical about helping business teams gain the maximum ROI possible from adopting, using, and optimizing Public Cloud Services. Having built 70+ Cloud Academy courses, Andrew has helped over 50,000 students master cloud computing by sharing the skills and experiences he gained during 20+ years leading digital teams in code and consulting. Before joining Cloud Academy, Andrew worked for AWS and for AWS technology partners Ooyala and Adobe.