Track observability business metric (metric 7) (#4420)
Motivation and Context
Implements business metric tracking for observability providers per SEP User Agent 2.1 specification. The metric ‘7’ (ObservabilityOtelMetrics) must be tracked when users configure OpenTelemetry metrics providers to help AWS understand observability usage patterns.
Description
This PR adds a new ObservabilityMetricDecorator that tracks the observability metric when OpenTelemetry metrics providers are configured through the global telemetry provider.
Implementation
The decorator registers an ObservabilityFeatureTrackerInterceptor that runs during request execution. It checks the global telemetry provider and uses type downcasting to detect if an OtelMeterProvider is configured:
- Checks global telemetry provider via
aws_smithy_observability::global::get_telemetry_provider()- Uses
downcast_ref::<OtelMeterProvider>()for reliable type detection- Adds
as_any()method toProvideMetertrait to enable downcasting- Stores metric in interceptor state when OTel provider is detected
When an OpenTelemetry metrics provider is configured, the metric is tracked in the User-Agent header.
Checklist
- I have updated CHANGELOG.next.toml if I made changes to the smithy-rs codegen or runtime crates
- I have updated CHANGELOG.next.toml if I made changes to the AWS SDK, generated SDK code, or SDK runtime crates
Note: This is a draft PR for review. The implementation successfully tracks OpenTelemetry metrics provider usage, which covers the SEP requirements for metric 7.
Co-authored-by: Landon James lnj@amazon.com
Smithy Rust
Smithy code generators for Rust that generate clients, servers, and the entire AWS SDK. The latest unreleased SDK build can be found in aws-sdk-rust/next.
Design documentation
All internal and external interfaces are considered unstable and subject to change without notice.
Setup
./gradlewwill setup gradle for you. JDK 17 is required.stable-2, i.e. the currentstableRust version and the prior two versions. Older versions may work.Development
For development, pre-commit hooks make it easier to pass automated linting when opening a pull request. Setup:
Project Layout
aws: AWS specific codegen & Rust code (signing, endpoints, customizations, etc.) Common commands:./gradlew :aws:sdk:assemble: Generate (but do not test / compile etc.) a fresh SDK intosdk/build/aws-sdk./gradlew :aws:sdk:sdkTest: Generate & run all tests for a fresh SDK. (Note that these tests require Go to be installed for FIP support to compile properly)./gradlew :aws:sdk:{cargoCheck, cargoTest, cargoDocs, cargoClippy}: Generate & run specified cargo command.codegen-core: Common code generation logic useful for clients and serverscodegen-client: Smithy client code generationcodegen-client-test: Smithy protocol test generation & integration tests for Smithy client whitelabel codedesign: Design documentation. See the design/README.md for details about building / viewing.codegen-server: Smithy server code generationcodegen-server-test: Smithy protocol test generation & integration tests for Smithy server whitelabel codeexamples: A collection of server implementation examplesTesting
Running all of smithy-rs’s tests can take a very long time, so it’s better to know which parts to test based on the changes being made, and allow continuous integration to find other issues when posting a pull request.
In general, the components of smithy-rs affect each other in the following order (with earlier affecting later):
rust-runtimecodegenandcodegen-serveraws/rust-runtimeaws/codegen-aws-sdkSome components, such as
codegen-client-testandcodegen-server-test, are purely for testing other components.Testing
rust-runtimeandaws/rust-runtimeTo test the
rust-runtimecrates:To test the
aws/rust-runtimecrates:Some runtime crates have a
additional-ciscript that can also be run. These scripts often requirecargo-hackandcargo-udepsto be installed.Testing Client/Server Codegen
To test the code generation, the following can be used:
Several Kotlin unit tests generate Rust projects and compile them. When these fail, they typically output links to the location of the generated code so that it can be inspected.
To look at generated code when the codegen tests fail, check these paths depending on the test suite that’s failing:
codegen-client-test/build/smithyprojections/codegen-client-testcodegen-server-test/build/smithyprojections/codegen-server-testTesting SDK Codegen
See the readme in
aws/sdk/for more information about these targets as they can be configured to generate more or less AWS service clients.The generated SDK will be placed in
aws/sdk/build/aws-sdk.