Quickly Debug Your AWS Lambda Functions
Tags: aws, serverless, devops, cloud
Published: 2021-04-23 11:05:24

*In this article, we'll be looking into four different methods of how to debug AWS Lambda functions faster.*

Great writers use metaphors to get their point across, so let me give that a try real quick.

Bugs are nasty little pests. It's hard to get rid of them, but apart from just spraying poison everywhere, there are only a few options left. One of those options is using a natural predator to get rid of those bugs, a predator like birds.

So birds can help you get rid of bugs, and I work for a company called Dashbird that helps developers debug their AWS Lambda applications.

See what I did there? **Pests\bugs ⇔ birds\Dashbirds**?

Main Reasons For Using AWS Lambda Functions
-------------------------------------------

One of the main AWS Lambda perks is that, as AWS claim, **"You can forget all about the project's infrastructure and focus solely on launching apps in the cloud while you'll be able to perform integrations with other Amazon services."** Scalability and the low cost of using the AWS computing resources are other perks that come along.

![anatomy of a function](https://dashbird.io/wp-content/uploads/2020/10/rvsm59em8ijtn9wt2h4h.png)*Anatomy of a Lambda function - AWS re:Invent 2017*

All you need to do is to **write your function**, **connect it to an event**, **deploy it**, and **AWS will take care of the rest**. The Lambda function will process thousands of requests every hour on AWS with no need for your effort whatsoever.

**But what happens when a Lambda function fails**?

How To Debug AWS Lambda Functions?
----------------------------------

When talking about the debugging process on AWS Lambda functions, **four methods are most commonly used**. These methods can be grouped into two categories. The first one is offline debugging, and the second one logging.

### Debugging Lambda Functions Offline

Offline debugging allows you to work locally in case of a standard development process.

The [Serverless Offline](https://www.npmjs.com/package/serverless-offline) library is great for debugging your application **while it's still in development**. It acts very similar to AWS, giving you access to various services like SQS, SNS, S3, etc., only, instead of the request hitting the live services, **it goes to a local emulated service**.

### Logging Lambda Functions Online

Suppose you have a **live service** or have a **dev/staging environment** or **multiple developers working on the same project at once**. In that case, you'll need to start looking at live **debugging services**. While there are tons of tools to debug monolith applications, **for serverless specifically, there are only a few tools for debugging**, some better than others.

But when you deploy your Lambda function to real infrastructure, **logging might be the only debug method left**. **Logging can be done in three ways**.

1.  **First**, log directly to AWS CloudWatch, by simply writing to standard out. This is probably the most popular method because it's easy to set up. The **downsides of CloudWatch are that all the logs are grouped, and it can take a lot of time to figure out what's wrong** when you have many moving parts in your app. Nevertheless, it's probably the best option if you are just starting with AWS Lambda.
2.  **The second way** is to **write your own logging tool** with AWS services like Kinesis. In this process, the need for manually creating these tools **will take developers a lot of time**, which further means it'll cost more since additional Amazon infrastructure will be used. But at first, this process seems quite faster.
3.  **The third way** is the use of third-party logging services. They don't have the downsides of using CloudWatch but also don't require you to waste development time.

Dashbird is the only tool entirely dedicated to [monitoring and debugging AWS Lambda applications and serverless systems](https://dashbird.io/aws-lambda-monitoring/), and **the main reason our users love the service is its simplicity**. With just a few clicks you can connect your AWS account, no code changes, and start discovering and troubleshooting **unknown and known errors** from general statistics of your microservices to individual function execution profiles.

[![AWS Lambda monitoring](https://dashbird.io/wp-content/uploads/2020/07/lambda.png)](https://dashbird.io/aws-lambda-monitoring/)

### Debugging AWS Lambda Functions with Dashbird

Dashbird is an excellent choice since it was **built especially for serverless** **developers**, and it's able to detect quickly any sorts of failures. Dashbird offers quite a lot of features for effective debugging like:

-   [**Error Views**](https://dashbird.io/failure-detection/) necessary in **showing and discovering the point of failure** that gives developers insight into what went wrong.
-   **Log Search** allows you to **search through Lambda logs**, which means you'll be able to find relevant invocations.
-   **Function View** allows you to **look closer into any function** that seems to misbehave and thoroughly work on it.
-   **Live Tailing** allows developers to **perform a real-time observation of a function's activity**.
-   **Tracing** gives you an incredible and compelling **insight into what your invocations are doing and how they're interconnected**.

![](https://dashbird.io/wp-content/uploads/2020/10/f86h82npl8856sjihaxi.png)

Debugging an Example Lambda Function
------------------------------------

Let's try to debug an example function. We can create one with the **AWS Lambda web console**. I'll assume that you know how to do this and just give you the example code here:

exports.handler = async (event, context) => {
  console.log("Logging!");

  const x = event.a.b;
};

Two types of logs will be produced by this function. First the call to the `console.log` function then the access of an undefined event property.

If you open up [Dashbird](https://dashbird.io/), the first thing you will see is the main dashboard. This error will be in plain sight.

![dashbird dashboard showing errors](https://dashbird.io/wp-content/uploads/2021/04/quickly-debug-total-errors.png)

"`Cannot read property 'b' of undefined`" --- a well-known JavaScript error message. When you click on it, you get the **event view** with more details of the error.

![error detail with stack trace](https://dashbird.io/wp-content/uploads/2019/04/read-property-b-undefined.png)

Dashbird's error details will show you **when the error first happened, when it last happened, where it happened and how severe it actually is**.

It even gives you a stack trace, which helps to **debug the error before the next deployment**.

But where did the call to `console.log` end up? If you go to **Inventory** and click on your **Lambda function** in the list that opens **you can choose from the last invocations of that function**. My function is called `extractRecords` so that's what I'll search for.

![invocation logs](https://dashbird.io/wp-content/uploads/2019/04/invocation-logs.png)

If I click on the last invocation, the logs of that invocation will open and I'll see the log call and the error.

![debugging and tracing details](https://dashbird.io/wp-content/uploads/2019/04/debug-tracing.png)

Depending on the number of logs you write in your function, it can become hard to find the error, that's why **I'd recommend using the error details when debugging**.

Summary
-------

AWS Lambda functions are working in an **isolated remote environment**, which complicates debugging more and more. While your code is in the **development phase**, it's still crucial to go through frameworks (think [Serverless Application Model](https://github.com/aws/serverless-application-model)) to **monitor and debug your code on your machine**.

When you finally **deploy your function to the cloud**, different methods are required to get the [insights](https://dashbird.io/serverless-observability/) you need. If you think CloudWatch is too clunky and you **want to see what's happening at one glance**, give [Dashbird](https://dashbird.io/) a try. It's **built from the ground up to monitor serverless applications** and **removes many obstacles** you would find when building your own logging service.