Implement AWS Lambda detector

[AzharH]

Implement AWS Lambda detector
Discussion issue

Changes

Exposed the AWSLambdaResourceDetector.Detect over the ResourceBuilder to allow enriching logs/traces/metrics with AWS Lambda specific attributes

Merge requirement checklist

• CONTRIBUTING guidelines followed (license requirements, nullable enabled, static analysis, etc.)
• Unit tests added/updated
• Appropriate CHANGELOG.md files updated for non-trivial changes
• Changes in public API reviewed (if applicable)

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: AzharH / name: AzharH (1c6d70d, 1e0764f, c80f940, d2206e2, db9dc0f)
• ✅ login: Oberon00 / name: Christian Neumüller (c80f940)

[azhar-hosenbocus-cko]

hey @martincostello
any chance I can get a review on the PR please? 🤞

[Kielek]

@normj, @lukeina2z, @Oberon00, @rypdal?

[Oberon00]

What happens if this is called when also adding the resource detector implicitly via the instrumentation (

opentelemetry-dotnet-contrib/src/OpenTelemetry.Instrumentation.AWSLambda/TracerProviderBuilderExtensions.cs

Line 46 in 55aa86e

builder.ConfigureResource(x => x.AddDetector(new AWSLambdaResourceDetector(awsSemanticConventions)));

)? Couldn't this easily lead to double-detection of resources? I think it may be easy to misuse this method, if they are going to be in the same package, maybe it's better to enhance the instrumentation method with a parameter/add an option inside AWSLambdaInstrumentationOptions to add only resource detection without instrumentation? That would make it hard to accidentally add it twice.

[AzharH]

Its a valid point.
However just enhancing TracerProviderBuilderExtensions.AddAWSLambdaConfigurations to add only resource detection will not work in that case because the extension is exposed on TracerProviderBuilder. Resource detectors should be allowed to be added for logs and metrics too (similar to the other resource detectors) and be exposed on ResourceBuilder instead.

I enhanced the XML docs to make it easier to understand how the 2 extensions are expected to be used, should make it clearer to avoid double resource detection.
Let me know what you think.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[AzharH]

@normj, @lukeina2z , @Oberon00, @rypdal
The PR has been opened for a while, any chance we get this approved and merged soon?

[Oberon00]

Does it make sense to accept AWSLambdaInstrumentationOptions here? The detector is not an instrumentation, and indeed it seems like all options except SemanticConventionVersion are ignored.

[AzharH]

Was mostly trying to keep it close to the other detectors extensions. but its a valid point - removed the AWSLambdaInstrumentationOptions to use the default semantic convention version

Would appreciate another review please

[AzharH]

@Oberon00 🙏

[Oberon00]

Why not accept (just) the semantic convention version as parameter?

[Oberon00]

It seems OK to me and I definitely see the use case, but I can't really review conformance to usual OTel best practices, would appreciate it if someone else could also take a look at the API.