-
Notifications
You must be signed in to change notification settings - Fork 33
Description
The Elastic Serverless Forwarder currently uses the Python Agent.
The characteristic of the Forwarder is that it's an Application available on the AWS Serverless Application Repository that different users can deploy. Enabling APM tracing and instrumentation is optional: according to the users requirement they may opt-in into it, but by default the feature is not enabled.
We achieve this with our own capture_serverless decorator: checking for ELASTIC_APM_ACTIVE being set as ENV variable, and adding a no-op wrapper in case it's not.
(Additionally we check for AWS_LAMBDA_FUNCTION_NAME being set as well, in order to easy local running and integration tests)
I run a test deploying the Forwarder with the AWS Lambda extension layer, and I realised that without setting ELASTIC_APM_LAMBDA_APM_SERVER ENV variable the Forwarder lambda execution fails.
Contrary to the Python Agent capture_serverless decorator, there is no workaround for this in the AWS Lambda extension.
This prevents the Forwarder to adopt the AWS Lambda extension, that should be the way to go for the future, especially given the planned support for collecting logs.
In general, Applications available on the AWS Serverless Application Repository, should be the more flexible they can in providing their own users to optionally enable accessory features like APM, and with the current behaviour there is no way to use AWS Lambda extension without enabling it.
The additional check for AWS_LAMBDA_FUNCTION_NAME ENV variable would be optimal, since it will lower the effort required on running the lambda code outside of a real lambda environment, but there might be space for any alternative solution.