4 AWS Lambda Debug Methods To Troubleshoot Function Issues

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 Lambda function – AWS re:Invent 2017 All you need to do is to , , , and . The Lambda function will process thousands of requests every hour on AWS with no need for your effort whatsoever. write your function connect it to an event deploy it AWS will take care of the rest 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 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. Serverless Offline Logging Lambda Functions Online Suppose you have a or have a or . In that case, you’ll need to start looking at live . 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. live service dev/staging environment multiple developers working on the same project at once debugging services 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 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. 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. 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, 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 from general statistics of your microservices to individual function execution profiles. unknown and known errors 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: necessary in showing and discovering the point of failure that gives developers insight into what went wrong. - Error Views - allows you to search through Lambda logs, which means you’ll be able to find relevant invocations. Log Search - allows you to look closer into any function that seems to misbehave and thoroughly work on it. Function View - allows developers to perform a real-time observation of a function’s activity. Live Tailing - gives you an incredible and compelling insight into what your invocations are doing and how they’re interconnected. Tracing Debugging an Example Lambda Function Let’s try to debug an example function. We can create one with the . I’ll assume that you know how to do this and just give you the example code here: AWS Lambda web console 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 function then the access of an undefined event property. console.log If you open up Dashbird, the first thing you will see is the main dashboard. This error will be in plain sight. “ ” — a well-known JavaScript error message. When you click on it, you get the with more details of the error. Cannot read property ‘b’ of undefined event view 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 end up? If you go to and click on your in the list that opens you can choose from the last invocations of that function. My function is called so that’s what I’ll search for. console.log Inventory Lambda function extractRecords If I click on the last invocation, the logs of that invocation will open and I’ll see the log call and the error. 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 , which complicates debugging more and more. While your code is in the , it’s still crucial to go through frameworks (think ) to . isolated remote environment development phase Serverless Application Model monitor and debug your code on your machine When you finally , different methods are required to get the insights you need. If you think CloudWatch is too clunky and you , give Dashbird a try. It’s and you would find when building your own logging service. deploy your function to the cloud want to see what’s happening at one glance built from the ground up to monitor serverless applications removes many obstacles