This is one step of enabling New Relic's AWS Lambda monitoring.
Important
Because there are several steps to integration, it's important that you test your account link by deploying and testing an example function before instrumenting your own code.
Deployment strategies
There are many different deployment strategies for Lambda functions. New Relic offers direct support for several, but we cannot cover every option. At its core, New Relic Lambda instrumentation relies on the Lambda service itself, rather than any particular deployment strategy or tool, so we're confident that it can be made to work in your use case.
newrelic-lambda
CLI quickstart
The CLI tool that we recommended for setting up the account link can also reconfigure your Lambda functions to use New Relic.
To install or upgrade the New Relic instrumentation layer, run:
newrelic-lambda layers install --nr-account-id YOUR_NR_ACCOUNT_ID --function my-function --upgrade
This command automatically finds the newest available layer for your Lambda's region and runtime.
This is a great way to quick-start instrumentation, and this tool can easily be integrated into your existing CI/CD processes. However, since it modifies existing Lambda function resources, when you deploy a code update to your function, you may inadvertently remove the New Relic instrumentation. Be sure to re-run the command above after every update, or (even better) integrate the layer and associated configuration with your existing deployment process.
Note that the CLI can operate on many functions in a batch: use --function all
, --function installed
, or
--function not-installed
to operate on all functions in a region, or only those with or without existing
New Relic instrumentation.
Continuous deployment
In the long term, it's usually less work to integrate New Relic into your existing continuous deployment process. Instead of running the CLI after updating your function, you can integrate New Relic into your continuous deployment framework.
Unusual integrations
For most, one of the options above will work well. There's a chance that you can't use any of these solutions though. For guidance on how to customize your integration to fit your needs, read on.
CloudWatch telemetry
As mentioned previously we used to recommend sending your telemetry through CloudWatch Logs. This path can still work, though it is deprecated.
- Disable the extension by adding the
NEW_RELIC_LAMBDA_EXTENSION_ENABLED
environment variable to your function, with the valuefalse
. - Create a CloudWatch Logs subscription filter, to invoke the
newrelic-log-ingestion
function with the logs for your function.- The CLI can do this for you:
newrelic-lambda subscriptions install --function FUNCTION_NAME
- Alternatively, use the AWS Console to create a subscription filter from your function's CloudWatch Log Group to
invoke the
newrelic-log-ingestion
lambda function. See below.
- The CLI can do this for you:
Lambda console UI configuration
While it is more error prone and labor intensive than the approaches above, it's possible to manually alter the configuration of a Lambda function to use New Relic from the AWS Lambda Console, for Node.js, Python, Ruby and Java.
Find the layer that matches your runtime and region.
Copy the Amazon Resource Name (ARN) of the most recent version and add it in the AWS Lambda console for your function.
Update your function's handler to point to the newly attached layer in the console for your function:
- Python and Ruby:
newrelic_lambda_wrapper.handler
(underscores) - Node:
newrelic-lambda-wrapper.handler
(hyphens) - Java:
RequestHandler
implementation:com.newrelic.java.HandlerWrapper::handleRequest
RequestStreamHandlerWrapper
implementation:com.newrelic.java.HandlerWrapper::handleStreamsRequest
- Python and Ruby:
Add these environment variables to your Lambda console:
NEW_RELIC_ACCOUNT_ID
: Your account IDNEW_RELIC_LAMBDA_HANDLER
: Path to your initial handler.
Modify the Execution Role to allow access to the New Relic secret
Find the ARN of the secret named
NEW_RELIC_LICENSE_KEY
Add a new inline policy in the function's execution role that looks like this (replacing the
SECRET_ARN
with the value you found above):"Statement": [{"Action": ["secretsmanager:GetSecretValue"],"Resource": "SECRET_ARN","Effect": "Allow"}]
Note that for Go, you must make source code changes to your Lambda function to instrument it. Configuration changes are not enough.
Layer customization
The layer contains several components, depending on your runtime:
- For all runtimes, the extension executable is packaged in the layer.
- For Python, Ruby, Node.js and Java, we also include:
- The New Relic agent
- The AWS SDK instrumentation package for the New Relic agent
- A handler wrapper, which configures the agent, and intercepts invocations, to start the instrumentation process, then invokes your handler.
If you need a different wrapper, you can build your own layer, based on ours. See our newrelic-lambda-layers GitHub repo for the code contained in our wrapper function. By creating your own layer with a replacement wrapper, and applying it after ours, your wrapper will overwrite the one we supply. Similarly, you can include your custom wrapper directly in your function.
Similarly, if you are testing a custom build of the agent, perhaps to address some bug, you could modify our layer packaging scripts above to package your agent build, and build your own layer.
We explicitly do not recommend that you package the agent with your Lambda function. While this is possible, it makes it difficult for you to upgrade the agent and receive bug fixes. The layer may conflict with your vendored agent. Such a configuration should be regarded as unsupported, though it can work.
Did this doc help with your installation?
What's next?
After you complete these steps, here's what you can do next:
- See data reporting in the Lambda monitoring UI. If you're having trouble finding your data, see Lambda enable troubleshooting.