Add support for ALB events in opentelemetry-instrumentation-aws-lambda

[jbfenton]

Description

The current opentelemetry-instrumentation-aws-lambda module only supports conventional API Gateway events which typically contain a headers field that the trace context can be extracted from.

ALB events will only contain a headers field when Multi value headers is disabled for the ALB in question. Otherwise the necessary headers will be found under the 'multiValueHeaders` field:
ELB: Lambda functions as targets

As a part of implementing this change, types + interfaces of the instrumentation have been hardened so that we avoid passing Optional parameters down the call chain wherever it is practical.

Handlers for processing types of events have also been placed in wrappers to make it a little easier to identify where we are pulling the trace context from, and where/why a given set of span attributes is being extracted + applied.

The hope is that in the future if someone wanted to add an additional span attribute for an API Gateway Proxy they could simply add it to APIGatewayProxyWrapper.set_pre_execution_span_attributes without risk of breaking any of the other event handlers.

This change should also resolve: #2511

Type of change

Please delete options that are not relevant.

• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update
  • Current documentation doesn't cover event_context_extractor that has changed.

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

• Sample events have been added for all types of events that the instrumentation supports.
• Unit tests have also been aded for new/modified utility functions.

Does This PR Require a Core Repo Change?

• No.

Checklist:

See contributing.md for styleguide, changelog guidelines, and more.

• Followed the style guidelines of this project
• Changelogs have been updated
• Unit tests have been added
• Documentation has been updated

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: jbfenton / name: Joshua Fenton (ab096b4, a6c0b4d, 2c16d76, e0ba7b9, 4ad3d7e, 2908a30, 829d1ce, 30ffb88, 90b017b, 1eeb261, 9d4d187, b8e594e, c2ac409, 5abbcdf, 54b382d, 9ee67ca, 7c6dc65, 678d8e8, d9db3dc, 90fdc67)

[xrmx]

@jbfenton need a changelog entry

[jbfenton]

@jbfenton need a changelog entry

Changelog updated in 393dcf2

[tammy-baylis-swi]

Thanks for putting all this work and testing in!

I don't quite understand the functionality/conveniences the new FlushableTracerProvider and FlushableMeterProvider provide, since the SDK's versions have force_flush implemented (here and here). If a user or vendor implemented their own by extending the API, would the not hasattr check and set be enough? Or, why not update the API instead so other instrumentors could use this?

[jbfenton]

Functionally the Flushable Providers don't serve any purpose other than fixing up some type-hinting issues.
I'll have a look back through and see if it can be optimised.

[xrmx]

Took a look at this today, it's great to have the tests with proper mock responses but the amount of code that has been added was intimidating 😅

Would it possible to first add the tests and add whatever minimal change is eventually needed to have them pass and do the refactoring later?

[jbfenton]

Take a look at this today, it's great to have the tests with proper mock responses but the amount of code that has been added was intimidating 😅

Would it possible to first add the tests and add whatever minimal change is eventually needed to have them pass and do the refactoring later?

Thanks for taking a look!

I'm happy to split this across a couple of PRs, I'll transition this PR back to draft, and spin up a new PR to introduce tests first.