This repository contains source code and utilities to build and publish New Relic's public AWS Lambda layers.
Most users should use our published layers which are chosen automatically via the CLI tool. Those layers are published to be public and are available here.
This tool is released for users seeking to deploy their own copies of the New Relic Lambda Layers into their accounts, or to modify and publish their own customized wrapper layers.
- aws-cli
- bash shell
The AWS cli must be configured, please refer to its documentation.
Run the following in your shell:
cd python
./publish-layers.sh
cd ..
cd nodejs
./publish-layers.sh
cd ..
cd ruby
./publish-layers.sh
cd ..
cd java
./publish-layers.sh
cd ..
cd extension
./publish-layer.sh
cd ..
The layers published to your account may be used directly within SAM, Cloudformation Templates, Serverless.yml, or other configuration methods that allow specifying the use of layers by ARN.
New Relic Serverless APM customers are advised to use the newrelic-lambda-cli tool, and this may be used with custom layers as follows by adding the --layer-arn flag to the layers install command:
newrelic-lambda layers install \
--function <name or arn> \
--nr-account-id <new relic account id>
--layer-arn <YOUR_CUSTOM_LAYER_ARN>
We recommend using the newrelic-lambda-cli tool, but some users find that they need, or prefer to manually configure their functions.
These steps will help you configure the layers correctly:
- Find the New Relic AWS Lambda Layer ARN that matches your runtime and region.
- Copy the ARN of the most recent AWS Lambda Layer version and attach it to your function.
- Using Cloudformation, this refers to adding your layer arn to the Layers property of a AWS::Lambda::Function resource.
- Update your functions handler to point to the newly attached layer in the console for your function:
- Python:
newrelic_lambda_wrapper.handler - Node:
newrelic-lambda-wrapper.handler - Ruby:
newrelic_lambda_wrapper.handler - Java:
- RequestHandler implementation:
com.newrelic.java.HandlerWrapper::handleRequest - RequestStreamHandlerWrapper implementation:
com.newrelic.java.HandlerWrapper::handleStreamsRequest
- RequestHandler implementation:
- Add these environment variables to your Lambda console:
- NEW_RELIC_ACCOUNT_ID: Your New Relic account ID
- NEW_RELIC_LAMBDA_HANDLER: Path to your initial handler.
- NEW_RELIC_USE_ESM: For Node.js handlers using ES Modules, set to
true.
Refer to the New Relic AWS Lambda Monitoring Documentation for instructions on completing your configuration by linking your AWS Account and Cloudwatch Log Streams to New Relic.
AWS announced support for Node 18 as a Lambda runtime in late 2022, introducing aws-sdk version 3 for Node 18 only. This version of aws-sdk patches NODE_PATH, so ESM-supporting functions using import and top-level await should work as expected with Lambda Layer releases v9.8.1.1 and above (Numerical layer versions vary by region and runtime). To configure the layer to leverage import, add the environment variable NEW_RELIC_USE_ESM: true.
Note that if you use layer-installed instrumentation with the NEW_RELIC_USE_ESM environment variable, your function must use promises or async/await; callback based functions are not supported. The Node wrapper uses a dynamic import to attach to your function, which is an asynchronous operation. If you still need support for callback based functions, you will have to use the CommonJS based wrapper, which can be done by removing the NEW_RELIC_USE_ESM environment variable.
You may see some warnings from the Extension in CloudWatch logs referring to a non-standard handler; these warnings may be ignored.
If your Node functions use import and top-level await in Node 16 or Node 14 runtimes, layer-installed instrumentation will be unable to find imported modules, as import specifiers don't resolve with NODE_PATH. You can still instrument your functions with New Relic, but you will need to do the following:
- instrument your function manually using our Node Agent
- On deploying your function, don't set the function handler to our Node wrapper; instead, use your regular handler function, which you've wrapped with
newrelic.setLambdaHandler(). - If you're using Node 18 or above, apply the latest Lambda Layer for your runtime. It will install both the Node agent and our Lambda Extension.
- If you're using Node 14 or Node 16, you will have to deploy our agent with your function code, but you could use our Extension-only Lambda Layer for delivering telemetry. Use our layer discovery website to find the ARN for your region. Look for either NewRelicLambdaExtension or NewRelicLambdaExtensionARM64 (depending on your function's architecture).
- Add your
NEW_RELIC_LICENSE_KEYas an environment variable.
In order to wrap ESM functions without a code change, our wrapper awaits the completion of a dynamic import. If your ESM function depends on a large number of dependency and file imports, you may see long cold start times as a result. As a workaround, we recommend instrumenting manually, following the instructions below.
First import the New Relic Node agent into your handler file:
import newrelic from 'newrelic'Then wrap your handler function using the .setLambdaHandler method:
export const handler = newrelic.setLambdaHandler(async (event, context) => {
// TODO implement
return {
statusCode: 200,
body: JSON.stringify('Hello from Lambda!')
}
})Should you need assistance with New Relic products, you are in good hands with several support channels.
If the issue has been confirmed as a bug or is a feature request, please file a GitHub issue.
Support Channels
- New Relic Documentation: Comprehensive guidance for using our platform
- New Relic Community: The best place to engage in troubleshooting questions
- New Relic Developer: Resources for building a custom observability applications
- New Relic University: A range of online training for New Relic users of every level
- New Relic Technical Support 24/7/365 ticketed support. Read more about our Technical Support Offerings.
At New Relic we take your privacy and the security of your information seriously, and are committed to protecting your information. We must emphasize the importance of not sharing personal data in public forums, and ask all users to scrub logs and diagnostic information for sensitive information, whether personal, proprietary, or otherwise.
We define “Personal Data” as any information relating to an identified or identifiable individual, including, for example, your name, phone number, post code or zip code, Device ID, IP address and email address.
Please review New Relic’s General Data Privacy Notice for more information.
We encourage your contributions to improve the New Relic Lambda layers! Keep in mind when you submit your pull request, you'll need to sign the CLA via the click-through using CLA-Assistant. You only have to sign the CLA one time per project.
If you have any questions, or to execute our corporate CLA, required if your contribution is on behalf of a company, please drop us an email at opensource@newrelic.com.
A note about vulnerabilities
As noted in our security policy, New Relic is committed to the privacy and security of our customers and their data. We believe that providing coordinated disclosure by security researchers and engaging with the security community are important means to achieve our security goals.
If you believe you have found a security vulnerability in this project or any of New Relic's products or websites, we welcome and greatly appreciate you reporting it to New Relic through HackerOne.
If you would like to contribute to this project, review these guidelines.
To all contributors, we thank you! Without your contribution, this project would not be what it is today.
The New Relic Lambda layers are licensed under the Apache 2.0 License.
The New Relic Lambda layers also use source code from third-party libraries. You can find full details on which libraries are used and the terms under which they are licensed in the third-party notices document.