Start free trial

Central data platform for your serverless environment.

Get full access to all premium features for 14 days. No code changes and no credit card required.

Password: 8+ characters, at least one upper case letter, one lower case letter, and one numeric digit

By signing up, you agree to our Privacy policy and
Terms and Conditions.

How To Measure And Improve Your Serverless Application’s Health

Share

Technology and its implementation methodology evolves with time very rapidly. Cost efficiency and productivity are the key drivers of technological evolution these days. With the advent of The Cloud, infrastructure costs have been brought down significantly. Serverless technology adds icing to the cake! Serverless, or in other words “pay-as-you-go” computing, enables users to not pay for infrastructure while apps are sitting idle.

AWS Lambda and serverless computing have become synonymous to each other. But, that’s not exactly true. AWS Lambda is a compute service on the AWS cloud provider. While serverless stands for any and every service you can use to serve your app without managing your own servers. These services are numerous on AWS, like Kinesis, S3, API Gateway and of course Lambda. The same applies to other cloud providers such as Azure and Google Cloud!

Getting back to the gist of it. If you choose to use AWS Lambda to create functions or any serverless architecture based service, you will have to deal with some “trade-offs”.

To name few, you lose some flexibility. Mainly because you cannot connect to the instance, like you would with let’s say EC2. But the main issue is the difficulty to monitor issues, diagnose where they are happening and debug them. Considering these limitations, this article will cover how the health of your AWS Lambda functions can be measured and improved.

Before moving on let’s just mention some positive trade-offs. The main upside is that you do not have to manage any servers. You just deploy the code, and the Cloud provider does the rest. You don’t have to scale anything, because it will auto-scale to keep up with spikes in usage. Meaning, you can sleep at night and not worry about downtime. I like sleep. Very much.

How to measure the health of your AWS Lambda functions

Here are few metrics which should be considered while measuring how good your lambda functions are functioning. It is important to note that, these measures vary from function to function depending on their type. For example, for a real-time request (user facing), functions need to quickly respond while for a calculation intensive non-user facing request will have different priorities.

  • How many times functions are invoked in a given period of time?
  • What is the average time taken by these function calls? And what is the breakdown between lambda service and function code?
  • What is the memory usage of these functions?
  • Which are most invoked functions? And which functions caused most errors?
  • How many functions were throttled?
  • How frequently is my function having cold start?

Dashbird helps aggregating and analyzing the metrics above to diagnose issues which surface in a serverless environment. Dashbird parses CloudWatch logs and presents an overview which enables users to analyze lambda functions effectively, including their health, errors, invocations among many other key factors.

Here is an image of the main dashboard on Dashbird. It’s very handy tool which lets you analyse the health of your lambda functions. As you can see, parameters like number of invocations, duration, memory usage are among the few parameters which are displayed straight up.

1. Fixing / Improving bad lambdas

Dashbird lets you analyse individual lambdas as shown in following screenshot.

You can narrow down your analysis by clicking on a specific lambda above. Say you click on the lambda named as “timeout” in the view above, it will show the detailed view of the timeout lambda as shown below.

Now, if you wish to further analyse the logs or other factors of specific invocation, you can do so by clicking the Request which shows this.

2. Allocating more memory to resource-hungry functions

Dashbird also provides memory usage for each lambda. The memory usage in the below screenshot helps you identify if we need to allocate more memory for improving health.

3. Unused libraries/frameworks

The size of the deployed archive can impact the performance of your lambda function. Removing any unused libraries or frameworks will speed up the warm up and invocation time. If none of the libraries can be removed, one can look for alternative lightweight efficient libraries that can replace the ones which are currently used.

4. Avoid Cold starts, keep lambdas warm

AWS Lambda is billed per invocation. It makes no sense for AWS to keep our functions warm all the time. But these cold starts can be frustrating for user experience. The best way to keep them warm is to schedule their invocation. Though, it adds to the overall cost but it is worth considering, because of the significant performance boost it gives. Here is how you can schedule your lambda function invocation.

  1. Go to AWS console
  2. Click on CloudWatch
  3. Click on Events and Create Rule
  4. Enter necessary details in Event Source and Targets as shown in screenshot below

5. X-Ray SDK

With AWS X-Ray, developers can analyze and debug performance issues and troubleshoot them. You can use AWS X-Ray SDKs to create your own trace segments, annotate your traces, and view trace segments for downstream calls made from your Lambda functions. Luckily, Dashbird now has X-Ray integration making it incredibly easy to trace the logs!

Finally, a few takeaways

Serverless comes with limitations of less control on your application infrastructure, however, with analysis in right direction powered by right metrics and utilising tool provided by Dashbird, one can come over these limitations.

Hope you liked reading this short overview of monitoring the health of your lambda functions. Feel free to let us know in the comments below if you have any questions or remarks!


We aim to improve Dashbird every day and user feedback is extremely important for that, so please let us know if you have any feedback about these improvements and new features! We would really appreciate it!

Sign up to our newsletter to get all the latest news and tutorials on serverless.

Made by Developers for Developers

Our history and present are deeply rooted in building large-scale cloud applications on state-of-the-art technology. Dashbird was born out of our own need for an enhanced serverless debugging and monitoring tool, and we take pride in being developers.

10,000+ developers trust Dashbird

Dashbird helped us reduce the time to discovery from 2-4 hours to a matter of seconds. This means we’re saving dozens of hours in developer time, which not only can be funneled into improving the product but also means hundreds of dollars are saved every month.

Great onboarding: it takes just a couple of minutes to connect an AWS account to an organization in Dashbird. The UI is clean and gives a good overview of what is happening with the Lambdas and API Gateways in the account.

Dashbird provides an easier interface to monitor and debug problems with our Lambdas. Relevant logs are simple to find and view. Dashbird’s support has been good, and they take product suggestions with grace.

Great UI. Easy to navigate through CloudWatch logs. Simple setup.

Dashbird helped us refine the size of our Lambdas, resulting in significantly reduced costs. We have Dashbird alert us in seconds via email when any of our functions behaves abnormally. Their app immediately makes the cause and severity of errors obvious.

Read our blog

Why Are Some Engineers Missing The Point of Serverless?

Why are some engineers missing the point of serverless? Let’s have a look at the common critique points, benefits, drawbacks of serverless, and if it makes sense for your use case.

How Dashbird innovates serverless monitoring

What makes an effective serverless monitoring strategy? In this article, we’re discussing the three core ideas that Dashbird’s serverless monitoring tool was built on top and that should be the fundamentals of any effective serverless monitoring approach.

Debugging with Dashbird: Malformed Lambda Proxy Response

A problem that pops up quite frequently when people try to build serverless applications with AWS API Gateway and AWS Lambda is: Execution failed due to configuration error: Malformed Lambda proxy response.Learn what causes it and how to fix it.

AWS Lambda Error Handling

In this article, we’ll be discussing everything you need to know about the basics of AWS Lambda error handling and some popular methods using StepFunctions and X-Ray.

Deploying AWS Lambda with Docker Containers: I Gave it a Try and Here’s My Review

AWS Lambda now supports Docker Containers. Finally! We gave it a try and here’s our review (with ETL examples)

Go to blog