feat(aws-sdk): lambda client instrumentation

[chrisrichardsevergreen]

Which problem is this PR solving?

Implements instrumentation of the AWS SDK 'Lambda' calls (invoke) using FAAS trace semantics - this follows on from discussions on PR #877

Short description of the changes

• Add lambda service extension adding faas_* attributes to the request span, and propagating the context into the ClientContext custom field on the Invoke request.

Checklist

• Ran npm run test-all-versions for the edited package(s) on the latest commit if applicable.

[codecov]

Codecov Report

Merging #916 (1eedc98) into main (cc37e3f) will increase coverage by 0.14%.
The diff coverage is 97.95%.

@@            Coverage Diff             @@
##             main     #916      +/-   ##
==========================================
+ Coverage   95.91%   96.05%   +0.14%     
==========================================
  Files          13       24      +11     
  Lines         856     1394     +538     
  Branches      178      289     +111     
==========================================
+ Hits          821     1339     +518     
- Misses         35       55      +20     

Impacted Files	Coverage Δ
...try-instrumentation-aws-sdk/src/services/lambda.ts	97.77% <97.77%> (ø)
...entelemetry-instrumentation-aws-sdk/src/aws-sdk.ts	97.44% <100.00%> (ø)
...ntation-aws-sdk/src/services/ServicesExtensions.ts	100.00% <100.00%> (ø)
...emetry-instrumentation-aws-sdk/src/services/sns.ts	93.75% <0.00%> (ø)
...etry-instrumentation-aws-sdk/src/services/index.ts	100.00% <0.00%> (ø)
...y-instrumentation-aws-sdk/src/services/dynamodb.ts	100.00% <0.00%> (ø)
...opentelemetry-instrumentation-aws-sdk/src/utils.ts	97.36% <0.00%> (ø)
...opentelemetry-instrumentation-aws-sdk/src/enums.ts	100.00% <0.00%> (ø)
...tapackages/auto-instrumentations-node/src/utils.ts	97.87% <0.00%> (ø)
...emetry-instrumentation-aws-sdk/src/services/sqs.ts	89.65% <0.00%> (ø)
... and 3 more

[blumamir]

If the function is invoked multiple times (for example, traceparent and tracestate for W3CTraceContextPropagator, or the 4 fields of B3MultiPropagator propagator), it is possible that only part of the context will be injected and some will be missing after the limit is reached.
For SQS / SNS, the inject function is first checking if all context fields can be injected successfully and only then attempts any modifications to the request.

What do you think about using a similar approach here as well?

This will also be more performant, as currently, we decode the base64 string, JSON.parse it, then JSON stringify it and encode it back to base64, again and again for each field.

[chrisrichardsevergreen]

I noted that approach, but wasn't sure if there was a precise enough equivalent to the 'will this send it over the limit' question, when we first don't know the length of the key + value (the SQS/SNS equivalent is for max number of keys, the values are free in length, so don't need checking) and we would have to use a bodgy encoded => base64 length mapping formula. I'll give it a try to see if I can get all tests passing but it might need a final check before setting just in case despite best endeavours it still has managed to go over the limit.

[blumamir]

What I imagined is something like this (haven't really run it, it's just a scatch):

const injectPropagationContext = (
  invocationRequest: InvocationRequest
): InvocationRequest => {
  try {
    const propagationKeysValues = {};
    propagation.inject(context.active(), propagationKeysValues);

    const parsedClientContext = invocationRequest.ClientContext
    ? JSON.parse(
        Buffer.from(invocationRequest.ClientContext, 'base64').toString('utf8')
      )
    : {};

    const updatedClientContext = {
      ...parsedClientContext,
      Custom: {
        ...parsedClientContext.Custom,
        ...propagationKeysValues,
      },
    };

    const encodedClientContext = Buffer.from(
      JSON.stringify(updatedClientContext)
    ).toString('base64');

    // The length of client context is capped at 3583 bytes of base64 encoded data
    // (https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html#API_Invoke_RequestSyntax)
    if (encodedClientContext.length > 3583) {
      diag.warn(
        'lambda instrumentation: cannot set context propagation on lambda invoke parameters due to ClientContext length limitations.'
      );
      return invocationRequest;      
    }

    return { 
      ...invocationRequest,
      ClientContext: encodedClientContext,
    }

  } catch(err) {
    diag.error(
      'lambda instrumentation: failed to set context propagation on ClientContext',
      err
    );
    return invocationRequest;
  }
};

This code will either inject the entire propagation data, or none of it. It will also JSON.parse + Buffer.from and JSON.stringify + toString('base64') the client context at most once, regardless of the number of propagation keys.
It will also create a copy of the request params, instead of modifying the user's object which might introduce side effects

[blumamir]

Thanks for addressing everything and for writing all these high-quality tests 🥇
We are almost ready, added a few more minor comments.
@NathanielRN @willarmiros do you want to review as well?

[NathanielRN]

It looks good to me from a high level. I added a few comments, but I'll defer to @blumamir for the final review.

[NathanielRN]

Should this be a switch statement too?

[chrisrichardsevergreen]

Updated

[NathanielRN]

Probably a space below this would make sense?

[chrisrichardsevergreen]

The linter keeps removing that, so unfortunately I can't