Feature request: enable tracing only when running on AWS Lambda

[dreamorosi]

Description of the feature request

Customers have raised a pain point around the Tracer utility throwing errors when when not running inside the Lambda execution environment. While both the Tracer and the underlying aws-x-ray packages provide ways to both change missing context strategy and disable tracing altogether, it would make sense to have Tracer to be enabled by default only when running inside a Lambda function and disabled elsewhere instead of the current behaviour that sees the utility always being enabled by default unless explicitly disabled.

Problem statement

Tracer throws an error when trying to interact with a segment outside of a context and/or without the existence of a root segment (aka facade). Customers have to explicitly disable the Tracer utility when running outside of Lambda (i.e. testing, CI, etc.) which can be cumbersome.

Summary of the feature

• Change wording/names of the parameter and variable used to enable/disable tracing to avoid double negation (i.e. currently reading like tracing disabled, change to tracing enabled).
• Add logic to detect whether Tracer is being initialised in a Lambda function or not which would check the existence of one between AWS_LAMBDA_FUNCTION_NAME or AWS_EXECUTION_ENV environment variables that are present by default in Lambda.
• Change protected property Tracer.tracingDisabled to Tracer.tracingEnabled.
• Change all conditional behaviour and references related to Tracer.tracingDisabled to account for change.
• Update all unit tests.

Code examples

• Current environment variable used to disable tracing is POWERTOOLS_TRACE_DISABLED, would change to POWERTOOLS_TRACE_ENABLED.
• Currently, to disable the tracer Customers have to do this const tracer: Tracer = new Tracer({ disabled: true });, it would change to const tracer: Tracer = new Tracer({ enabled: true });

Benefits for you and the wider AWS community

Better Developer Experience, less boilerplate code (-1 extra line) needed to instrument tests.

Describe alternatives you've considered

Clearer documentation around how to either disable tracing and/or changing X-Ray underlying SDK behaviour to ignore missing segments/context.

Additional context

Related issues, RFCs

#515
#572

[bahrmichael]

check the existence of one between AWS_LAMBDA_FUNCTION_NAME or AWS_EXECUTION_ENV environment variables

I suggest using only AWS_LAMBDA_FUNCTION_NAME because AWS_EXECUTION_ENV seems to be present in other compute engines as well: https://stackoverflow.com/a/54241697

[dreamorosi]

Thank you for pointing this out, I was not aware! ECR does support X-Ray though, so in that case, when enabled, it would find a parent segment and not throw an error; which is what we are trying to avoid with this change.

Generally speaking I find it counterintuitive to piggy-back on the AWS_LAMBDA_FUNCTION_NAME variable since we are effectively trying to distinguish whether we are running in a Lambda execution environment or Locally/CI.

I think accounting for all compute engines might be a bit out of the scope (given the tenets) but I can see it being a problem if we decide that it's important to our Customers.

Alternatively instead of checking wether the variable is set or not we could check if it has a value of one of the Lambda supported runtimes (nodejs10.x | nodejs12.x | nodejs14.x).

@saragerion what do you think?

[github-actions]

⚠️ COMMENT VISIBILITY WARNING ⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.