AWS Lambda Extensions & newrelic-log-ingestion lambda

Hi Team, I’m currently trying to implement the lambda monitoring in NR to get in-depth monitoring for the AWS lambda functions. I got confused in some of the methods as mentioned in the docs and also have few questions based on that.

  1. Do we need to create newrelic-log-ingestion lambda to get all detailed metrics from the lambda function or lambda extensions with the respective layer is enought to do that ?
  2. Do we need to link the AWS account anywhere in the NR console other than the IAM role permissions (with external ID as NR-account-id) in respective AWS account ?

Hey @kavinrajag.17mts,

Thanks for posting your questions here in Explorers Hub! Also exciting to see you are trying out our Lambda monitoring to get more in-depth instrumentation for your functions! Yay!

Depending on the language, the layer may or may not suffice. For Node.js, Python, and Java functions, we have everything you would typically need bundled into the layer. That includes our agents or OpenTracing SDK, wrapper code to hook up your function’s handler and set environment variables, and our Extension to ship payloads and logs (bypassing CloudWatch and the newrelic-log-ingestion function).

If using Go or .NET functions, you can still use our Extension layer (which just includes the Extension and nothing else) to avoid CloudWatch and associated expenses, but will need to manually hook up your functions since we don’t have a wrapper to do that.

So to address your first question, you don’t need to create the newrelic-log-ingestion function to get detailed metrics. It can be replaced by our Extension and any existing subscription filters pointing function output to the log ingestion function can be deleted.

For your second question, just one integration is needed in the Infrastructure → AWS page. This brings in all of the function names and associated CloudWatch metrics (basic monitoring data).

If you are using a Metric Streams integration, make sure to unlink a previously created API polling integration for the same AWS account if one exists. There should only be one integration per AWS account or bad things will happen.

*Note: our tooling has yet to be updated to work with Metric Streams. If using our CLI to do a newrelic-lambda integrations install, it will still try to create an API polling integration. This would be undesirable if you already have a Metric Streams integration set up. It’s a similar situation for our Serverless Plugin. Best to keep the default enableIntegration: false in that case.

Hi, do you have any updates to this? Is GoLang now fully supported? Thanks!

Hey @ffloresca,

Thanks for your question about Golang. Not much has changed in terms of our layers for Golang. We still don’t have a Golang-specific layer. The challenge as I understand it has to do with the fact that Go is a compiled language, so it’s not as easy to monkeypatch our wrapper around a Go function.

You’ll still need to use our legacy docs to manually instrument with our Go agent.
https://docs.newrelic.com/docs/serverless-function-monitoring/aws-lambda-monitoring/enable-lambda-monitoring/enable-serverless-monitoring-aws-lambda-legacy/#go

Some more exciting news is about OpenTelemetry. We’ve now got the preliminary docs up for Java and .NET functions to utilize a standard AWS OTEL layer which instruments the function and sends telemetry to our OTLP endpoint.

However, it appears that AWS does not yet have a Golang layer for OTEL either.

Our Go agent is still the “go-to” method for instrumenting Golang functions.