The recommended way of configuring the APM Lambda Extension and the APM Agents on AWS Lambda is through the Lambda function’s environment variables.
The configuration options for the APM Agents are documented in the corresponding language agents:
The following configuration options are particularly relevant for Elastic’s APM on AWS Lambda:
This required config option controls where the Lambda extension will ship data. This should be the URL of the final APM Server destination for your telemetry.
One of these (or, alternatively, the corresponding settings for the AWS Secrets Manager IDs) needs to be set as the authentication method that the extension uses when sending data to the URL configured via
ELASTIC_APM_LAMBDA_APM_SERVER. Alternatively, you can store your APM Server credentials using the AWS Secrets Manager and use the
ELASTIC_APM_SECRETS_MANAGER_API_KEY_ID config options, instead. Sending data to the APM Server if none of these options is set is possible, but your APM agent must be allowed to send data to your APM server in anonymous mode.
Instead of specifying the
ELASTIC_APM_API_KEY as plain text in your Lambda environment variables, you can use the AWS Secrets Manager to securely store your APM authetication keys. The
ELASTIC_APM_SECRETS_MANAGER_SECRET_TOKEN_ID config options allow you to specify the Secrets Manager’s secret id of the stored APM API key or APM secret token, respectively, to be used by the APM Lambda Extension for authentication.
The configured name of your application or service. The APM Agent will use this value when reporting data to the APM Server. If unset, the APM Agent will automatically set the value based on the Lambda function name. Use this config option if you want to group multiple Lambda functions under a single service entity in APM.
The APM Lambda Extension’s timeout value, in seconds, for receiving data from the APM Agent. The default is
The port on which the APM Lambda Extension listens to receive data from the APM Agent. The default is
The timeout value, in seconds, for the Lambda Extension’s HTTP client sending data to the APM Server. The default is
3. If the Extension’s attempt to send APM data during this time interval is not successful, the extension queues back the data. Further attempts at sending the data are governed by an exponential backoff algorithm: data will be sent after a increasingly large grace period of 0, then circa 1, 4, 9, 16, 25 and 36 seconds, provided that the Lambda function execution is ongoing.
Whether to synchronously flush APM agent data from the extension to the APM Server at the end of the function invocation.
The two accepted values are
syncflush. The default is
backgroundstrategy indicates that the extension will not flush when it receives a signal that the function invocation has completed. It will instead send any remaining buffered data on the next function invocation. The result is that, if the function is not subsequently invoked for that Lambda environment, the buffered data will be lost. However, for lambda functions that have a steadily frequent load pattern the extension could delay sending the data to the APM Server to the next lambda request and do the sending in parallel to the processing of that next request. This potentially would improve both the lambda function response time and its throughput.
The other value,
syncflushwill synchronously flush all remaining buffered APM agent data to the APM Server when the extension receives a signal that the function invocation has completed. This strategy blocks the lambda function from receiving the next request until the extension has flushed all the data. This has a negative effect on the throughput of the function, though it ensures that all APM data is sent to the APM server.
The logging level to be used by both the APM Agent and the Lambda Extension. Supported values are