What is AWS Lambda monitoring?
AWS Lambda is a serverless computing service provided by Amazon Web Services. It enables to run code, from simple functions to whole applications, without having to provision and manage servers. AWS Lambda monitoring is the branch of AWS cloud monitoring that deals with ensuring that AWS Lambda code is running without issues and hiccups.
AWS Lambda is a complex ecosystem that supports many use cases. It is used to run arbitrary code written in many languages, from JavaScript to Go, from Python to Ruby, C#, and Rust, just to name a few. AWS Lambda functions can be used for plenty of scopes: running websites, mobile apps, or doing data analytics, file processing, and a lot of different usage scenarios.
These are critical pieces of a company's infrastructure, and it is therefore important to make sure that these workloads are efficiently performing and healthy, following AWS Lambda monitoring best practices. Monitoring AWS Lambda applications can also help you detect performance problems, outages, and errors in the workloads.
What are the AWS Lambda metrics to monitor?
By default, AWS Lambda metrics are exposed to Amazon CloudWatch, the central monitoring tool that integrates metrics from all AWS cloud services and resources. These metrics are free of charge, unlike the other functionalities of AWS Lambda. Lambda metrics are sent to CloudWatch every time a function finishes processing an event.
Lambda monitoring then can go through simply setting up a dashboard on CloudWatch and checking the metrics for all your code on AWS Lambda or using a third-party AWS Lambda monitoring tool that supports the metrics that you are interested in. There are a few types of Lambda metrics, grouped in 4 categories: Invocation, Performance, Concurrency, and Asynchronous invocation.
AWS Lambda Invocation metrics
Invocation metrics are indicators of the outcome of your Lambda functions. The main metrics you want to monitor are the total function invocation count, the number of errors returned, the destination delivery failures (the number of times that AWS Lambda attempts to send an event to a destination but failed), the invocation throttle count, and the count of occurrences of recursive invocation dropped, a sign that your function may be part of an infinite recursive loop. These Lambda metrics are the basic ones to check how your functions are being run and if they are encountering problems of any sort.
AWS Lambda Performance metrics
Performance AWS Lambda metrics provide performance details about a single function invocation. To get a sense of how well your functions are performing, check the duration metric, the post runtime extensions duration, which will tell you the time spent processing an event. Some sources of events also trigger the creation of iterator age and offset lag Lambda metrics. The former is for functions connected with Amazon databases like DocumentDB, DynamoDB, and Kinesis. It calculates the time between a stream receiving the record and when the event source mapping sends the event to the function. The offset lag metrics is instead for self-managed Apache Kafka event sources, recording the offset between last record written and the last event your function processed.
AWS Lambda Concurrency metrics
Monitoring AWS Lambda often implies many concurrency functions and services. AWS Lambda metrics in the Concurrency category includes metrics like unreserved and concurrent executions, the number of function instances that are processing events. Provisioned concurrent executions and utilization instead inform you about the number of function instances that are using provisioned concurrency, and their utilization value.
AWS Lambda Asynchronous Invocation metrics
In case of asynchronous invocations, there are only 3 metrics that are exported by AWS Lambda functions. They are the number of received events, those which are successfully queued for processing, the number of dropped events, those which were instead dropped, and the async event age, the time between queuing and successfully invoking the relative function.
These are the metrics in Lambda monitoring useful to understand the overall performance of your AWS Lambda assets.
AWS Lambda monitoring best practices
While it would not be wrong to monitor all the above-mentioned metrics, it is not strictly necessary. Nor is it due in every use case of AWS Lambda. One of the main AWS Lambda monitoring best practices to follow is to focus on the metrics that matter to you and that apply to how you use the power of AWS Lambda functions. Also, to avoid being inundated by data, making it harder to discern what is important and what can be ignored.
Surely an important practice to follow is to check the AWS Lambda logs. These are pushed to CloudWatch or can be accessed through the Lambda Console, the AWS CLI, or with the CloudWatch API made available externally, to your AWS Lambda monitoring tool of choice. It is worth having in mind that AWS Lambda logs are not created in real-time, but it may take between 5 and 10 minutes for them to show up after a function invocation.
Monitoring AWS Lambda necessitates setting up a proper alarm or notification system, as in all other types of monitoring. CloudWatch alarms or custom notification in the AWS Lambda monitoring tool you are using, like Checkmk, are vital to be promptly informed of metrics reaching a threshold and know when you need to intervene.
An useful tool from Amazon to contain AWS Lambda costs is Cost Anomaly Detection. It is an AWS Lambda monitoring best practice to have a system to check and identify costs and opportunities to reduce them. Cost Anomaly Detection can help, but better than it is Checkmk, which can give you an overview of costs per AWS service or per account, warning you when you are approaching your pre-defined limits.
AWS Lambda monitoring is a complex set of efforts to maintain efficiency in your serverless functions. Keeping track of, probably, hundreds or thousands of them is an impossible task to leave to cloud administrators only. A good Lambda monitoring tool with advanced functionalities, like Checkmk, is vital to have maximum observability and automation in an AWS cloud setup. Checkmk can help administrators in identifying problems, areas of improvement, errors, and contain AWS costs.
FAQ
AWS Lambda allocates CPU power in proportion to the memory configured. By default, AWS Lambda functions have 128MB of allocated memory. The max memory size of each function is 10GB.
AWS Lambda and Fargate are both serverless technologies to run code and applications on the Amazon cloud. Lambda runs code and applications, while Fargate is specific to containers, falling into the category of CaaS (Containers as a Service) offerings. Lambda and Fargate are not direct alternatives then, but one is used over the other depending on whether you need to run small code snippets or large applications, and the other when implementing containers in your infrastructure.