8000 Add AWS_LAMBDA_RESOURCE_MAPPING_ID Semantic Convention Support for AWS Lambda SDK by lukeina2z · Pull Request #14229 · open-telemetry/opentelemetry-java-instrumentation · GitHub
[go: up one dir, main page]

Skip to content

Conversation

lukeina2z
Copy link
Contributor

This PR adds support for the AWS_LAMBDA_RESOURCE_MAPPING_ID semantic convention attribute in the AWS Lambda SDK instrumentation library.

It also introduces the following two experimental attributes. Work is currently underway to add these keys to the AWS section of the Semantic Conventions (SemConv) registry:

aws.lambda.function.arn
aws.lambda.function.name

Name is extracted from request object.
ARN is extracted from response object.
Resource Mapping ID is extracted from both request and response objects. This behavior is covered by unit tests.

Tests Run:
./gradlew spotlessCheck
./gradlew instrumentation:check
./gradlew :smoke-tests:test

All newly added tests pass, and no regressions were found.

Backward Compatibility:
This change is fully backward compatible. It introduces instrumentation for an additional AWS resource without modifying existing behavior in the auto-instrumentation library.

…S Lambda SDK

This PR adds support for the AWS_LAMBDA_RESOURCE_MAPPING_ID semantic convention attribute in the AWS Lambda SDK instrumentation library.

It also introduces the following two experimental attributes. Work is currently underway to add these keys to the AWS section of the Semantic Conventions (SemConv) registry:

aws.lambda.function.arn
aws.lambda.function.name

Name is extracted from request object.
ARN is extracted from response object.
Resource Mapping ID is extracted from both request and response objects.
This behavior is covered by unit tests.

Tests Run:
./gradlew spotlessCheck
./gradlew instrumentation:check
./gradlew :smoke-tests:test

All newly added tests pass, and no regressions were found.

Backward Compatibility:
This change is fully backward compatible. It introduces instrumentation for an additional AWS resource without modifying existing behavior in the auto-instrumentation library.
@lukeina2z lukeina2z requested a review from a team as a code owner July 11, 2025 16:34
if (config == null) {
return null;
}
Method method = config.getClass().getMethod("getFunctionArn");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we try to avoid doing reflective lookups on each method invocation

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I got it and that makes sense. The current design in AwsSDK-v2 supports nested visit: response(AWS_LAMBDA_ARN.getKey(), "Configuration.FunctionArn").

Unfortunately, I am not able to figure out how to do nested query in V1. It seems the current design in v1 only supports direct access to the top layer methods.

May I know your advice here? Is there a way to do that without reflection for v1?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you could do the class.getMethod("getFunctionArn") call only once and cache the Method/MethodHandle for that

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the advice. Now the method handler is cached. We only call once: getMethod("getFunctionArn")

@laurit laurit added this to the v2.18.0 milestone Jul 15, 2025
@trask trask merged commit 0b4b5f9 into open-telemetry:main Jul 15, 2025
166 of 169 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants
0