Monitoring your AWS Lambda applications with New Relic

With AWS Lambda, you can run applications without the added complexity of managing servers. You set triggers that invoke AWS Lambda functions to process an event that’s formatted in JSON. Compared to other AWS services, AWS Lambda is easier to set up with fewer points of failure, but a lot can still go wrong. So what do you do when your application should be humming along but it’s not?

One of the first things you’ll learn when using AWS Lambda is that some issues simply aren’t handled by AWS. The operating system, network config, and physical security of your hardware? All are guaranteed by AWS. Code quality and configuration problems? You need to have the tools to monitor and debug your Lambda-fueled applications on your own.

You can use AWS X-Ray to run distributed traces throughout your AWS environment. AWS also provides information on billing, your Lambda compute time, and peaks and average times for Lambda computes. However, AWS isn’t going to give you insights into what’s happening in your code. So when AWS says your Lambdas are blazing fast but your customers say your application is really slow, you need another tool that helps you find the root cause of the issue.  

New Relic gives you full observability into every part of your application, so you can see exactly where issues are happening and fix them faster. You can use New Relic serverless monitoring to observe individual code execution within your Lambda function. You can also use synthetic monitoring to alert you when your application is running slowly, so you can take care of it before your end users get frustrated. As a nice bonus, you can also monitor all your AWS CloudWatch data directly in New Relic—no need to context-switch between your AWS services and your monitoring solution to try to figure out issues.

So let’s take a look at the tools that you can use to monitor Lambda-powered web applications.

Monitor AWS Lambda from the inside with serverless monitoring

New Relic offers serverless Lambda monitoring of your Lambda code, combining CloudWatch data and code-level instrumentation to give you full visibility into your system. There is support for NodeJS, Python, Go, Java, and .NET Core.

So how does New Relic serverless Lambda monitoring work? New Relic provides an agent (or SDK) that wraps around your Lambda invocation handler function. This library provides:

• Information on how long function invocations are taking 
• Details on any errors that occur
• Additional context about source events and your function’s responses

New Relic also has a Lambda extension that enhances your telemetry data and sends your Lambda function’s logs to New Relic. New Relic offers a custom UI for Lambda functions, providing any troubleshooting information you need. You can read more about Lambda monitoring architecture in the New Relic docs. If you’re ready, you can jump right into enabling monitoring for AWS Lambda in New Relic.

If you’re new to New Relic, you can also get started and sign up here for free.

After you’ve set up the integration, you get a summary overview of your Lambda invocations, including their frequency, duration, and any errors.

You also have access to all your CloudWatch metrics in New Relic, so there’s no need to switch between AWS and New Relic to get more insight into how your Lambdas are performing.

There are no errors showing in the previous images, but what if errors do come up? You can select Distributed Tracing in the Lambda UI to drill down further. New Relic serverless uses the same technology as New Relic APM to monitor individual code execution in your Lambda. The next image shows an example.

Not surprisingly, the AWS Lambda function shown in the image is very fast, but other operations like a POST to a Ruby Sinatra backend and a Java page for purchase confirmation are taking considerably longer. 

You can then select a process and see exactly where it falls in your service map. For instance, the fulfillment service showing in the previous image is a bit slow. Selecting it shows how the fulfillment service fits in the services map. As the next image shows, when you select a service in the map, you can get more information on performance, attributes, and details. This kind of service map is extremely useful when you’re running hundreds or even thousands of services.

Just because your AWS Lambdas are working correctly doesn’t mean your application is, but you can quickly drill down and figure out where errors are coming from so you can fix them.

Learn more about AWS Lambda with serverless monitoring in New Relic.

To be proactive, you should also set up alerts so you’re notified when any issues arise.

Monitor your AWS Lambdas from the browser with synthetic monitoring

Now let’s discuss AWS Lambda from the outside, in production environments. The whole point of AWS Lambda is to make your life easier as a practitioner. You don’t have to worry about server provisioning, but you still need to test your code and make sure it’s working as expected. End-to-end testing is extremely important, especially when modern microservices architectures. While you can test your AWS Lambdas locally, just because everything looks good in development doesn’t mean it will run smoothly in production. 

This is where synthetic monitoring comes in. Synthetic monitoring is a bit like integration testing, except you’re testing a user flow in production, not development. When you create a user flow, you also can set one of twenty global locations where that user flow could originate from. New Relic uses minions to execute synthetic monitors and creates a Selenium-driven Google Chrome browser that navigates the user flow you determine.

So let’s say you have a process that uses AWS Lambda. You can create a synthetic monitor that simulates a user in Dublin navigating your site and invoking that Lambda. You can then set up alerts so you’re notified if the flow is taking too long or not working.

The easy way to set up a user flow (along with alerts) is described with this no-code synthetics solution. You can also set up a scripted browser monitor, which you can use to create more complex user sequences that trigger your AWS Lambda. Whether you use a script or the no-code solution, you can set the user flow to run at intervals, from as many locations as you want, and then get notified with an alert based on thresholds you define. 

That way, if you get an alert that says a user flow originating in Tokyo is taking 12 seconds, you know what’s happening—and hopefully, have the problem fixed—before your users are impacted.

Putting it together: Use serverless and synthetics for monitoring 

With New Relic serverless and New Relic synthetics, you have multiple tools at your disposal to monitor your AWS Lambda applications. On the outside—from a browser perspective—you can be proactive and set up user flows that alert you when Lambda-powered processes are taking too long or aren’t working. 

Then, from the inside, you can use New Relic Serverless to monitor the functions you’re executing both before and after your AWS Lambdas trigger. And alerts will let you know if there are any errors. After scanning your dashboards or getting an alert you can drill down and see exactly which function is causing the issue and resolve it.