No-op in case ELASTIC_APM_ACTIVE is not set or set to false

[aspacca]

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.

[simitt]

@aspacca apologies for the late reply on this one. There are a couple of things to unpack in this request, please let me know if I correctly understood what you are asking for:

(1) You are looking for a way to install, but disable the lambda extension and the suggestion is that the extension should listen to ELASTIC_APM_ACTIVE for this. This sounds reasonable to me.
(2) You would like to use the apm lambda extension outside an AWS environment for testing. I don't quite grasp your reference to checking the AWS_LAMBDA_FUNCTION_NAME for this, could you go into more details here please or point me towards a reference?
(3) You would like to use the apm lambda extension without having to specify the ELASTIC_APM_LAMBDA_APM_SERVER. This is not possible. The Lambda extensions needs an endpoint to which the apm data are sent. The Server URL and an API Key or secret token (either specified via ENV or Secret Manager) are the minimal required config options for the extension. I am not certain how you would envision the extension to know where to send the data to if no endpoint is specified, but maybe I misinterpreted some part of your request?

[aspacca]

(1) You are looking for a way to install, but disable the lambda extension and the suggestion is that the extension should listen to ELASTIC_APM_ACTIVE for this. This sounds reasonable to me.

then we are aligned on this :)

(2) You would like to use the apm lambda extension outside an AWS environment for testing. I don't quite grasp your reference to checking the AWS_LAMBDA_FUNCTION_NAME for this, could you go into more details here please or point me towards a reference?

Checking the AWS_LAMBDA_FUNCTION_NAME is an additional check I currently do for the apm python agent. And it's used to not use the agent outside an AWS environment. the logic is not AWS_LAMBDA_FUNCTION_NAME or not ELASTIC_APM_ACTIVE. This is because I have some test scenario where ELASTIC_APM_ACTIVE is set but not AWS_LAMBDA_FUNCTION_NAME.
You can find more details in the comment of the decorator: https://github.com/elastic/elastic-serverless-forwarder/blob/main/handlers/aws/utils.py#L50-L68

(3) You would like to use the apm lambda extension without having to specify the ELASTIC_APM_LAMBDA_APM_SERVER. This is not possible. The Lambda extensions needs an endpoint to which the apm data are sent. The Server URL and an API Key or secret token (either specified via ENV or Secret Manager) are the minimal required config options for the extension. I am not certain how you would envision the extension to know where to send the data to if no endpoint is specified, but maybe I misinterpreted some part of your request?

No, sorry, I was not clear: I want to be able to disable the APM lambda extension (through the ELASTIC_APM_ACTIVE not being set or set to false) and in this case to have no need to set any other ELASTIC_APM_* env variables.

Basically what I look for is either I opt-in in the APM lambda extension setting explicitly ELASTIC_APM_ACTIVE, ELASTIC_APM_LAMBDA_APM_SERVER and all the other minimum required environment variables (api key or secret token), or if I don't set ELASTIC_APM_ACTIVE or set it to false I don't need to set any other ELASTIC_APM_* env variables and still a lambda with the APM extension layer will be able to run just with no APM features enabled.

[simitt]

Thanks for the explanation. Allowing to disable the lambda extension sounds reasonable.

Checking AWS_LAMBDA_FUNCTION_NAME for the python agent seems very specific, and is nothing we would want to adopt in this extension. You'll probably need to adapt your test scenarios for this.

I cannot make any promises on delivery and timelines, but we'll keep this enhancement topic in mind.

[aspacca]

@simitt great, thanks!

[aspacca]

@simitt could you confirm I can expect this feature on 8.7? thanks!

[simitt]

@aspacca it is not planned for the 8.7 timeline.
cc @elastic/apm-pm for visibility

[aspacca]

@simitt @elastic/apm-pm : is this planned for any release?

[simitt]

It currently isn't, as it is not aligned with our major priorities.
IMO adding an option ELASTIC_APM_ACTIVE should be fairly straight forward. Changing the required options to only be conditionally required would be a bit more involved. If it is good enough for now to only introduce ELASTIC_APM_ACTIVE and you configure a dummy value for any other required options, I believe we could plan this for 8.9. But ultimately defer for @elastic/apm-pm to chime in on this.