Deploy OneAgent as AWS Lambda extension

Dynatrace provides you with a dedicated AWS Lambda layer that contains the Dynatrace OneAgent extension for AWS Lambda. You need to add the publicly available layer for your runtime and region to your function. Then, based on your configuration method, Dynatrace provides a template or configuration for your AWS Lambda function. (see details below).

Prerequisites

  • The Dynatrace OneAgent extension supports AWS Lambda functions written in Node.js, Python, or Java running on an Amazon Linux 2 runtime.
  • To monitor a Java Lambda function with OneAgent, you need to allocate at least 1.5 GB of RAM to the Lambda function.

To configure memory, in the AWS Lambda console, go to General > Basic settings and set Memory to a value of at least 1.5 GB.

  • The Forward Tag 4 trace context extension is a required Deep monitoring setting. Please confirm it in New OneAgent features. If it's already confirmed but disabled, enable it in Troubleshooting.

1. Activate AWS Lambda

To get started

  1. In the Dynatrace menu, select Deploy Dynatrace.
  2. On the Dynatrace Hub page, search for AWS Lambda.
  3. Select AWS Lambda and then select Activate AWS Lambda.
  4. Follow the instructions to enable monitoring of AWS Lambda functions.

Note: If you're using the Deploy Dynatrace page, select Start installation. On the Install OneAgent page, select AWS Lambda. This displays the Enable Monitoring for AWS Lambda Functions page.

2. Choose a configuration method

The Dynatrace Lambda agent is distributed as a layer that can be enabled and configured manually or using well known Infrastructure as Code (IaC) solutions.

On the Enable Monitoring for AWS Lambda Functions page, use the How will you configure your AWS Lambda functions? list to select your preferred method, and then make sure you set all properties for the selected method before copying the generated configuration snippets.

3. optional Specify a Dynatrace API endpoint

optional

This is an optional step that enables you to specify a Dynatrace API endpoint to which monitoring data will be sent.

The typical scenario is to deploy a Dynatrace ActiveGate in close proximity (same region) to the Lambda functions that you want to monitor in order to reduce network latency, which can impact the startup time of your Lambda functions.

4. optional Enable Real User Monitoring

optional

This is an optional step to use Real User Monitoring (RUM), which provides you with deep insights into user actions and performance via the browser or in mobile apps.

5. Define an AWS layer name

Select the AWS region and the runtime of the Lambda function to be monitored. These settings are required to provide the correct layer ARN.

6. Deployment

Copy the configuration snippets into your deployment and use your deployment method of choice to enable the layer and set the configuration for your Lambda functions.

7. Configuration options

Configure the AWS API Gateway

If inbound (non-XHR) requests to your Lambda functions are not connected to the calling application, configure the API Gateway to pass through the Dynatrace tag. To do this, enable Use Lambda Proxy Integration on the Integration Request configuration page of the API Gateway.

AWS Lambda also supports non-proxy integration, which, without some additional configuration, prevents Dynatrace from doing the following:

  • Tracing calls from other monitored applications
  • RUM detection

To make tracing calls from other monitored applications/RUM detection work in this scenario, create a custom mapping template in the integration requests configuration.

  1. In the AWS API Gateway Console, go to Resources and select a request method (for example, GET).
  2. Select Mapping Templates and then select Add mapping template.
  3. Add the following content to the template:
{
    #set($path = $context.stage + $context.resourcePath)
    "path": "$path",
    "httpMethod": "$context.httpMethod",
    "headers": {
        #foreach($param in ["X-dynaTrace", "traceparent", "tracestate"])
        "$param": "$util.escapeJavaScript($input.params().header.get($param))"
        #if($foreach.hasNext),#end
        #end
    },
    "requestContext": {
        "stage": "$context.stage"
    }
}
  1. Select Save to save your configuration.
  2. Redeploy your API.

Note: This configuration method works only for Node.js and Python. Mapping templates currently aren't supported for Java.

Filter cold starts

One of the important metrics for Lambda is the frequency of cold starts. A cold start happens when a new instance of a Lambda function is invoked. Such cold starts take longer and add latency to your requests.

A high cold start frequency can indicate errors or an uneven load pattern that can be mitigated using provisioned concurrency. Dynatrace OneAgent reports such cold starts as a property on the PurePath.

To analyze cold starts, select View all requests on the Lambda service details page.

Service details page for AWS Lambda function

In the request filter, select Function cold start in the Request property section.

This displays a page that you can filter by invocations containing Only cold start or No cold start.

Screen to filter by invocations containing a Only cold start or No cold start

OneAgent overhead

Enabling monitoring unavoidably induces overhead to the monitored function execution. Overhead depends on several factors, such as function runtime technology, configuration, and concrete function characteristics, such as code size or execution duration and complexity.

The amount of memory configured for a function directly impacts the compute resources assigned to the function instance. The worst-case scenario for OneAgent overhead is a function with an empty function handler and minimum memory configuration.

Cold start overhead

  • For Python, cold start overhead is about 1,000 ms.
  • For Node.js, cold start overhead is about 700 ms.
  • For Java, cold start overhead may exceed 1,000 ms.

For the minimum memory configuration requirement, see Requirement for Java Lambda functions.

Response time latency

Latency depends on the function implementation, but is typically less than 10%.

Code space overhead

Runtime Code space (MB)
Node.js ~6MB
Python 6.3MB
Java 4.5MB

8. Dynatrace AWS integration

While not mandatory, we recommend that you set up Dynatrace AWS integration (SaaS, Managed). This allows data ingested via AWS integration to be seamlessly combined with the data collected by the OneAgent Lambda code module.

AWS Lambda metrics Invocations

Known limitations

  • The Dynatrace AWS Lambda extension relies on an AWS Lambda extension mechanism that is currently available for Lambda functions with an Amazon Linux 2 runtime. These runtimes are:
    • For Node.js
      • Node.js 14
      • Node.js 12
      • Node.js 10
    • For Python
      • Python 3.8
    • For Java
      • Java 11
      • Java 8 (only for amazon-corretto-8 JDK)

See Lambda runtimes for details.

  • The Dynatrace AWS Lambda extension does not support the capture of request attributes.

  • Dynatrace does not support database calls from Lambda functions with Node.js.

  • To detect and trace invocations through Lambda functions written in Java, your function needs to use the Lambda events library for event attribute mapping, which also includes HTTP tag extraction. For details, see AWS Lambda Java Events. Specifically, this limits the supported handler function event types to:

    • APIGatewayProxyRequestEvent
    • APIGatewayV2HTTPEvent
  • The Dynatrace AWS Lambda extension doesn't capture IP addresses of outgoing HTTP requests. This results in unmonitored hosts if the called service isn't monitored with Dynatrace OneAgent.

  • Incoming calls: Dynatrace can only monitor incoming calls that are invoked via AWS SDK or an API gateway.

  • Outgoing requests to another AWS Lambda function: In a monitored AWS Lambda function, only the following libraries are supported for outgoing requests to another AWS Lambda function:

    • For Java - AWS SDK for Java
    • For Node.js - AWS SDK for JavaScript in Node.js
    • For Python - AWS SDK for Python (Boto3)
  • Outgoing HTTP requests: In a monitored AWS Lambda function, only the following libraries/HTTP clients are supported for outgoing HTTP requests:

    • For Java - Apache HTTP Client 3.x, 4.x
    • For Node.js - Built-in http.request
    • For Python - requests, aiohttp-client, urllib3