Removing automatic service name from Lambda instrumentation

[ehornby]

Changes

Adding a ServiceNameOverride property to AwsLambdaInstrumentationOptions for instances where desired service name is different than Lambda function name.

For significant contributions please make sure you have completed the following items:

• Appropriate CHANGELOG.md updated for non-trivial changes
• Design discussion issue #
• Changes in public API reviewed

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: ehornby / name: Eric Hornby (bb7b7a0)

[codecov]

Codecov Report

Merging #1080 (f87fec2) into main (6c29bc9) will decrease coverage by 0.05%.
The diff coverage is 100.00%.

❗ Current head f87fec2 differs from pull request most recent head 2df4446. Consider uploading reports for the commit 2df4446 to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1080      +/-   ##
==========================================
- Coverage   69.31%   69.26%   -0.05%     
==========================================
  Files         214      212       -2     
  Lines        8358     8337      -21     
==========================================
- Hits         5793     5775      -18     
+ Misses       2565     2562       -3     

Impacted Files	Coverage Δ
...ation.AWSLambda/AWSLambdaInstrumentationOptions.cs	100.00% <100.00%> (ø)
...ation.AWSLambda/TracerProviderBuilderExtensions.cs	100.00% <100.00%> (ø)

... and 13 files with indirect coverage changes

[Kielek]

@Oberon00, could you please review?
@ehornby, if the changes will be approved, we need record in CHANGELOG.md.

[Oberon00]

I don't think this is necessary or even very useful: Using the new ConfigureResource API introduced in open-telemetry/opentelemetry-dotnet#2909 + open-telemetry/opentelemetry-dotnet#3307, one can override the service more easily already.

But: It would be good if this call here could also be changed to use ConfigureResource instead of SetResourceBuilder, so it does not reset any other resources set before it. This is only tangentially related though and not a prerequisite for overriding the service afterwards.

[ehornby]

@Oberon00 Completely agree - there are fine existing ways to override the service name as is, I'm currently using the ConfigureResource API in existing implementations.

Where I saw value here was in the lack of clarity that such an override is necessary in the first place, if one required their service name to differ from the Lambda function name. Documentation indicates that setting the OTEL_SERVICE_NAME environment variable (or injecting attributes via OTEL_RESOURCE_ATTRIBUTES) should set the service.name attribute as desired, but that didn't seem to be what happened in practice.

I didn't find it immediately clear anywhere that behavior is different with Lambdas using this package, so this change wasn't intended to add functionality so much as just clarity.

[Oberon00]

This is currently still in beta, so we may break things if we find we need to. I think that this overrides an explicitly set OTEL_SERVICE_NAME is a bug. IMHO, it would be good to completely remove setting the service name here, and we can maybe later add it back under a dedicated off-by-default option (or even just provide an API that returns the function name for users to set as service name themselves)

[ehornby]

It certainly seems more like a bug than intended behaviour, for sure.

I'm happy to repurpose this PR to remove the functionality that sets the service name, if you'd like?

[Oberon00]

I think that would be a better solution for the problem you describe. Thank you!

[Oberon00]

Please add a CHANGELOG entry and also check if the README or any xmldoc needs to be updated, then this is good to go from my perspective. Thank you!

[Kielek]

LGTM, per discussion in this PR.