-
Notifications
You must be signed in to change notification settings - Fork 534
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: allow custom aws sdk service extensions via config (#829) #877
feat: allow custom aws sdk service extensions via config (#829) #877
Conversation
…hub.com/EvergreenSmartPower/opentelemetry-js-contrib into allow_custom_aws_sdk_service_extensions
Codecov Report
@@ Coverage Diff @@
## main #877 +/- ##
==========================================
+ Coverage 95.29% 95.66% +0.37%
==========================================
Files 10 20 +10
Lines 701 1199 +498
Branches 142 245 +103
==========================================
+ Hits 668 1147 +479
- Misses 33 52 +19
|
The existing hooks are meant exactly for that:
What is the motivation to add a second mechanism? |
My understanding was that these didn't allow attributes to be added to the AWS SDK parameters though, so those existing mechanisms wouldn't allow custom behaviour in terms of trace propagation via e.g. ClientContext on lambda invoke, the only way to achieve this would be to add utility methods in client code, however it felt cleaner to be able to configure the instrumentation to do this for you.
|
LambdaTestCustomServiceExtension in the unit tests is a fairly close representation of the sort of thing I had in mind, particularly the requestPostSpanHook. More than happy for this to go in as built in functionality if you'd be receptive to that as a PR instead.
|
Sorry I still don't understand. What is LambdaTest and which unit tests are you referring to? Please share:
|
I was referring to However:
If anything this PR was a strawman solution for issue #829, currently assigned to @willarmiros, so more than happy for alternative suggestions |
Makes sense, I missed that :) thanks I totally support adding this logic directly into the instrumentation code. The current list of supported services is very partial and is meant to be extended as needed. Context injection and FAAS attributes will probably be very useful to all users. |
Yep, seems like a reasonable additive change! |
@chrisrichardsevergreen - Are you good with this suggested change? |
Hi - just in the process of preparing a PR for the change. It's probably easier to create a new PR for the change as it's so different. It'll probably be ready at some point this week. |
|
Which problem is this PR solving?
Implements #829 - allowing the end user to provide custom service extensions, meaning trace semantic conventions can be added by the user to a much larger array of AWS services that could be reasonably expected to be built into this package. It also also for users to 'tweak' the semantics of existing service specific logic.
Short description of the changes
customServiceExtensions
, and merge these into the existing service extensions (as implemented this allows overriding the built-in ones, however this is definitely open for debate!)ServiceExtension
type and dependent types on the package interface, as well as the service specific types so these can be built uponChecklist
npm run test-all-versions
for the edited package(s) on the latest commit if applicable.