Git Product home page Git Product logo

newrelic-lambda-extension's Introduction

Community Plus header

newrelic-lambda-extension Build Status Coverage

An AWS Lambda extension to collect, enhance, and transport telemetry data from your AWS Lambda functions to New Relic without requiring an external transport such as CloudWatch Logs or Kinesis.

This lightweight AWS Lambda Extension runs alongside your AWS Lambda functions and automatically handles the collection and transport of telemetry data from supported New Relic serverless agents. The extension requires a telemetry payload from a New Relic agent. Conditions that delay or prevent that payload from being written may result in longer-than-expected invocation durations.

Installation

To install the extension, simply include the layer with your instrumented Lambda function. The current layer ARN can be found here.

Note: This extension is included with all New Relic AWS Lambda layers going forward.

You'll also need to make the New Relic license key available to the extension. Use the New Relic Lambda CLI to install the managed secret, and then add the permission for the secret to your Lambda execution role.

newrelic-lambda integrations install \
    --nr-account-id <account id> \
    --nr-api-key <api key> \
    --linked-account-name <linked account name> \
    --enable-license-key-secret

Each of the example functions in the examples directory has the appropriate license key secret permission.

After deploying your AWS Lambda function with one of the layer ARNs from the link above you should begin seeing telemetry data in New Relic.

See below for details on supported New Relic agents.

Supported Configurations

AWS's Extension API supports only a subset of all their runtimes. Notably absent as of this writing are Node JS before 10, Python before 3.7, Go (all versions), Dotnet before 3.1, and the older "java8" runtime, though "java8.al2" is supported.

For Go lambdas, we suggest using "provided" or "provided.al2". The Go example's deploy script contains compiler flags that produce a suitable self-hosting Go executable. See the Custom runtime docs for more details on this feature.

All of our layers include the extension, and the latest Agent version for the Layer's runtime. The latest layer version ARNs for your runtime and region are available here. The NewRelicLambdaExtension layer is suitable for Go, Java and Dotnet.

Building

Use the included Makefile to compile the extension.

make dist

This creates the extension binary in ./extensions/newrelic-lambda-extension. The binary is compiled for Amazon Linux, which is likely different from the platform you're working on.

Deploying

To publish the extension to your AWS account, run the following command:

    make publish

This packages the extension, and publishes a new layer version in your AWS account. Be sure that the AWS CLI is configured correctly. You can use the usual AWS CLI environment variables to control the account and region for the CLI.

Startup Checks

This Lambda Extension will perform a series of checks on initialization. Should any of these checks fail, the extension wil attempt to output troubleshooting recommendations to both CloudWatch Logs and New Relic Logs. If you have any issues using this extension, be sure to check your logs for messages starting with Startup check failed: for troubleshooting recommendations.

Startup checks include:

  • New Relic agent version checks
  • Lambda handler configuration checks
  • Lambda environment variable checks
  • Vendored New Relic agent checks

Disabling Extension

The New Relic Lambda Extension is enabled by default. To disable it, after adding or updating the Lambda layer, set the NEW_RELIC_LAMBDA_EXTENSION_ENABLED environment variable to false.

Testing

To test locally, acquire the AWS extension test harness first. Then:

TODO: Link to the AWS SDK that has the test harness, assuming it gets published.

  1. (Optional) Use the newrelic-lambda CLI to create the license key managed secret in your AWS account and region.

  2. Build the docker container for sample function code. Give it the tag lambda_ext.

    • Be sure to include your lambda function in the container.
  3. Start up your container.

    • Using AWS Secret Manager

         export AWS_ACCESS_KEY_ID=$(aws configure get aws_access_key_id --profile default)
         export AWS_SECRET_ACCESS_KEY=$(aws configure get aws_secret_access_key --profile default)
         export AWS_SESSION_TOKEN=$(aws configure get aws_session_token --profile default)
      
         docker run --rm -v $(pwd)/extensions:/opt/extensions -p 9001:8080 \
             -e AWS_ACCESS_KEY_ID -e AWS_SECRET_ACCESS_KEY -e AWS_SESSION_TOKEN \
             lambda_ext:latest \
             -h function.handler -c '{}' -t 60000
      
    • Or, setting the license key directly

         docker run --rm \
             -v $(pwd)/extensions:/opt/extensions \
             -p 9001:8080 \
             lambda_ext:latest \
             -h function.handler -c '{"NEW_RELIC_LICENSE_KEY": "your-license-key-here"}' -t 60000
      
  4. To invoke the sample lambda run:

    curl -XPOST 'http://localhost:9001/2015-03-31/functions/function.handler/invocations' \
        -d 'invoke-payload'
    
  5. Finally, you can exercise the container shutdown lifecycle event with:

     curl -XPOST 'http://localhost:9001/test/shutdown' \
         -d '{"timeoutMs": 5000 }'
    

Support

New Relic hosts and moderates an online forum where customers can interact with New Relic employees as well as other customers to get help and share best practices. Like all official New Relic open source projects, there's a related Community topic in the New Relic Explorers Hub. You can find this project's topic/threads in the Explorers Hub.

Contributing

We encourage your contributions to improve newrelic-lambda-extension! 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 [email protected].

License

newrelic-lambda-extension is licensed under the Apache 2.0 License. The newrelic-lambda-extension also uses 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.

newrelic-lambda-extension's People

Contributors

cdalton713 avatar chaudharysaket avatar codylandry avatar coreyarnold avatar dependabot[bot] avatar go-agent-robot avatar iamemilio avatar irishgordo avatar katiewest820 avatar kavinraja-g avatar kolanos avatar leslie-alldridge avatar mattwhelan avatar mirackara avatar mrickard avatar nc-holodakg avatar nr-swilloughby avatar umaannamalai avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

newrelic-lambda-extension's Issues

Use fixed port in the logsever

listener, err := net.Listen("tcp", host+":")

If log server starts listening on random port, and Lambda sandbox (function and extensions) is restarted, it can lose logs from the previous invocation or the log server could receive duplicate logs. Using a stable port in the same sandbox will guarantee exactly-once delivery of the logs. It also will reduce the memory utilization in the sandbox.

ARM64 Extension has intermittent delay (10 seconds+) after registering for logs

Description

I've just recently looked into using a .NET 6 lambda function on the ARM64 platform; however, when deploying it to that platform, we're seeing intermittent issues within the new-relic-extension layer (arn:aws:lambda:us-east-1:451483290750:layer:NewRelicLambdaExtensionARM64:10). Currently, the function timeout is 10 seconds and at times the entire function timeout is spent within the initialization of the extension.

I've enabled debug logging via NEW_RELIC_EXTENSION_LOG_LEVEL=DEBUG and have attached a Cloudwatch output of the function below.

While using this same function on the x86_64 platform and the corresponding layer (arn:aws:lambda:us-east-1:451483290750:layer:NewRelicLambdaExtension:26), I've seen no issues.

Steps to Reproduce

  • Create a .NET 6 AWS managed lambda targeting ARM64
  • Invoke function

Expected Behavior

The layer should not be adding this delay to the function execution.

Relevant Logs / Console output

image

License key sanity check isn't

Erroneous message from the sanity check added in #36 when passing the license key as an environment variable.

Description

I am manually adding the Python layer to a test function, passing the license key in as an environment variable. There is a message in the log on every cold start about how I should remove the environment variable because a Secrets Manager secret is also present. There is no Secrets Manager secret.

Steps to Reproduce

  1. Do not have a Secrets Manager secret containing the newrelic key
  2. Pass New Relic license key in NEW_RELIC_LICENSE_KEY environment variable on the lambda
  3. Invoke the lambda
  4. Check logs for

    [NR_EXT] Startup check failed: There is both a AWS Secrets Manager secret and a NEW_RELIC_LICENSE_KEY environment variable set. Recommend removing the NEW_RELIC_LICENSE_KEY environment variable and using the AWS Secrets Manager secret.

Expected Behavior

No warning message in the log about duplicate key provisioning.

Relevant Logs / Console output

[NR_EXT] Startup check failed: There is both a AWS Secrets Manager secret and a NEW_RELIC_LICENSE_KEY environment variable set. Recommend removing the NEW_RELIC_LICENSE_KEY environment variable and using the AWS Secrets Manager secret.

Your Environment

  • Python 3.8 lambda
  • layer:NewRelicPython38:33

Additional context

#36 added a sanity check for the license key. It does this by checking for the presence of the environment variable NEW_RELIC_LICENSE_KEY and by also calling credentials.GetLicenseKeyImpl() (here).

GetLicenseKeyImpl() itself falls back to returning the value in the environment variable if it is present and fetching from Secrets Manager failed (here).

The sanity check is not achieving what it aimed to do.

`NewRelicNodeJS14X:91` and higher is broken

Description

When upgrading a Node.js 14.x AWS Lambda from layer NewRelicNodeJS14X:90 to layer NewRelicNodeJS14X:91, the response is malformed and invalid.

Steps to Reproduce

Broken:

  • ARN: arn:aws:lambda:us-east-1:451483290750:layer:NewRelicNodeJS14X:91

Response from AWS Lambda Test functionality:

{
  "_events": {
    "listening": [
      null,
      null
    ]
  },
  "_eventsCount": 5,
  "_connections": 4,
  "_handle": {},
  "_usingWorkers": false,
  "_workers": [],
  "_unref": false,
  "allowHalfOpen": true,
  "pauseOnConnect": false,
  "httpAllowHalfOpen": false,
  "timeout": 0,
  "keepAliveTimeout": 5000,
  "maxHeadersCount": null,
  "headersTimeout": 60000,
  "requestTimeout": 0,
  "_socketPathSuffix": "4a31grt9zht",
  "_binaryTypes": [],
  "_pipeName": "/tmp/server-4a31grt9zht.sock",
  "_connectionKey": "-1:/tmp/server-4a31grt9zht.sock:-1",
  "_isListening": true
}

Expected Behavior

Works

  • ARN: arn:aws:lambda:us-east-1:451483290750:layer:NewRelicNodeJS14X:90

Response from AWS Lambda Test functionality:

{
  "statusCode": 200,
  "body": "{\"message\":\"pong\"}",
  "headers": {
    "x-powered-by": "Express",
    "content-type": "application/json; charset=utf-8",
    "content-length": "18",
    "etag": "W/\"12-6FyCUNJCdUkgXM8yXmM99u6fQw0\"",
    "date": "Tue, 07 Mar 2023 17:49:59 GMT",
    "connection": "close"
  },
  "isBase64Encoded": false
}

Relevant Logs / Console output

Logs from working version:

START RequestId: 69253d64-4f5d-4391-bf7c-3cdb616f990b Version: $LATEST
[1,"NR_LAMBDA_MONITORING","H4sIAAAAAAAAA9UZaU/bSPSvIGs/tYk995GqHxClh7bdRYKqH6oKDfZAXDm2a08gFPHf942dhDjEkLZZuutwjJ/fvPvy5CaYWGcS40wwuglMlQcj/3dkrupRZiZniRlN66E1tRvikVCac0k1loqOzqd57NIiHyX10EzdeJjYS5sV5cTmbmjKNBgEC5TTS1vV8B9o//F+/+Tw+AQe2pmNp81Tm1+mVZH7jYCx/+n49H3D+TQvEvu1xiycAX5ZFa6Ii+yOGBaDwFzArhX6OlQhDm4HwUIlUK9K49P29nM+zbIBFlIRjLnCIcV4cSsRChWmg8+fb4LcTCwQ+2AnRXUdHY2v6zQ2GZD9jAdKhAQjTSV/fCkZJSElXDImiNJIfPkyuEf+rTVl9LG2SUufgAKcKSkkUloxT+anQVKTUGi4J0wrjJHq5f/BzFr2FIVICIYE4VutNaKhVkoqJjVCEBu9LF5X1rY8cKjB/ERzhhHmnsrPQWgoONWMYyWw5Gyzef8q8jULcxFixjjFQGKbNQWuIUGKKk0UIUR0+RwcffTEq72TdDJXEOzDFBbqkQUilDSqEIaai94jfHxdOzvpkkZI697/kAAI26HcKGL00aVZ+t34tFshB0IQqYQUWDPEpaa7AbMQcUwx4kwjSARGmB2qHg17JEOIYQplh3KhESQVEjuD41BiTJVSDGFKqNTcDnE3eg8vobjU0ZVJ3VImjIiUkrJt1wjuuKAYfI4lk7wbO8fTsiwqZ85Aeedj1Re86KQyeW2a0llHx/bCV8baS0CgWPkfSAbIItal9cmerWxs0VGIscaEasS9MFwqLajgTXFq7iWGaGwUE5iBXfQ8EsFgjfQSdEFSEMqEEJyrBzieFM5ki0CdswZ+jNF5qdgkACQVIpj5dPZM+VISQjSSCrfbQAwIKEaUUJRSLLtueutc+SqtS+Pisa2eXvHocFZWtq7Bc28OT6LId8MoSc1FXtQujeuoTPOLZQCtsobGIKF+abZBrNU1Aq0huUFGKO9cErSVH35Qrk2uuCfgRqRNQERZ03YYJ1RQTmU3WPfLxM5+RED/CXH7e5/S3Om9SPPE+pAmSWavTLVqm29TC20iWqk6fr7RZKs1DbGC4gEpLu5Vt4eY2nb1Lk9dhzUiGqtlKC6jcRdwFXIYcrjiooUQqHfbWykFSVMDJdq28i7MwKSc52hnDQaBYXG+1tA7od5COEtMtG6jxHep7e01rTKbx4CQHJnKd7KO0aC5MLHVGkO4EsnAOsIO9dbsv9ZFvokxE0Boq7WfIDBcaGF+/iP8z4ppnuz5dHgsjUFRGCsk1stL7gaswX9EKSIoBL6/1t231sv2c5Nde/nmXbQpS+362Np8JWP956cp5e4hSmuF+vX8hSTqe2dZWHFzT4AhAsYHwedASnpRN++nUNKhpyjCYVRW0Ba3quI/JnS3b/ZL3MHbsLORFXou5lpA66RsQ/neUrLeqnw4c7YC50ZZAa9XYwjnaAy9/E4h6HmEyFZomKMo5Xz+ZnPv6d0aRCeQXpIAIsGAv5mnyTKw+NPwutMPuD6Zev8qo2066iCo46L81YHpN/TjXQn+/+jmv6zt758Fduawp50kdib2f2cO2ZVKv2uK6etJvXpt3553VYVB3sDMZ6JT6+egzvHmTQB2ttVlkVanNWR4MMLez4OgQa1Paz99jchtc9J5Zc9eTav22GXkWQMPeF1b2kwMAgdDSO3MpPQnroujUsnx4GeHrEGQPMZyeZQwuj+dBO668cPqYQcoV1VFFYzOTVZbf7jcerGr28Ksy8cH0CUPIKQdqHY7uLltbAfdq3bhxLpxkQAbiFYgvwBPqxRgvbG/QBtbk9iqDk0c29KfajtgCYE0yQamLLM0bqSKZh7yfLYOnWQvvr1EoR6kE3NhI/BROXgWPWuAagOXKbh7/6I9Pj+Y1q6Y7DUHkg1s79hVm4XzwQ07MKHw6i6VRmF7Jm+9l8LlsX9oJuZ7kZurOoyLCdDxq/a7gXDHXxh4ynMp33nbC+gPNBFsyM55MmRAaHh2LuMhjZMzgcW51uisK1AT48fFtIptuz5pgwXovzEOytl1Pz44y8dCw/nOKJg8sKNM17D7cSEpm8XKhseRj4wb+3i7Katidv38tn8HZOiFVxQQk+C2qWjruc398RmUkt6Upn0pvVXtXkvrFW6dbF49Ldoil9fS8mkTKy5yByZ+b/OLxg+Y//7s+7UC5XuZjxU3rQ+gzwMqdJcu/AQsCvC//2yo1mWR17bfIuoBrGXu3bnAjz8v9uKxn4Dcy6k7HyqI1i9fbm//ARNf/JmKHAAA"]
END RequestId: 69253d64-4f5d-4391-bf7c-3cdb616f990b
REPORT RequestId: 69253d64-4f5d-4391-bf7c-3cdb616f990b	Duration: 318.44 ms	Billed Duration: 319 ms	Memory Size: 128 MB	Max Memory Used: 128 MB	

Logs from non-working version:

START RequestId: 950b2d5a-d128-49df-ad18-7620ce8a1afc Version: $LATEST
END RequestId: 950b2d5a-d128-49df-ad18-7620ce8a1afc
REPORT RequestId: 950b2d5a-d128-49df-ad18-7620ce8a1afc	Duration: 650.31 ms	Billed Duration: 651 ms	Memory Size: 128 MB	Max Memory Used: 128 MB	Init Duration: 1860.57 ms	

Your Environment

Handler = newrelic-lambda-wrapper.handler
NEW_RELIC_ACCOUNT_ID = REDACTED
NEW_RELIC_DISTRIBUTED_TRACING_ENABLED = false
NEW_RELIC_LAMBDA_EXTENSION_ENABLED = false
NEW_RELIC_LAMBDA_HANDLER = lambda.handler
NEW_RELIC_LICENSE_KEY = REDACTED

Additional context

None

execution fails when using integration with sam local invoke

Description

Running the sam local invoke command does not succeed crashes when trying to start log server.

Steps to Reproduce

  1. Clone the repository.
  2. Change directory to the example for sam python
  3. Run sam build --use-container
  4. Run sam local invoke
  5. Application fails with lookup for sandbox

Expected Behavior

Start the log server as it does in a cloud deployment.

Relevant Logs / Console output

[NR_EXT] New Relic Lambda Extension starting up
Prepending Lambda task root to path: /var/task
Starting debugger...
[NR_EXT] Failed to start logs HTTP serverlisten tcp: lookup sandbox.localdomain on 192.168.65.7:53: no such host
panic: Failed to start logs HTTP serverlisten tcp: lookup sandbox.localdomain on 192.168.65.7:53: no such host

goroutine 1 [running]:
log.Panic({0xc0000b7ec8?, 0x9c0df8?, 0xc0001cea80?})
	/usr/local/go/src/log/log.go:388 +0x65
github.com/newrelic/newrelic-lambda-extension/util.Panic(...)
	/home/circleci/project/util/logger.go:82
main.main()
	/home/circleci/project/main.go:105 +0x5fb
25 May 2023 01:31:12,197 [ERROR] (rapid) Init failed error=exit status 2 InvokeID=
[NR_EXT] New Relic Lambda Extension starting up
Prepending Lambda task root to path: /var/task
Starting debugger...
[NR_EXT] Failed to start logs HTTP serverlisten tcp: lookup sandbox.localdomain on 192.168.65.7:53: no such host
panic: Failed to start logs HTTP serverlisten tcp: lookup sandbox.localdomain on 192.168.65.7:53: no such host

goroutine 1 [running]:
log.Panic({0xc0003b5ec8?, 0x9c0df8?, 0xc00008aac0?})
	/usr/local/go/src/log/log.go:388 +0x65
github.com/newrelic/newrelic-lambda-extension/util.Panic(...)
	/home/circleci/project/util/logger.go:82
main.main()
	/home/circleci/project/main.go:105 +0x5fb
END RequestId: da746be1-43c9-4929-b7f3-0202a42c4b56
REPORT RequestId: da746be1-43c9-4929-b7f3-0202a42c4b56	Init Duration: 0.34 ms	Duration: 2508.19 ms	Billed Duration: 2509 ms	Memory Size: 128 MB	Max Memory Used: 128 MB	

Command stopped: "sam local invoke"
2023-05-24 20:31:15 [INFO]: Attaching debugger to SAM application...```

## Your Environment

Windows 11 Enterprise 64-bit

## Additional context

Adding support for log levels of WARN and ERROR

Summary

In projects which use many lambdas that are invoked often, the logs written out by this layer that could be thought of as being of the "INFO" severity can really start to add up. The layer does use a NEW_RELIC_EXTENSION_LOG_LEVEL environment variable, but currently it only supports values of "INFO" and "DEBUG". I think it would be nice to have the options of "WARN" and "ERROR" as well so as to optionally omit the logs that are written over the course of normal, successful layer behavior.

Desired Behavior

I'm not sure that I've exhaustively identified each log that belongs to the INFO and WARN severities respectively, but I think the ones I have specifically linked should give a good idea of what I mean.

If the NEW_RELIC_EXTENSION_LOG_LEVEL environment variable is supplied with a value of either "WARN" or "ERROR", then many of the logs currently written over the course of normal, successful layer behavior ("INFO" logs) should not be written.

Such logs include

If the NEW_RELIC_EXTENSION_LOG_LEVEL environment variable is supplied with a value of "ERROR", then the following logs which represent information that is potentially problematic but not necessarily indicative of any failures ("WARN" logs) should not be written

Such logs include

And in both of the above cases, the existing DEBUG logs should not be written either.

Possible Solution

New Warnf, Warnln, Errorf, and Errorln functions could be added to /util/logger.go, similar to how there are currently Debugf, Debugln, Logf, and Logln functions.

The Logf and Logln functions could be renamed to Infof and Infoln.

Logs that report conceptual warnings would no longer be written via Logf and Logln and would instead be written via Warnf and Warnln.

Logs that report failures would no longer be written via Logf and Logln and would instead be written via Errorf and Errorln.

If the NEW_RELIC_EXTENSION_LOG_LEVEL environment variable were to be given a value of "ERROR", of all the aforementioned log functions, only Errorf and Errorln would actually write any logs if invoked.

If the NEW_RELIC_EXTENSION_LOG_LEVEL environment variable were to be given a value of "WARN", of all the aforementioned log functions, only Warnf, Warnln, Errorf, and Errorln would actually write any logs if invoked.

If the NEW_RELIC_EXTENSION_LOG_LEVEL environment variable were to be given a value of "INFO", of all the aforementioned log functions, only Infof, Infoln, Warnf, Warnln, Errorf, and Errorln would actually write any logs if invoked.

If the NEW_RELIC_EXTENSION_LOG_LEVEL environment variable were to be given a value of "DEBUG", then all of the aforementioned log functions would write logs if invoked.

Additional context

I'm willing to create a PR to add this functionality myself if you agree that it would be good to have.

Takes super long to execute

On some occasions it prolong my function execution to maximum time

Steps to Reproduce

not sure. a lot of invocations in a row.

Expected Behavior

Not to prolong my function execution for so much and cause unexpected costs on AWS. If it cannot deliver a message it should give up much faster.

Relevant Logs / Console output

	2021-10-26T11:17:49.299+02:00	[NR_EXT] Request failed. Ran out of retries after 3 attempts.
	2021-10-26T11:17:53.697+02:00	[NR_EXT] Telemetry client error: Post "https://log-api.newrelic.com/log/v1": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
	2021-10-26T11:17:56.579+02:00	[NR_EXT] Sent 0/1 New Relic function log batches successfully in 241457.663ms (35517ms to transmit 0.0kB).
	2021-10-26T11:17:57.238+02:00	{"v":0,"level":20,"name":"newrelic","hostname":"169.254.63.37","pid":17,"time":"2021-10-26T09:17:57.098Z","msg":"Not recording function setTimeout, not in a transaction.","component":"Shim","module":"timers"}
	2021-10-26T11:18:06.003+02:00	[NR_EXT] Request failed. Ran out of retries after 3 attempts.
	2021-10-26T11:18:10.465+02:00	[NR_EXT] Telemetry client error: Post "https://cloud-collector.newrelic.com/aws/lambda/v1": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
	2021-10-26T11:18:12.298+02:00	{"v":0,"level":20,"name":"newrelic","hostname":"169.254.63.37","pid":17,"time":"2021-10-26T09:18:12.159Z","msg":"Not recording function setTimeout, not in a transaction.","component":"Shim","module":"timers"}
	2021-10-26T11:18:13.761+02:00	[NR_EXT] Sent 0/1 New Relic payload batches with 1 log events successfully in 52017.034ms (38797ms to transmit 0.0kB).
	2021-10-26T11:18:13.898+02:00	[NR_EXT] New Relic Extension shutting down after 26 events
	2021-10-26T11:18:14.061+02:00	[NR_EXT] Sent 1/1 New Relic function log batches successfully in 16302.653ms (179ms to transmit 0.4kB).
	2021-10-26T11:18:14.099+02:00	[NR_EXT] Log server terminating: http: Server closed
	2021-10-26T11:18:14.100+02:00	[NR_EXT] http: panic serving 169.254.79.129:46010: send on closed channel
	2021-10-26T11:18:14.100+02:00	goroutine 30 [running]:
	2021-10-26T11:18:14.100+02:00	net/http.(*conn).serve.func1()
	2021-10-26T11:18:14.100+02:00	/usr/local/go/src/net/http/server.go:1801 +0xb9
	2021-10-26T11:18:14.100+02:00	panic({0x7e4300, 0x942dd0})
	2021-10-26T11:18:14.100+02:00	/usr/local/go/src/runtime/panic.go:1047 +0x266
	2021-10-26T11:18:14.100+02:00	github.com/newrelic/newrelic-lambda-extension/lambda/logserver.(*LogServer).handler(0xc00036d5c0, {0x94ec90, 0xc0000f4620}, 0xc0000a6700)
	2021-10-26T11:18:14.100+02:00	/home/circleci/project/lambda/logserver/logserver.go:164 +0x22a
	2021-10-26T11:18:14.100+02:00	net/http.HandlerFunc.ServeHTTP(0x4b4fe6, {0x94ec90, 0xc0000f4620}, 0xc0000f4620)
	2021-10-26T11:18:14.100+02:00	/usr/local/go/src/net/http/server.go:2046 +0x2f
	2021-10-26T11:18:14.100+02:00	net/http.(*ServeMux).ServeHTTP(0x0, {0x94ec90, 0xc0000f4620}, 0xc0000a6700)
	2021-10-26T11:18:14.100+02:00	/usr/local/go/src/net/http/server.go:2424 +0x149
	2021-10-26T11:18:14.100+02:00	net/http.serverHandler.ServeHTTP({0x94de78}, {0x94ec90, 0xc0000f4620}, 0xc0000a6700)
	2021-10-26T11:18:14.100+02:00	/usr/local/go/src/net/http/server.go:2878 +0x43b
	2021-10-26T11:18:14.100+02:00	net/http.(*conn).serve(0xc000108aa0, {0x950580, 0xc00026c030})
	2021-10-26T11:18:14.100+02:00	/usr/local/go/src/net/http/server.go:1929 +0xb08
	2021-10-26T11:18:14.100+02:00	created by net/http.(*Server).Serve
	2021-10-26T11:18:14.100+02:00	/usr/local/go/src/net/http/server.go:3033 +0x4e8
	2021-10-26T11:18:14.204+02:00	[NR_EXT] Sent 1/1 New Relic function log batches successfully in 143.268ms (142ms to transmit 1.0kB).
	2021-10-26T11:18:14.204+02:00	[NR_EXT] Extension shutdown after 813163ms
	2021-10-26T11:18:14.205+02:00	END RequestId: d43867d8-479d-4978-88d1-7510bed882d0
	2021-10-26T11:18:14.205+02:00	REPORT RequestId: d43867d8-479d-4978-88d1-7510bed882d0 Duration: 300699.81 ms Billed Duration: 300000 ms Memory Size: 512 MB Max Memory Used: 512 

Your Environment

  • node.js 14 using TypeScript
  • integration via serverless layers new relic plugin

New Relic Extension shutting down

Description

Primary code of my lambda processes the requests very quickly (~60ms), however the responses are not being sent back until New Relic engine times out (after 60s my configured lambda timeout). No idea why the extension shuts down.

Expected Behaviour

New Relic extension should not shut down and if it does it should have no impact on lambda sending back response even with the cost of loosing the metrics.
NOTE: # ( Tell us what you expected to happen. )

Relevant Logs / Console output

CleanShot 2023-08-23 at 18 38 57@2x

Your Environment

AWS Lambda + New relic lambda layer(3.10:7) integration via CLI
TIP: # ( Include as many relevant details about your environment as possible. )

Additional context

JSON logs are sent with cloudwatch log prefixes and not parsed

When writing JSON logs from the lambda (using, for example the AWS Power Tools Logger) the log message in New Relic is not parsed as JSON.

Description

The logs are not getting parsed as JSON because they are not being sent as JSON - they are including the cloudwatch log prefixes (timestamp, requestid, loglevel). The log message, when received in NewRelic looks like:

{
  "aws.lambda_request_id": "025f281a-8416-4f77-9271-27e90db13e12",
  "faas.execution": "025f281a-8416-4f77-9271-27e90db13e12",
  "faas.name": "test",
  "index": 859,
  "message": "2022-03-28T12:52:33.477Z\t025f281a-8416-4f77-9271-27e90db13e12\tINFO\t{\"cold_start\":false,\"function_arn\":\"arn:aws:lambda:eu-west-2:101:function:test\",...}\n",
  "newrelic.logPattern": "nr.DID_NOT_MATCH",
  "newrelic.source": "api.logs",
  "plugin": "newrelic-lambda-extension:2.1.0",
  "timestamp": 1648471953478
}

I was hoping that the newrelic lambda extension would allow me to take advantage of the JSON message parsing functionality, but due to the prefixes (and probably the trailing newline) this does not occur.

Steps to Reproduce

Sending any JSON to NewRelic via the lambda should recreate this problem.

console.log(JSON.stringify({"test": "this should be parsed by newrelic"})

Expected Behavior

JSON logs should be parsed using NewRelic's JSON message parsing functionality. Ideally there would be some configuration that could be toggled to let NewRelic know to expect JSON log messages, so it can remove leading/trailing characters.

I have looked through AWS's own documentation around this but have been unable to find anything that would allow configuration of the lambda console's output.

Dotnet core 6 support for lambda

From the code, it looks like the example provided works for dotnet3.1. However, AWS already deprecated it and LTS version is 6.x

Does the existing example just works? I presume so. Please revert if you think otherwise.

Thank you.

Dotnet sample is written by Opentracing(should replace to OTel )

Summary

Official docs is describe below.

New Relic provides OpenTelemetry SDKs for these runtimes. This approach requires a bit more code to integrate.

However sample code is witten by OpenTracing.
https://github.com/newrelic/newrelic-lambda-extension/blob/main/examples/sam/dotnet/src/NewRelicExampleDotnet/Function.cs

Desired Behavior

I think this sample should provide by Opentelemetry.

Possible Solution

Already explain above.

Additional context

If I instrument by Opentracing like sample above , lambda monitoring(by layer , extension) is work correctly?

README is out of date

https://github.com/newrelic/newrelic-lambda-extension/blob/main/examples/terraform/nodejs/README.md is out of date
[NOTE]: # ( ^^ Provide a general summary of the issue in the title above. ^^ )

Description

While trying to implement the example found in https://github.com/newrelic/newrelic-lambda-extension/blob/main/examples/terraform/nodejs I noticed that the instructions are out of date.

  1. The instructions refer to running newrelic-lambda install, but I believe the correct command is newrelic-lambda integrations install and it does not look like --enable-license-key-secret flag is still valid.
  2. Inside main.tf
data "aws_iam_policy" "newrelic_license_key_policy" {
  arn = "arn:aws:iam::${data.aws_caller_identity.current.account_id}:policy/ViewNewRelicLicenseKey"
}

throws an error since the policy created by the step in #1 has a different name.

There may be other problems and it would be great to get them fixed.

PHP Support

Summary

NewRelic has had a long history of supporting PHP, however I note this Lambda extension has no PHP support.

PHP already runs on Lambda quite well with the Bref (https://bref.sh) project. Bref has a NewRelic layer to bundle the php extension, but it currently requires a separate daemon server running elsewhere to ingest and forward logs. Your project seems to solve that problem by handling it locally in the Lambda function itself.

Desired Behavior

I'd like to be able to use Bref's NewRelic layer to install the NewRelic extension, and then use this layer to handles log ingestion and forwarding to NewRelic.

The desired result is a Lambda function that runs PHP and reports to NewRelic in a supported way, without needing any additional EC2 hosts configured to handle logging.

Possible Solution

  • Use the Bref layer for PHP in Lambda, with its NewRelic Bref extension layer for the php extension
  • Add this layer to the Lambda function
  • Configure the PHP module to talk to this agent (e.g. via newrelic.daemon.address)
  • Bottle all this into a README

Alternatives

  • If there's a way for the PHP extension to log into CloudWatch, then I know NewRelic has a way to subscribe to that.

I'm happy to help out here, but I don't currently understand how this lambda extension works differently to the newrelic daemon approach used by the PHP extension. If I can get some pointers to documentation on that or some tips, I'll be happy to run with it and contribute something if I'm successful.

Thanks!

Missing logs when function times out

Description

We have a lambda function that occasionally hits the 15-minute mark and times out. I noticed that no logs (errors or otherwise) show up in New Relic for these scenarios.

Steps to Reproduce

Based on our logs:

  1. Get a Lambda to run over 15 minutes using Python 3.8 and the layer ARN arn:aws:lambda:us-east-1:451483290750:layer:NewRelicPython38:51
  2. Find the CloudWatch logs for the logs, specifically the RequestId
  3. Look for the logs in New Relic and the RequestId above is missing.

Expected Behavior

  1. The RequestId shows up in New Relic logs
  2. New Relic reports an error

Relevant Logs / Console output

CloudWatch Log Insight query:

fields @timestamp, @requestId, @message
| filter @message like /(NR_EXT|START RequestId|REPORT|timed out)/
| sort @timestamp 

logs-insights-results.csv
The request that timed out was id e1a4b364-e0f5-4a27-a1dc-44a736937370

New Relic AwsLambdaInvocation query:

select timestamp, aws.requestId, duration  
from AwsLambdaInvocation 
where entityName = 'xyz' SINCE 3 days ago
Timestamp Aws.Request ID Duration
2021-10-29 13:22:25 c4e43c76-28de-4a78-8e95-43a695a91acd 791.6913824081421
2021-10-29 08:00:21 d8989ab2-a7e1-4abc-9f31-79480bf26467 49.77254390716553
2021-10-29 08:00:21 e5e0c7b2-9227-461e-83ce-c2db21b9dc2b 701.8979961872101
2021-10-29 08:00:21 63d224c4-112a-4f6f-aeda-fbea2b288a2c 178.43485140800476
2021-10-29 08:00:20 3d7059b0-3caf-45de-abb6-9befee05eea1 18.820170879364014

New Relic ServerlessSample query:

select timestamp, provider.errors.Sum, provider.duration.Maximum, provider.invocations.Sum 
from ServerlessSample 
where entityName = 'xyz' SINCE 3 days ago until 2 days ago
timestamp provider.errors.sum provider.duration.maximum provider.invocations.sum
October 29, 2021 08:22:00
October 29, 2021 03:00:00 0 178677.11 3

NOTE: I noticed in the ServerlessSample query results above, in addition to missing the timeout, it does not seem to include data for the RequestId e5e0c7b2-9227-461e-83ce-c2db21b9dc2b. Not counting the timeout, I would expect the second row to show something like:

  • provider.duration.maximum = 701897
  • provider.invocations.sum = 4

Your Environment

  • Lambda Runtime: Python 3.8
  • Layer ARN: arn:aws:lambda:us-east-1:451483290750:layer:NewRelicPython38:51
    • Should have been latest as of our last release, on 2021-10-10

Remove auto version update on lambda startup

Summary

Currently we use a proxy for outbound traffic, and we allow specific domains which can be accessed for security reason. Every time that the lambda starts, it tries to pull the latest version from github.
Adding github to our whitelisted domains can result in a risk which we dont want to present.

The error is:
[NR_EXT] There was an issue querying for the latest agent version: Get "https://github.com/newrelic/node-newrelic/releases/latest": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

Possible Solution

Please add an environment variable to control if version pulling is required or not on lambda startup.

distributed tracing sample fails because aws no longer supports Node12

Failed to deploy distributed tracing example

Description

https://github.com/newrelic/newrelic-lambda-extension/blob/main/examples/sam/distributedtracing
deploy fails. Node12 is no longer supported.

Steps to Reproduce

build and try to deploy the stack

Expected Behavior

it deploys

Relevant Logs / Console output

 {
            "StackId": "arn:aws:cloudformation:us-west-2:594264067293:stack/Newrelic-Dt-Example/c53d4a70-b619-11ee-b272-0a62e5f760df",
            "EventId": "NodeAndSQS-CREATE_FAILED-2024-01-18T15:54:19.945Z",
            "StackName": "Newrelic-Dt-Example",
            "LogicalResourceId": "NodeAndSQS",
            "PhysicalResourceId": "Newrelic-Dt-Example-NodeAndSQS-l9VrsMszTM8M",
            "ResourceType": "AWS::Lambda::Function",
            "Timestamp": "2024-01-18T15:54:19.945000+00:00",
            "ResourceStatus": "CREATE_FAILED",
            "ResourceStatusReason": "Resource handler returned message: \"The runtime parameter of nodejs12.x is no longer supported for creating or updating AWS Lambda functions. We recommend you use the new runtime (nodejs18.x) while creating or updating functions. (Service: Lambda, Status Code: 400, Request ID: 60869524-3114-4efa-81b6-bbdda5ad50a7)\" (RequestToken: a031f674-2db4-401e-38f0-e810be956bd4, HandlerErrorCode: InvalidRequest)",
            "ResourceProperties": "{\"Role\":\"arn:aws:iam::594264067293:role/Newrelic-Dt-Example-NodeAndSQSRole-fwkPvBC0z9RQ\",\"MemorySize\":\"128\",\"Runtime\":\"nodejs12.x\",\"Description\":\"A Lambda function that logs the payload of messages sent to an associated SQS queue.\",\"Timeout\":\"25\",\"PackageType\":\"Zip\",\"Handler\":\"newrelic-lambda-wrapper.handler\",\"Environment\":{\"Variables\":{\"NEW_RELIC_ACCOUNT_ID\":\"4257778\",\"NEW_RELIC_TRUSTED_ACCOUNT_KEY\":\"4257778\",\"SNS_TOPIC\":\"arn:aws:sns:us-west-2:594264067293:Newrelic-Dt-Example-SnsTopic-eOyFibvBV7mZ\",\"NEW_RELIC_LAMBDA_HANDLER\":\"src/handlers/sqs-sns-bridge.sqsHandler\"}},\"Code\":{\"S3Bucket\":\"newrelic-example-us-west-2-4257778\",\"S3Key\":\"c2e3aaa9f7f92c1fe03a4c7746a06d66\"},\"Layers\":[\"arn:aws:lambda:us-west-2:451483290750:layer:NewRelicNodeJS12X:44\"],\"Tags\":[{\"Value\":\"SAM\",\"Key\":\"lambda:createdBy\"}]}"
        }

Your Environment

Ubuntu linux.

Additional context

Manually updating the node version to Runtime: nodejs14.x in examples/sam/distributedtracing/template.yml fixed this, though that is also being retired soon.

Differentiate between logs from multiple lambdas having the same name

Summary

When multiple lambdas having the same name are instrumented, their logs all appear in one place in the New Relic UI.

Desired Behavior

Multiple lambdas with the same name should have their logs separated in the UI.

Possible Solution

It would be nice if the logs arrived with some other differentiator besides the name, which could be used by the UI to split up the logs. Currently it seems that the AWS account ID is not decorated on the logs which are sent, and this could be one approach. (Are lambda names unique per AWS account?)

Additional context

This affects prod/qa environments where both are instrumented and the lambda has the same name across environments.

terraform examples issue with policy arn

Description

When deploying python or node from examples/terraform/, I get "The argument "policy_arn" is required, but no definition was found."

Steps to Reproduce

cd examples/terraform/python #or node
terraform init
./deploy.sh MY_ACCOUNT_ID eu-west-1

Expected Behavior

A new lambda is deployed

Relevant Logs / Console output


region set to eu-west-1
Success! The configuration is valid.

data.aws_caller_identity.current: Refreshing state...
data.aws_iam_policy.newrelic_license_key_policy: Refreshing state...

Error: Missing required argument

  on main.tf line 24, in resource "aws_iam_role_policy_attachment" "newrelic_license_key_policy_attachment":
  24:   policy_arn = data.aws_iam_policy.newrelic_license_key_policy.arn

The argument "policy_arn" is required, but no definition was found.

Your Environment

  • linux mint 20.1
  • terraform: v0.14.6 (provider.aws v3.27.0). Also tested with v0.12.28

Additional context

I tried hardcoding policy_arn inline 24,
policy_arn = "arn:aws:iam::${data.aws_caller_identity.current.account_id}:policy/ViewNewRelicLicenseKey"
but then I got this error

Error: Error attaching policy arn:aws:iam::XXXXX:policy/ViewNewRelicLicenseKey to IAM Role newrelic_terraform_example_nodejs_role: NoSuchEntity: Policy arn:aws:iam::XXXXX:policy/ViewNewRelicLicenseKey does not exist or is not attachable.
	status code: 404, request id: XXXXX

Not related, but I guess that .terraform.lock.hcl shouldn't be in github right?

thanks

403 Forbidden error

Description

I have followed ALL the instructions found in the docs to install the New Relic AWS Lambda Telemetry extension.
Unfortunately, I could not find any related data in the Logs or Metrics & events.
I'm wondering if this issue is related to my account (should I upgrade it ???)

Steps to Reproduce

Expected Behavior

Relevant Logs / Console output

In the CloudWatch logs of the lambda, I realized the following error:
[NR_EXT] Telemetry client response: [403 Forbidden] {}
[NR_EXT] Sent 0/1 New Relic payload batches with 1 log events successfully in 272.606ms (272ms to transmit 0.4kB).

Your Environment

  • ex: Browser name and version:
  • ex: Operating System and version:

Additional context

Should agent version startup check warn on GET failure?

Current Behavior

If github.com is blocked in the firewall (a local artifactory repository is used instead), the GET operation will fail. Is there a good reason the current behavior is to return err rather than return nil?

func latestAgentTag(r *runtimeConfig) error {
resp, err := client.Get(r.agentVersionUrl)
if err != nil {
return err
}

The result is the following log line appears every time startup checks run:

[NR_EXT] There was an issue querying for the latest agent version: Get "https://github.com/newrelic/newrelic-python-agent/releases/latest": read tcp 169.254.76.1:58296->140.82.114.3:443: read: connection reset by peer

Expected Behavior

No error log lines would appear on GET failure in the following scenarios:

  1. Optional configuration to bypass the latest-version check.
  2. Optional configuration to check a different URL (like a local artifactory site) instead of GitHub
  3. Ignore GET failure with return nil.

trace.id Log Property is Always Empty String

Description

All of our lambda logs have the trace.id property set to any empty string instead of the actual trace ID.

Steps to Reproduce

Use the node newrelic lambda layer to lambda layer and ship logs to newrelic.

Expected Behavior

Logs should contain trace.id property that actually contains the ID of the corresponding trace.

Your Environment

Node v18
Lambda layer version: NewRelicNodeJS18X:48

Additional context

I noticed this comment in the code:

// There is a race condition here. Telemetry batch may be late, so the trace

I'm wondering if that's the source of the problem. Is there a workaround or way to fix this?

Is there a way to configure custom attributes or other metadata when sending logs directly (`NEW_RELIC_EXTENSION_SEND_FUNCTION_LOGS=true`)?

Summary

Hello,

When using this to send logs directly (NEW_RELIC_EXTENSION_SEND_FUNCTION_LOGS=true), is there a way to set custom attributes -- like common.attributes in Log API payloads?

Desired Behavior

To be clear, I don't mean via manually emitting JSON logs and directly embedding the attributes in them from the main function code. I'm asking if the extension provides a way to do it without code changes, and globally (for example it would apply to the START, END, REPORT events emitted automatically by the runtime.)

Possible Solution

I see that newrelic/aws-log-ingestion has an NR_TAGS environment variable to associate metadata with logs (I assume / it appears it actually means attributes rather than tags) and it seems like this could support something similar. I haven't implemented a Lambda extension, but I see that the documentation says they have access to the function's environment variables.

If using that approach to set attributes, I wouldn't name the variable "tags" though.

Additional context

This relates to my question about a way to attach attributes or other metadata (to identify environment, for example) across the (at least 4) ingestion methods.

On a related note, but outside the scope of this project, if you setup the AWS infrastructure integration, New Relic inventories Lambdas and their tags and creates an association between the entity and the logs. For example, you can browse to the entity and look at its logs, but it doesn't seem to expose a way to use the entity or its tags to filter logs in the Logs UI. If that was available this might be less relevant.

Thanks

New Relic Layer errors randomly

Description

Our kotlin Lambdas are producing error logs when running through the New Relic layer which are spamming our alert notifications. The logs provide no other details other than a Lambda runtime failure.
These only started appearing after integrating the layer and stopped when the layer was removed.

Steps to Reproduce

Intermittently happens after an unknown amount of time.

Expected Behavior

Does not cause the [ERROR] in the Lambda logs

Relevant Logs / Console output

| 1619106082000 | [NR_EXT] New Relic Lambda Extension starting up
| 1619106082210 | [NR_EXT] Starting log server.
| 1619106082212 | LOGS Name: newrelic-lambda-extension State: Subscribed Types: [platform,function]
| 1619106088310 | [2021-04-22 15:41:27.295] " + NO_REQUEST_ID + " INFO c.a.i.DefaultServiceEndpointBuilder - {rds-data, eu-west-1} was not found in region metadata, trying to construct an endpoint using the standard pattern for this region: 'rds-data.eu-west-1.amazonaws.com'.
| 1619106089032 | [NR_EXT] Sent 1/1 New Relic function log batches successfully in 216.247ms (214ms to transmit 0.4kB).
| 1619106090709 | EXTENSION Name: newrelic-lambda-extension State: Ready Events: [INVOKE,SHUTDOWN]
| 1619109040622 | [ERROR] [1619109040622] LAMBDA_RUNTIME Failed to get next invocation. No Response from endpoint
| 1619109040627 | [NR_EXT] New Relic Extension shutting down after 1 events
| 1619109040828 | [NR_EXT] Extension shutdown after 2958806ms

Your Environment

Runtime: Java 11 (Cornetto)
AWS Lambda core version: 1.2.1
Handler: Implementation of the RequestHandler

Additional details

This happened when using both the NewRelicJava11:1 and NewRelicLambdaExtension:11 layers

send on closed channel panic at logserver/logserver.go:185

Description

The lambda function we use with this extension periodically crashes at this line

ls.functionLogChan <- functionLogs

Steps to Reproduce

I have no specific steps, sorry. We just run the extension along with our production lambda.

Expected Behavior

No panics.

Relevant Logs / Console output

[NR_EXT] Log server terminating: http: Server closed
[NR_EXT] http: panic serving X.X.X.X:55518: send on closed channel

goroutine 36 [running]:
26
	2023-09-14T09:41:00.133+02:00
	net/http.(*conn).serve.func1()
27
	2023-09-14T09:41:00.133+02:00
	/usr/local/go/src/net/http/server.go:1850 +0xbf
28
	2023-09-14T09:41:00.133+02:00
	panic({0x980920, 0xce7e60})
29
	2023-09-14T09:41:00.133+02:00
	/usr/local/go/src/runtime/panic.go:890 +0x262
30
	2023-09-14T09:41:00.133+02:00
	/home/circleci/project/lambda/logserver/logserver.go:185 +0x276
31
	2023-09-14T09:41:00.133+02:00
	net/http.HandlerFunc.ServeHTTP(0xc0000ea2a0?, {0xcef040?, 0xc0000ea2a0?}, 0xa4245f?)
32
	2023-09-14T09:41:00.133+02:00
	/usr/local/go/src/net/http/server.go:2109 +0x2f
33
	2023-09-14T09:41:00.133+02:00
	net/http.(*ServeMux).ServeHTTP(0x0?, {0xcef040, 0xc0000ea2a0}, 0xc000384f00)
34
	2023-09-14T09:41:00.133+02:00
	/usr/local/go/src/net/http/server.go:2487 +0x149
35
	2023-09-14T09:41:00.133+02:00
	net/http.serverHandler.ServeHTTP({0xcee0c8?}, {0xcef040, 0xc0000ea2a0}, 0xc000384f00)
36
	2023-09-14T09:41:00.133+02:00
	/usr/local/go/src/net/http/server.go:2947 +0x30c
37
	2023-09-14T09:41:00.133+02:00
	net/http.(*conn).serve(0xc00008c8c0, {0xcef520, 0xc000387b00})
38
	2023-09-14T09:41:00.133+02:00
	/usr/local/go/src/net/http/server.go:1991 +0x607
39
	2023-09-14T09:41:00.133+02:00
	created by net/http.(*Server).Serve
40
	2023-09-14T09:41:00.133+02:00
	/usr/local/go/src/net/http/server.go:3102 +0x4db

Your Environment

Extension version:

arn:aws:lambda:eu-west-1:451483290750:layer:NewRelicLambdaExtension:33

Event API support?

Will the extension forward custom events or be used to report handled errors?

agent -> extension -> newrelic api

nodejs 14 lambda log duration over 120 seconds

Description

[NR_NEXT] Extension shutdown after 121464ms ! And this causes our lambda timeout.

Steps to Reproduce

Expected Behavior

Relevant Logs / Console output

image

Your Environment

AWS nodejs 14 lambda runtime
TIP: # ( Include as many relevant details about your environment as possible. )
AWS Region: eu-west-1
Nodejs14
and Newrelic arn: arn:aws:lambda:eu-west-1:451483290750:layer:NewRelicNodeJS14X:84

Additional context

Node Handler check, is not handling mjs file extension

Description

The node handler check is not handling the file extension for esm modules (mjs) correctly, so you always see as an error in aws lambdas, and this is misleading
[NR_EXT] Startup check failed: Missing handler file newrelic-lambda-wrapper.handler

Steps to Reproduce

  • have a mjs file as a handler
  • the check will tell that the handler is not found as it only looks for js files

Expected Behavior

  • handle mjs files

I'm happy to provide a pr to fix this issue

Readme appears to incorrectly state Extension is disabled by default

Readme file statement:

The New Relic Lambda Extension is disabled by default. To enable it, after adding or updating the Lambda layer, set the NEW_RELIC_LAMBDA_EXTENSION_ENABLED environment variable to any value.

However code block appears to show enabled-by-default:

enabledStr, extensionEnabledOverride := os.LookupEnv("NEW_RELIC_LAMBDA_EXTENSION_ENABLED")

extensionEnabled := true
if extensionEnabledOverride && "false" == strings.ToLower(enabledStr) {
    extensionEnabled = false
}

func ConfigurationFromEnvironment() Configuration {

`make dist` *** No rule to make target `dist'

Description

Looks like the documentation is outdated and has missing steps (may be obvious for go developers but not that much for others): make dist
Expected results by the docs: "This creates the extension binary in ./extensions/newrelic-lambda-extension."
Actual result: "make: *** No rule to make target `dist'. Stop."

License key cannot be loaded from Parameter Store

Summary

Currently the New Relic license key can only configured as an environment variable, or as a secret from Secrets Manager. We would also like to load our license key from SSM Parameter Store.

Desired Behavior

Setting an environment variable named NEW_RELIC_LICENSE_KEY_PARAMETER or similar would cause this extension to load a license key from the given parameter.

Possible Solution

I'm willing to open a PR if this feature would be acceptable.

Additional context

AWS Secrets Manager and AWS SSM Parameter Store can both be used for storing sensitive values. Our organization currently prefers Parameter Store, and several internal projects already load a New Relic license key from Parameter Store. It would be nice if lambdas could also utilize the same parameter, instead of having to duplicate the license key in Secrets Manager.

Layer Errors prevent the "main" Lambda to get executed

Description

We recently instrumented all our node.js Lambdas with the NR Layer and noticed by an accident (wrong VPC Config for one Lambda), that if the NR Collector could not be reached in 5.0 Seconds, the "main" Lambda is not being executed. This will add a hard dependency to NewRelic in our Setup.

Steps to Reproduce

Create a Lambda in a private VPC which can not reach the NR Collector

Expected Behaviour

Just log the timeout and execute the "main" Lambda

Relevant Logs / Console output

timestamp,message
1617087177609,"[NR_EXT] New Relic Lambda Extension starting up
1617087187732,"START RequestId: 26922b09-3892-472f-b30e-040960748b43 Version: $LATEST
1617087188692,"[NR_EXT] New Relic Lambda Extension starting up
1617087190735,"EXTENSION	Name: newrelic-lambda-extension	State: Registered	Events: [INVOKE,SHUTDOWN]
1617087192737,"END RequestId: 26922b09-3892-472f-b30e-040960748b43
1617087192737,"REPORT RequestId: 26922b09-3892-472f-b30e-040960748b43	Duration: 5004.28 ms	Billed Duration: 3000 ms	Memory Size: 128 MB	Max Memory Used: 28 MB	
1617087192737,"2021-03-30T06:53:12.736Z 26922b09-3892-472f-b30e-040960748b43 Task timed out after 5.00 seconds

[Question] Java error Logs Events

Hi,

In our lambdas (Java) will always return a success execution, if we found errors we catch it and log it as error and then continue with normal execution.
This log error that are on cloudwatch will be show up on New Relic dashboard to then able to detected them with Incidents/alerts ? or only bad lambda executions will show up?

If the answer is yes:
what format of log error new relic will detect it? there is a pattern? configuration to change this?

If no, how I can achieve this? what alternatives I can do?

Duplicates Logs

Description

Hi guys.

Actually have a problem with the logs because i am watching that when send logs in new relic not everything but it duplicates some logs for me.

As you can see the unique argument that changes is the index but the content log message is equals. This error are reproduce in other lambdas that have in my account of AWS.

Attach image for you help me.

Steps to Reproduce

  • Lambda Layers NodeJS and Python

Expected Behavior

Not duplicated logs in my account of New Relic

Relevant Logs / Console output

Screen Shot 2022-07-28 at 12 32 51
Screen Shot 2022-07-28 at 12 32 45

Your Environment

  • Lambda 12.x, 14.x
  • Python 3.x
  • NEW_RELIC_EXTENSION_SEND_FUNCTION_LOGS = true

The description about command "newrelic-lambda" can be updated

Description

The description about command "newrelic-lambda" can be updated in the following README file;
https://github.com/newrelic/newrelic-lambda-extension/blob/main/examples/sam/go/README.md#prerequisites

Today it is described as following;

Make sure you've run the newrelic-lambda install command in your AWS Region, and included the --enable-license-key-secret flag.

However newrelic-lambda install doesn't work today and it should be newrelic-lambda integrations install and flag --enable-license-key-secret is replaced new flag --disable-license-key-secret

Steps to Reproduce

n/a

Expected Behavior

n/a

Relevant Logs / Console output

n/a

Your Environment

  • ex: Browser name and version:
  • ex: Operating System and version:

Additional context

GO SAM sample logging errors

[NOTE]: # /var/task/bootstrap: /lib64/libc.so.6: version `GLIBC_2.34' not found

Description

Seeing /var/task/bootstrap: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by /var/task/bootstrap) in aws cloudwatch logs.

Steps to Reproduce

  1. build the example.
  2. send it a test message.

Expected Behavior

No errors.

Relevant Logs / Console output

[NR_EXT] New Relic Lambda Extension starting up
/var/task/bootstrap: /lib64/libc.so.6: version GLIBC_2.32' not found (required by /var/task/bootstrap) /var/task/bootstrap: /lib64/libc.so.6: version GLIBC_2.34' not found (required by /var/task/bootstrap)
EXTENSION Name: newrelic-lambda-extension State: Registered Events: [INVOKE, SHUTDOWN]
INIT_REPORT Init Duration: 86.89 ms Phase: init Status: error Error Type: Runtime.ExitError

Your Environment

aws

  • ex: Browser name and version:
  • ex: Operating System and version:

Additional context

Function logs sometimes send in subsequent invocation

Description

Because the main loop and the function log loop are running completely independently, it sometimes happens that Lambda runtime freezes before the function logs are sent to New Relic.

Expected Behavior

Function logs are send within the same Lambda invocation as they are produced.

Relevant Logs / Console output

Screenshot 2021-01-22 at 13 08 24

These are the logs for a Lambda function that is invoked every 5 minutes. You can see from the 300000ms response time, that the logs are actually send in the subsequent Lambda invocation.

fatal error: concurrent map read and map write

Description

We are currently seeing an intermittent fatal error: concurrent map read and map write error. A CloudWatch log containing one example is below

Steps to Reproduce

I haven't found a reliable way to reproduce this

Relevant Logs / Console output

1660167744499	"REPORT RequestId: e1ccb62f-fb7f-480b-87fd-e46a82237f66	Duration: 175.16 ms	Billed Duration: 176 ms	Memory Size: 10240 MB	Max Memory Used: 131 MB	"
1660167744816	"START RequestId: 8cf373d8-fddd-4337-b089-a3c3e8320bde Version: $LATEST"
1660167744816	"[NR_EXT] Sent 1/1 New Relic function log batches successfully in 323.743ms (322ms to transmit 2.0kB)."
1660167744818	"START RequestId: 96844507-9d12-4b09-a9e6-2ac1d9a97ca0 Version: $LATEST"
1660167744818	"[NR_EXT] Sent 1/1 New Relic function log batches successfully in 4032.514ms (4032ms to transmit 0.6kB)."
1660167744821	"START RequestId: d97aed5d-637e-4fae-b1f3-3f4241c86f42 Version: $LATEST"
1660167744823	"fatal error: concurrent map read and map write"
1660167744826	
1660167744826	"goroutine 24 [running]:"
1660167744826	"runtime.throw({0x875619, 0x80})"
1660167744826	"/usr/local/go/src/runtime/panic.go:1198 +0x71 fp=0xc00005fc90 sp=0xc00005fc60 pc=0x4349d1"
1660167744826	runtime.mapaccess2_faststr(0x7f9120, 
1660167744826	"0xc000464630, {0xc0003e0030, 0x24})"
1660167744826	"/usr/local/go/src/runtime/map_faststr.go:116 +0x3d4 fp=0xc00005fcf8 sp=0xc00005fc90 pc=0x413d74"
1660167744826	"github.com/newrelic/newrelic-lambda-extension/telemetry.(*Batch).RetrieveTraceID(...)"
1660167744826	"/home/circleci/project/telemetry/batch.go:151"
1660167744826	"github.com/newrelic/newrelic-lambda-extension/telemetry.(*Client).SendFunctionLogs(0xc0000bc4b0, {0x9740b8, 0xc000076ac0}, {0xc00029a500, 0x4, 0x0})"
1660167744826	"/home/circleci/project/telemetry/client.go:202 +0x645 fp=0xc00005ff18 sp=0xc00005fcf8 pc=0x7b05e5"
1660167744826	main.logShipLoop(
1660167744826	"{0x9740b8, 0xc000076ac0}, 0xc0002a6140, 0x0)"
1660167744826	"/home/circleci/project/main.go:172 +0x89 fp=0xc00005ff90 sp=0xc00005ff18 pc=0x7b3a69"
1660167744826	"main.main.func4()"
1660167744826	"/home/circleci/project/main.go:139 +0x68 fp=0xc00005ffe0 sp=0xc00005ff90 pc=0x7b3768"
1660167744826	"runtime.goexit()"
1660167744826	/usr/local/go/src/runtime/asm_amd64.s:1581
1660167744826	" +0x1 fp=0xc00005ffe8 sp=0xc00005ffe0 pc=0x464701"
1660167744826	"created by main.main"
1660167744826	"/home/circleci/project/main.go:137 +0xba5"
1660167744826	
1660167744826	goroutine
1660167744826	"1 [runnable]:"
1660167744826	github.com/newrelic/newrelic-lambda-extension/telemetry.LogsEventForBytes({0xc00036a090, 0x90, 
1660167744826	"0x90})"
1660167744826	/home/circleci/project/telemetry/request.go:88 +0xe5
1660167744826	
1660167744826	github.com/newrelic/newrelic-lambda-extension/telemetry.(*Client).SendTelemetry(
1660167744826	0xc0000bc4b0, {0x9740b8, 0xc000076ac0}, {
1660167744826	"0xc0005381c0, 0x3e}, {0xc000294510, 0x6, 0x9})"
1660167744826	/home/circleci/project/telemetry/client.go:88 +
1660167744826	"0x47b"
1660167744826	main.shipHarvest({0x9740b8
1660167744826	, 0xc000076ac0}, {0xc00006cd80, 0x3, 
1660167744826	0xbd0520}, 0xc00, 
1660167744826	{0xc0005381c0, 0x3e}
1660167744826	")"
1660167744826	/home/circleci/project/main.go:
1660167744826	"319 +0x1fb"
1660167744826	main.mainLoop({0x9740b8
1660167744826	, 0xc000076ac0}, 0xc0000a00f0
1660167744826	, 0xc0000bc050, 0xc0000c8180, 
1660167744826	"0x28, 0x0)"
1660167744826	
1660167744826	"/home/circleci/project/main.go:272 +0x6f1"
1660167744826	main.main(
1660167744826	")"
1660167744826	/home/circleci/project/main.go:143 +
1660167744826	"0xbe5"
1660167744826	
1660167744826	goroutine 18
1660167744826	" [syscall, 18 minutes]:"
1660167744826	os/signal.signal_recv(
1660167744826	")"
1660167744826	/usr/local/go/src/runtime/sigqueue.go:
1660167744826	"169 +0x98"
1660167744826	"os/signal.loop()"
1660167744826	"/usr/local/go/src/os/signal/signal_unix.go:24 +0x19"
1660167744826	"created by os/signal.Notify.func1.1"
1660167744826	"/usr/local/go/src/os/signal/signal.go:151 +0x2c"
1660167744826	
1660167744826	"goroutine 34 [chan receive, 18 minutes]:"
1660167744826	"main.main.func1()"
1660167744826	"/home/circleci/project/main.go:41 +0x35"
1660167744826	created by main.main
1660167744826	
1660167744826	"/home/circleci/project/main.go:40 +0x173"
1660167744826	
1660167744826	"goroutine 35 [chan receive, 18 minutes]:"
1660167744826	"main.main.func2()"
1660167744826	"/home/circleci/project/main.go:50 +0x45"
1660167744826	"created by main.main"
1660167744826	"/home/circleci/project/main.go:49 +0x22f"
1660167744826	
1660167744826	"goroutine 38 [IO wait]:"
1660167744826	"internal/poll.runtime_pollWait(0x7f0b2883eeb0, 0x72)"
1660167744826	"/usr/local/go/src/runtime/netpoll.go:234 +0x89"
1660167744826	"internal/poll.(*pollDesc).wait(0xc00028c200, 0xc0002c6000, 0x0)"
1660167744826	"/usr/local/go/src/internal/poll/fd_poll_runtime.go:84 +0x32"
1660167744826	"internal/poll.(*pollDesc).waitRead(...)"
1660167744826	/usr/local/go/src/internal/poll/fd_poll_runtime.go:89
1660167744826	
1660167744826	"internal/poll.(*FD).Read(0xc00028c200, {0xc0002c6000, 0x1000, 0x1000})"
1660167744826	"/usr/local/go/src/internal/poll/fd_unix.go:167 +0x25a"
1660167744826	net.(*netFD).Read(0xc00028c200, {0xc0002c6000, 0x437527, 0xc00005cc30}
1660167744826	")"
1660167744826	"/usr/local/go/src/net/fd_posix.go:56 +0x29"
1660167744826	net.(*conn).Read(0xc0002a2068, {0xc0002c6000, 
1660167744826	"0x88d330, 0xc0000001a0})"
1660167744826	/usr/local/go/src/net/net.go:183
1660167744826	" +0x45"
1660167744826	net/http.(*persistConn).Read(0xc0002b2240, {
1660167744826	"0xc0002c6000, 0xc0002ae3c0, 0xc00005cd30})"
1660167744826	
1660167744826	"/usr/local/go/src/net/http/transport.go:1926 +0x4e"
1660167744826	bufio.(*Reader).fill
1660167744826	"(0xc00028e3c0)"
1660167744826	/usr/local/go/src/bufio/bufio.go:101 +0x103
1660167744826	
1660167744826	"bufio.(*Reader).Peek(0xc00028e3c0, 0x1)"
1660167744826	"/usr/local/go/src/bufio/bufio.go:139 +0x5d"
1660167744826	net/http.(*persistConn).readLoop(0xc0002b2240
1660167744826	")"
1660167744826	/usr/local/go/src/net/http/transport.go:
1660167744826	"2087 +0x1ac"
1660167744826	created by net/http.(*Transport).dialConn
1660167744826	
1660167744826	/usr/local/go/src/net/http/transport.go:
1660167744826	"1747 +0x1e05"
1660167744826	
1660167744826	goroutine 39 [
1660167744826	"select]:"
1660167744826	net/http.(*persistConn).writeLoop(
1660167744826	"0xc0002b2240)"
1660167744826	"/usr/local/go/src/net/http/transport.go:2386 +0xfb"
1660167744826	"created by net/http.(*Transport).dialConn"
1660167744826	/usr/local/go/src/net/http/transport.go:1748 +0x1e65
1660167744826	
1660167744826	
1660167744826	goroutine 40 [IO wait, 18
1660167744826	" minutes]:"
1660167744826	"internal/poll.runtime_pollWait(0x7f0b2883ece0, 0x72)"
1660167744826	"/usr/local/go/src/runtime/netpoll.go:234 +0x89"
1660167744826	"internal/poll.(*pollDesc).wait(0xc00028c380, 0x203000, 0x0)"
1660167744826	/usr/local/go/src/internal/poll/fd_poll_runtime.go
1660167744826	":84 +0x32"
1660167744826	"internal/poll.(*pollDesc).waitRead(...)"
1660167744826	"/usr/local/go/src/internal/poll/fd_poll_runtime.go:89"
1660167744826	internal/poll.(*FD).Accept(
1660167744826	"0xc00028c380)"
1660167744826	/usr/local/go/src/internal/poll/fd_unix.go:402 +
1660167744826	"0x22c"
1660167744826	net.(*netFD).accept(0xc00028c380
1660167744826	")"
1660167744826	"/usr/local/go/src/net/fd_unix.go:173 +0x35"
1660167744826	"net.(*TCPListener).accept(0xc000280198)"
1660167744826	/usr/local/go/src/net/tcpsock_posix.go
1660167744826	":140 +0x28"
1660167744826	"net.(*TCPListener).Accept(0xc000280198)"
1660167744826	"/usr/local/go/src/net/tcpsock.go:262 +0x3d"
1660167744826	"net/http.(*Server).Serve(0xc0002e2000, {0x972620, 0xc000280198})"
1660167744826	/usr/local/go/src/net/http/server.go
1660167744826	":3002 +0x394"
1660167744826	"github.com/newrelic/newrelic-lambda-extension/lambda/logserver.startInternal.func1()"
1660167744826	/home/circleci/project/lambda/logserver/logserver.go:217 +
1660167744826	"0x85"
1660167744826	"created by github.com/newrelic/newrelic-lambda-extension/lambda/logserver.startInternal"
1660167744826	/home/circleci/project/lambda/logserver/logserver.go:215 +0x292
1660167744826	
1660167744826	
1660167744826	"goroutine 22 [syscall]:"
1660167744826	syscall.Syscall6(0x101
1660167744826	", 0xffffffffffffff9c, 0xc0000c01f8, 0x80000, 0x0, 0x0, 0x0)"
1660167744826	/usr/local/go/src/syscall/asm_linux_amd64.s:43 +0x5
1660167744826	
1660167744826	syscall.openat(0x489226
1660167744826	, {0x86e385, 0x46252e}, 0x437527, 0x0
1660167744826	")"
1660167744826	"/usr/local/go/src/syscall/zsyscall_linux_amd64.go:69 +0x105"
1660167744826	"syscall.Open(...)"
1660167744826	/usr/local/go/src/syscall/syscall_linux.go
1660167744826	":155"
1660167744826	os.openFileNolog({0x86e385, 0xc0000ceee0}, 0x0
1660167744826	", 0x0)"
1660167744826	/usr/local/go/src/os/file_unix.go:217 +
1660167744826	"0x9b"
1660167744826	"os.OpenFile({0x86e385, 0x17}, 0x0, 0x3)"
1660167744826	/usr/local/go/src/os/file.go
1660167744826	":338 +0x45"
1660167744826	"github.com/newrelic/newrelic-lambda-extension/telemetry.pollForTelemetry()"
1660167744826	/home/circleci/project/telemetry/ipc.go
1660167744826	":35 +0x5e"
1660167744826	"github.com/newrelic/newrelic-lambda-extension/telemetry.InitTelemetryChannel.func1()"
1660167744826	/home/circleci/project/telemetry/ipc.go:26 +0x25
1660167744826	
1660167744826	"created by github.com/newrelic/newrelic-lambda-extension/telemetry.InitTelemetryChannel"
1660167744826	"/home/circleci/project/telemetry/ipc.go:24 +0xa5"
1660167744826	
1660167744826	goroutine
1660167744826	"61 [runnable]:"
1660167744826	"syscall.write(0xc, {0xc00075e000, 0x4b, 0x1000})"
1660167744826	
1660167744826	"/usr/local/go/src/syscall/zsyscall_linux_amd64.go:908 +0xfc"
1660167744826	"syscall.Write(...)"
1660167744826	/usr/local/go/src/syscall/syscall_unix.go:214
1660167744826	
1660167744826	"internal/poll.ignoringEINTRIO(...)"
1660167744826	"/usr/local/go/src/internal/poll/fd_unix.go:582"
1660167744826	internal/poll.(*FD).Write
1660167744826	"(0xc000160800, {0xc00075e000, 0x4b, 0x1000})"
1660167744826	/usr/local/go/src/internal/poll/fd_unix.go:275
1660167744826	" +0x36e"
1660167744826	"net.(*netFD).Write(0xc000160800, {0xc00075e000, 0x0, 0x0})"
1660167744826	"/usr/local/go/src/net/fd_posix.go:74 +0x29"
1660167744826	net.(*conn).Write(0xc0000b6160, {
1660167744826	"0xc00075e000, 0xa, 0x0})"
1660167744826	"/usr/local/go/src/net/net.go:195 +0x45"
1660167744826	net/http.checkConnErrorWriter.Write({
1660167744826	"0x612f6f}, {0xc00075e000, 0x0, 0x614c0e})"
1660167744826	
1660167744826	"/usr/local/go/src/net/http/server.go:3533 +0x33"
1660167744826	"bufio.(*Writer).Flush(0xc0000a4780)"
1660167744826	"/usr/local/go/src/bufio/bufio.go:607 +0x62"
1660167744826	"net/http.(*response).finishRequest(0xc0007061c0)"
1660167744826	
1660167744826	"/usr/local/go/src/net/http/server.go:1609 +0x76"
1660167744826	"net/http.(*conn).serve(0xc0000dc640, {0x974160, 0xc0000a6900})"
1660167744826	/usr/local/go/src/net/http/server.go:1935 +
1660167744826	"0xb3f"
1660167744826	"created by net/http.(*Server).Serve"
1660167744826	"/usr/local/go/src/net/http/server.go:3034 +0x4e8"
1660167744826	
1660167744826	goroutine 518 [
1660167744827	"IO wait]:"
1660167744827	"internal/poll.runtime_pollWait(0x7f0b2883eb10, 0x72)"
1660167744827	"/usr/local/go/src/runtime/netpoll.go:234 +0x89"
1660167744827	"internal/poll.(*pollDesc).wait(0xc000160880, 0xc0003a4000, 0x0)"
1660167744827	"/usr/local/go/src/internal/poll/fd_poll_runtime.go:84 +0x32"
1660167744827	"internal/poll.(*pollDesc).waitRead(...)"
1660167744827	/usr/local/go/src/internal/poll/fd_poll_runtime.go:89
1660167744827	
1660167744827	"internal/poll.(*FD).Read(0xc000160880, {0xc0003a4000, 0x1363, 0x1363})"
1660167744827	"/usr/local/go/src/internal/poll/fd_unix.go:167 +0x25a"
1660167744827	net.(*netFD).Read(0xc000160880
1660167744827	", {0xc0003a4000, 0xc0003a4005, 0x22a})"
1660167744827	"/usr/local/go/src/net/fd_posix.go:56 +0x29"
1660167744827	net.(*conn).Read(0xc0000101e8, {0xc0003a4000, 0xc00002a0a0, 
1660167744827	"0xc0000d17f8})"
1660167744827	/usr/local/go/src/net/net.go:183 +
1660167744827	"0x45"
1660167744827	crypto/tls.(*atLeastReader).Read(0xc00000e228
1660167744827	", {0xc0003a4000, 0x0, 0x40b08d})"
1660167744827	/usr/local/go/src/crypto/tls/conn.go:
1660167744827	"777 +0x3d"
1660167744827	bytes.(*Buffer).ReadFrom
1660167744827	"(0xc00021a5f8, {0x96b540, 0xc00000e228})"
1660167744827	/usr/local/go/src/bytes/buffer.go
1660167744827	":204 +0x98"
1660167744827	crypto/tls.(*Conn).readFromUntil(0xc00021a380
1660167744827	", {0x96bc00, 0xc0000101e8}, 0x46252e)"
1660167744827	/usr/local/go/src/crypto/tls/conn.go:799
1660167744827	" +0xe5"
1660167744827	crypto/tls.(*Conn).readRecordOrCCS
1660167744827	"(0xc00021a380, 0x0)"
1660167744827	/usr/local/go/src/crypto/tls/conn.go
1660167744827	":606 +0x112"
1660167744827	"crypto/tls.(*Conn).readRecord(...)"
1660167744827	
1660167744827	"/usr/local/go/src/crypto/tls/conn.go:574"
1660167744827	crypto/tls.(*Conn).Read(0xc00021a380, {
1660167744827	"0xc0000e2000, 0x1000, 0x0})"
1660167744827	/usr/local/go/src/crypto/tls/conn.go:1277 +
1660167744827	"0x16f"
1660167744827	net/http.(*persistConn).Read(0xc00011f680, {
1660167744827	"0xc0000e2000, 0xc000032360, 0xc0000d1d30})"
1660167744827	/usr/local/go/src/net/http/transport.go:1926 +0x4e
1660167744827	
1660167744827	"bufio.(*Reader).fill(0xc0000b3140)"
1660167744827	/usr/local/go/src/bufio/bufio.go:
1660167744827	"101 +0x103"
1660167744827	"bufio.(*Reader).Peek(0xc0000b3140, 0x1)"
1660167744827	"/usr/local/go/src/bufio/bufio.go:139 +0x5d"
1660167744827	"net/http.(*persistConn).readLoop(0xc00011f680)"
1660167744827	/usr/local/go/src/net/http/transport.go:2087
1660167744827	" +0x1ac"
1660167744827	"created by net/http.(*Transport).dialConn"
1660167744827	/usr/local/go/src/net/http/transport.go:1747
1660167744827	" +0x1e05"
1660167744827	
1660167744827	"goroutine 519 [select]:"
1660167744827	"net/http.(*persistConn).writeLoop(0xc00011f680)"
1660167744827	
1660167744827	"/usr/local/go/src/net/http/transport.go:2386 +0xfb"
1660167744827	"created by net/http.(*Transport).dialConn"
1660167744827	"/usr/local/go/src/net/http/transport.go:1748 +0x1e65"
1660167744827	
1660167744827	"goroutine 522 [IO wait]:"
1660167744827	"internal/poll.runtime_pollWait(0x7f0b2883edc8, 0x72)"
1660167744827	"/usr/local/go/src/runtime/netpoll.go:234 +0x89"
1660167744827	internal/poll.(*pollDesc).wait(0xc000160800, 0xc000243ea1, 
1660167744827	"0x0)"
1660167744827	"/usr/local/go/src/internal/poll/fd_poll_runtime.go:84 +0x32"
1660167744827	"internal/poll.(*pollDesc).waitRead(...)"
1660167744827	"/usr/local/go/src/internal/poll/fd_poll_runtime.go:89"
1660167744827	"internal/poll.(*FD).Read(0xc000160800, {0xc000243ea1, 0x1, 0x1})"
1660167744827	"/usr/local/go/src/internal/poll/fd_unix.go:167 +0x25a"
1660167744827	"net.(*netFD).Read(0xc000160800, {0xc000243ea1, 0x8035a0, 0xc000375f48})"
1660167744827	"/usr/local/go/src/net/fd_posix.go:56 +0x29"
1660167744827	net.(*conn).Read(0xc0000b6160
1660167744827	", {0xc000243ea1, 0xc0000a47d0, 0xc0005b41e0})"
1660167744827	"/usr/local/go/src/net/net.go:183 +0x45"
1660167744827	"net/http.(*connReader).backgroundRead(0xc000243e90)"
1660167744827	"/usr/local/go/src/net/http/server.go:672 +0x3f"
1660167744827	created by net/http.(*connReader).startBackgroundRead
1660167744827	
1660167744827	"/usr/local/go/src/net/http/server.go:668 +0xcf"
1660167744827	
1660167744827	"goroutine 465 [IO wait]:"
1660167744827	"internal/poll.runtime_pollWait(0x7f0b2883ebf8, 0x72)"
1660167744827	/usr/local/go/src/runtime/netpoll.go
1660167744827	":234 +0x89"
1660167744827	"internal/poll.(*pollDesc).wait(0xc0003e8300, 0xc000118a00, 0x0)"
1660167744827	"/usr/local/go/src/internal/poll/fd_poll_runtime.go:84 +0x32"
1660167744827	"internal/poll.(*pollDesc).waitRead(...)"
1660167744827	"/usr/local/go/src/internal/poll/fd_poll_runtime.go:89"
1660167744827	internal/poll.(*FD).Read(0xc0003e8300, {0xc000118a00, 0x1363, 0x1363
1660167744827	"})"
1660167744827	"/usr/local/go/src/internal/poll/fd_unix.go:167 +0x25a"
1660167744827	"net.(*netFD).Read(0xc0003e8300, {0xc000118a00, 0xc000118a05, 0x1a5})"
1660167744827	"/usr/local/go/src/net/fd_posix.go:56 +0x29"
1660167744827	net.(*conn).Read(
1660167744827	"0xc000198010, {0xc000118a00, 0x6, 0xc0003577f8})"
1660167744827	"/usr/local/go/src/net/net.go:183 +0x45"
1660167744827	"crypto/tls.(*atLeastReader).Read(0xc0004b2060, {0xc000118a00, 0x0, 0x40b08d})"
1660167744827	"/usr/local/go/src/crypto/tls/conn.go:777 +0x3d"
1660167744827	bytes.(*Buffer).ReadFrom(0xc00007e5f8, 
1660167744827	"{0x96b540, 0xc0004b2060})"
1660167744827	"/usr/local/go/src/bytes/buffer.go:204 +0x98"
1660167744827	"crypto/tls.(*Conn).readFromUntil(0xc00007e380, {0x96bc00, 0xc000198010}, 0x0)"
1660167744827	"/usr/local/go/src/crypto/tls/conn.go:799 +0xe5"
1660167744827	"crypto/tls.(*Conn).readRecordOrCCS(0xc00007e380, 0x0)"
1660167744827	"/usr/local/go/src/crypto/tls/conn.go:606 +0x112"
1660167744827	"crypto/tls.(*Conn).readRecord(...)"
1660167744827	"/usr/local/go/src/crypto/tls/conn.go:574"
1660167744827	crypto/tls.(*Conn).Read(0xc00007e380, {0xc00075a000, 0x1000, 0x0}
1660167744827	")"
1660167744827	"/usr/local/go/src/crypto/tls/conn.go:1277 +0x16f"
1660167744827	"net/http.(*persistConn).Read(0xc00011e480, {0xc00075a000, 0xc0002ae0c0, 0xc000357d30})"
1660167744827	"/usr/local/go/src/net/http/transport.go:1926 +0x4e"
1660167744827	"bufio.(*Reader).fill(0xc0005e8720)"
1660167744827	
1660167744827	"/usr/local/go/src/bufio/bufio.go:101 +0x103"
1660167744827	"bufio.(*Reader).Peek(0xc0005e8720, 0x1)"
1660167744827	/usr/local/go/src/bufio/bufio.go:
1660167744827	"139 +0x5d"
1660167744827	"net/http.(*persistConn).readLoop(0xc00011e480)"
1660167744827	/usr/local/go/src/net/http/transport.go
1660167744827	":2087 +0x1ac"
1660167744827	"created by net/http.(*Transport).dialConn"
1660167744827	"/usr/local/go/src/net/http/transport.go:1747 +0x1e05"
1660167744827	
1660167744827	"goroutine 530 [select]:"
1660167744827	"net/http.(*persistConn).writeLoop(0xc00011e480)"
1660167744827	/usr/local/go/src/net/http/transport.go:2386 +
1660167744827	"0xfb"
1660167744827	"created by net/http.(*Transport).dialConn"
1660167744827	"/usr/local/go/src/net/http/transport.go:1748 +0x1e65"
1660167744831	"END RequestId: d97aed5d-637e-4fae-b1f3-3f4241c86f42"

Your Environment

New Relic Lambda Extension: 2.3.2
New Relic Lambda CLI: 0.6.3
Layer: arn:aws:lambda:us-west-1:451483290750:layer:NewRelicPython38:65

Additional context

We are using this to track telemetry data around Elasticsearch calls. We see ~70k invocations of the related lambda function per day. We see this error ~10 times per day

distributed tracing fails: cannot import name 'DEFAULT_CIPHERS' from 'urllib3.util.ssl_

Python lambda failing to import newlic_lambda_wrapper

Description

[ERROR] Runtime.ImportModuleError: Unable to import module 'newrelic_lambda_wrapper': Failed to import module 'app': cannot import name 'DEFAULT_CIPHERS' from 'urllib3.util.ssl_' (/var/task/urllib3/util/ssl_.py)
Traceback (most recent call last):

Steps to Reproduce

Follow the steps in the example: examples/sam/distributedtracing

Expected Behavior

Python lambda launches successfully when invoked.

Relevant Logs / Console output

[ERROR] Runtime.ImportModuleError: Unable to import module 'newrelic_lambda_wrapper': Failed to import module 'app': cannot import name 'DEFAULT_CIPHERS' from 'urllib3.util.ssl_' (/var/task/urllib3/util/ssl_.py)
Traceback (most recent call last):

Your Environment

aws

Duplicates Logs

Description

Hi guys.

Actually have a problem with the logs because i am watching that when send logs in new relic not everything but it duplicates some logs for me.

As you can see the unique argument that changes is the index but the content log message is equals. This error are reproduce in other lambdas that have in my account of AWS.

Attach image for you help me.

Steps to Reproduce

  • Lambda Layers NodeJS and Python

Expected Behavior

Not duplicated logs in my account of New Relic

Relevant Logs / Console output

Screen Shot 2022-07-28 at 12 32 51
Screen Shot 2022-07-28 at 12 32 45

Your Environment

  • Lambda 12.x, 14.x
  • Python 3.x
  • NEW_RELIC_EXTENSION_SEND_FUNCTION_LOGS = true

Node.js missing invocations

Description

On regular basis some invocations are missing on New Relic, but clearly can be found on CloudWatch.

Steps to Reproduce

Hard to say. Every time couple of invocations are missing. For example if invoked 20 times it'll miss 2-3 invocations - it seems as last couple of invocations.

Expected Behavior

Having all invocation

Your Environment

Lambda container support

Summary

Support Lambda containers for the lambda extension.

Desired Behavior

Lambda containers are able to use the new relic lambda extension.

Additional context

We tried installing the extension into /opt/extensions but it did not work.

NEW_RELIC_EXTENSION_SEND_FUNCTION_LOGS requires lower-case 'true', but is documented with 'TRUE'

Description

https://docs.newrelic.com/docs/serverless-function-monitoring/aws-lambda-monitoring/enable-lambda-monitoring/account-linking#alt "Lambda environment variables" states:

NEW_RELIC_EXTENSION_SEND_FUNCTION_LOGS | FALSE by default. Set to TRUE to send function logs to New Relic directly, bypassing CloudWatch and the newrelic-log-ingestion Lambda.

However, following those instructions literally doesn't work: it has to be true (lower-case), not TRUE.
 

Steps to Reproduce

  1. Create a lambda with the appropriate layer
  2. Set NEW_RELIC_EXTENSION_SEND_FUNCTION_LOGS=TRUE in its environment
  3. Observe subscription isn't configured correctly

Expected Behavior

Function logs should be forwarded to new relic.

Relevant Logs / Console output

With NEW_RELIC_EXTENSION_SEND_FUNCTION_LOGS=TRUE, the lambda CloudWatch logs contain:

LOGS Name: newrelic-lambda-extension State: Subscribed Types: [platform]

With NEW_RELIC_EXTENSION_SEND_FUNCTION_LOGS=true, they contain:

LOGS Name: newrelic-lambda-extension State: Subscribed Types: [platform,function]

Your Environment

  • Lambda: Python 3.9
  • Layer: arn:aws:lambda:ap-southeast-2:451483290750:layer:NewRelicPython39:30

Additional context

N/A

Dead link in Support section of README

In the Support section of the README, the text "in the Explorers Hub" is linked with the following URL:

https://discuss.newrelic.com/t/new-relic-lambda-extension/111715

When I visit this URL, despite being logged in, I get the following error:

Sorry, you don't have access to that topic!

I am however able to access other threads, such as this one.

https://discuss.newrelic.com/t/problems-setting-up-serverless-monitoring-lambda-layer/122424

Is it possible the thread linked in the README no longer exists?

Golang Layer example fails silently for older versions of aws-lambda-go

Description

The example at newrelic-lambda-extension/examples/sam/go has a silent failure if the aws-lambda-go version is pre-1.18. One service I was working on had been built at a time when v1.13 was the latest version, and pinned since then.

The example instructs using -tags lambda.norpc but that build tag will have no effect if using a pre-1.18 version of the lambda package, and is a difficult error to track down - it results in mysterious timeouts after successfully running the cold start of a lambda, due to rpc server blocking the main thread.

Steps to Reproduce

Attempt to deploy this lambda after having checked out a version before

https://github.com/aws/aws-lambda-go/releases/tag/v1.18.0

Custom Runtime support is listed as a feature change in that version.

Expected Behavior

Golang does not emit any warnings in this situation, so a warning in this example would be appropriate.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.