This is a cache of https://www.elastic.co/guide/en/apm/agent/java/current/aws-lambda.html. It is a snapshot of the page at 2024-12-26T01:06:42.754+0000.
Monitoring AWS Lambda Java Functions | APM Java Agent Reference [<strong>1</strong>.x] | Elastic

Monitoring AWS Lambda Java Functions

edit

The Java APM Agent can be used with AWS Lambda to monitor the execution of your AWS Lambda functions.

Note: The Centralized Agent Configuration on the Elasticsearch APM currently does NOT support AWS Lambda.

Quick Start

edit

To get started with APM for your Java AWS Lambda functions, follow the steps below.

Prerequisites

edit
  1. You need an APM Server to send APM data to. Follow the APM Quick start if you have not set one up yet. For the best-possible performance, we recommend setting up APM on Elastic Cloud in the same AWS region as your AWS Lambda functions.
  2. Make sure you are using one of the supported AWS Lambda Java runtimes:

    Tags Java Runtime Operating System Supported

    11

    Java 11 (Corretto)

    Amazon Linux 2

    yes

    8.al2

    Java 8 (Corretto)

    Amazon Linux 2

    yes

    8

    Java 8 (OpenJDK)

    Amazon Linux 2018.03

    no

Step 1: Select the AWS Region and Architecture

edit

Pick the right ARN from this release table for the APM Lambda Extension Layer.

In addition, pick the right ARN from this release table for the APM Agent Layer.

Select the AWS region and architecture of your Lambda function. This documentation will update based on your selections.
region:
architecture:

The selected AWS region and the architecture must match the AWS region and architecture of your AWS Lambda function!

Step 2: Add the APM Layers to your Lambda function

edit

Both the Elastic APM AWS Lambda extension and the Java APM Agent are added to your Lambda function as AWS Lambda Layers. Therefore, you need to add the corresponding Layer ARNs (identifiers) to your Lambda function.

To add the layers to your Lambda function through the AWS Management Console:

  1. Navigate to your function in the AWS Management Console
  2. Scroll to the Layers section and click the Add a layer button image of layer configuration section in AWS Console
  3. Choose the Specify an ARN radio button
  4. Copy and paste the following ARNs of the Elastic APM AWS Lambda extension layer and the APM agent layer in the Specify an ARN text input:
    APM Extension layer:
    EXTENSION_ARN
    APM agent layer:
    AGENT_ARN image of choosing a layer in AWS Console
  5. Click the Add button

Step 3: Configure APM on AWS Lambda

edit

The Elastic APM AWS Lambda extension and the APM Java agent are configured through environment variables on the AWS Lambda function.

For the minimal configuration, you will need the APM Server URL to set the destination for APM data and an APM Secret Token. If you prefer to use an APM API key instead of the APM secret token, use the ELASTIC_APM_API_KEY environment variable instead of ELASTIC_APM_SECRET_TOKEN in the following configuration.

For production environments, we recommend using the AWS Secrets Manager to store your APM authentication key instead of providing the secret value as plaintext in the environment variables.

To configure APM through the AWS Management Console:

  1. Navigate to your function in the AWS Management Console
  2. Click on the Configuration tab
  3. Click on Environment variables
  4. Add the following required variables:
AWS_LAMBDA_EXEC_WRAPPER       = /opt/elastic-apm-handler  # use this exact fixed value
ELASTIC_APM_LAMBDA_APM_SERVER = <YOUR-APM-SERVER-URL>     # this is your APM Server URL
ELASTIC_APM_SECRET_TOKEN      = <YOUR-APM-SECRET-TOKEN>   # this is your APM secret token
ELASTIC_APM_SEND_STRATEGY     = background                

Java environment variables configuration section in AWS Console

The ELASTIC_APM_SEND_STRATEGY defines when APM data is sent to your Elastic APM backend. To reduce the execution time of your lambda functions, we recommend to use the background strategy in production environments with steady load scenarios.

You can optionally fine-tune the Java agent or the configuration of the Elastic APM AWS Lambda extension.

ThatR17;s it; After following the steps above, youR17;re ready to go! Your Lambda function invocations should be traced from now on.

Read on to learn more about the features and limitations of the Java APM Agent on AWS Lambda Functions.

Features and Caveats

edit

The AWS Lambda as a runtime behaves differently from conventional runtimes. While most APM and monitoring concepts apply to AWS Lambda, there are a few differences and limitations to be aware of.

Performance monitoring

edit

Elastic APM automatically measures the performance of your lambda function executions. It records traces for database queries, external HTTP requests, and other slow operations that happen during execution.

By default, the agent will trace the usual supported technologies. To trace other events, take a look at additional method tracing options, however note that due to its asynchronous nature, the Sampling Profiler is not a valid option for AWS Lambda.

Error monitoring

edit

Whenever an Exception is thrown by your function handler method, the agent will send an error event to the APM Server and the corresponding transaction will be recorded as a failed transaction. Errors related to traced spans will be sent as well.

Caveats

edit
  • System and custom metrics are not collected for Lambda functions. This is both because most of those are irrelevant and because the interval-based event sending model is not suitable for FaaS environments.
  • Central Configuration is disabled, which means that the APM agent configuration cannot be changed without redefining the lambda environment variables or APM agent settings.
  • Cold starts can be significantly slower when the agent is installed. If this is an issue, following are ways to deal with slow code starts:

    • If the only issue with slower cold starts is Lambda timing out, consider increasing the configured timeout.
    • The higher memory limit you would allow for your Function, the smaller this effect would be. This is irrelevant for subsequent Function invocations, it is only relevant for cold starts.
    • Much of the startup delay is related to the amount of enabled instrumentations. An enabled instrumentation will contribute to this overhead regardless of it being applicable for your specific Lambda function. You can considerably reduce the related overhead by specifying a limited list of enabled instrumentations through the enable_instrumentations config. An automatic way to generate such list is by invoking your Lambda with the agentR17;s default configurations and a log_level of INFO or lower. After the first lambda invocation, the agent would log a message with the following format: Used instrumentation groups: [aws-lambda, executor, executor-collection, fork-join, ssl-context, urlconnection].
  • The Sampling Profiler feature would not work because it relies on profiling sessions and subsequent asynchronous processing of the collected data.