An overview of CloudWatch Metrics for AWS Lambda
Learn how to monitor CloudWatch Metrics for AWS Lambda Functions
In this article, I am going to discuss about AWS Lambda execution and monitoring using the CloudWatch metrics. AWS Lambda lets you run your applications on the cloud without having to provision any servers. All you need to do is write your code using your preferred programming language and deploy your code to AWS Lambda. You can then directly run your programs using the resources provided by AWS. At the time of writing this article, AWS Lambda supports programs written in Java, NodeJS, C#, PowerShell, Python, Ruby and Go.
Why should you monitor Lambda Functions
I think this is a good point to start. It might be a question that if Lambda is serverless and deployed in the cloud then why do we actually want to monitor it. Well, that’s because Lambda is billed for every execution triggered and also for the duration of the execution. We will see more about the Lambda pricing later in the article. However, there is always room or scope of improving the code such that it executes efficiently with minimum resources and in the least possible time frame. This will help you grow as a developer and gradually will also contribute towards the growth of the organization, since you are actually building a system that is cost efficient.
In the new age of cloud computing, things are a bit different from the traditional server based architectures. AWS Lambda is serverless and it has a built-in logging and monitoring system that pushes the results in AWS CloudWatch. It is important to know what metrics can be measure while running an AWS Lambda Function. Following are some of the metrics that are captured by the CloudWatch during the execution of a Lambda Function.
In order to view the Performance metrics for any Lambda function, you can follow the steps as follows. Open the Lambda Function that you want to monitor. Click on Monitoring on the top and the CloudWatch Metrics tab will show up. In this tab, you can see multiple metrics as follows.
In this tab, there are almost seven metrics that are monitored. I have discussed the meaning of each of the metrics below. Basically, all the metrics can be divided into three parts — Invocation Metrics, Performance Metrics and Concurrency Metrics. Let us see each of these in details.
Invocation Metrics
· Invocations — This metrics is one of the most important on which the billing of the lambda functions depend on actually. Whenever a lambda function in triggered, Lambda adds in a value of 1 for each of the successful or failed executions. In case the invocation is throttled then it wouldn’t be captured in this metric.
· Errors — There might be errors in the lambda function which might result in non-successful completion of the lambda function after execution. This might due to exceptions internally raised by the code of the lambda function or by the lambda runtime itself. Most common reasons of errors raised by the lambda environment are incorrect parameter configuration or timeout issues raised due to longer execution. A lambda function can run for 15 mins at maximum.
· Error Rate — The error rate is calculated by dividing the number of errors by the total number of function invocations.
· Success Rate — The success rates of the lambda functions is calculated by subtracting the errors from the invocation and then dividing it by the total number of invocations.
Performance Metrics
The performance metrics tell us about the performance of a single execution of a lambda function.
· Duration — This metric tell us the duration that lambda takes in order to execute the function. This also depends on the amount of memory that is allocated to the lambda. Based on the memory, AWS assigns a compute power to the lambda as well which is in proportion with the memory allocation. You can play around this setting to find a good benchmark when your lambda use up all the memory that has been allocated.
· Iterator Age — This metric helps us understand the duration between the messages received at the stream and it actually is sent to the function. This metric is applicable only for event source mapped lambda functions. Events to the lambda functions can be sent from various Amazon services like Simple Queue Service or Amazon Kinesis.
Concurrency Metrics
Running lambda functions on the cloud provides an added advantage to run concurrent functions together at the same time. When lambda functions are executed in parallel, the concurrency metrics are pushed in to the CloudWatch Metrics.
· Concurrent Executions — This metric tells us the maximum number of concurrent executions that are running at the same time for any given particular lambda function.
CloudWatch Logs Insights
Whenever a lambda function is executed, logs are generated which are stored and can be viewed from CloudWatch later at any point of time. Logs help us analyze and troubleshoot the lambda functions in case there are any issues or errors during the execution of the functions.
The CloudWatch Logs Insights is also an important section that provide us information regarding each of the execution of the lambda functions. There are two sections in this — Recent Invocations and the Most Expensive Invocations. The CloudWatch Metrics provided in these section are as follows.
· Timestamp — This in general, is the timestamp when the function receives the request to start an execution. It is stored in UTC time zone.
· RequestID — The RequestID is a UUID field that is autogenerated for every execution of a lambda function. This is a unique identifier that can be used to identify a specific instance of execution of a lambda function.
· LogStream — The logstream actually contains the detailed stream of logs that is generated during the generation of the Lambda function. You can click on each of the individual log streams that will open up the specific log stream where you view the logs in detail.
· DurationInMS — This metric tells us the duration of the execution of the lambda function in milliseconds.
· BilledDurationInMS — This metric is a rounded up version of the DurationInMS metric that is used for the purpose of billing. Usually, the values are always rounded up to the next higher integer.
· MemorySetInMB — This tells us the memory that we have allocated to the particular Lambda Function while execution. By default every lambda function is set to start with 128 MB of memory. However, depending the load of your application, you are advised to alter it accordingly.
· MemoryUsedInMB — This is one of the most important CloudWatch Metrics that I personally use a lot to understand how much memory is being consumed by my application. If all the memory set is being used, then we should increase it so that there is some memory left after the execution. This will also in turn help in decreasing the duration of the execution time.
· BilledDurationInGBSeconds — This is a calculated metric that is measured by multiplying the memory assigned with the billed duration. You are finally billed based on this metric.
Conclusion
In this article, we have seen how to bundle applications and deploy to AWS Lambda. AWS Lambda provides a platform your run your applications on a serverless platform. This means that you do not need to maintain or take care of the underlying resources used by Lambda. However, since it is serverless, you need to monitor the usage of the functions and so that you are not over billed. Lambda is billed based on the number of executions and also the duration of the execution. You can easily monitor the executions of the Lambda Functions using the CloudWatch Metrics that are provided by default.
