-
Notifications
You must be signed in to change notification settings - Fork 540
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(instrumentation-aws-sdk): upstream aws-sdk instrumentation from ext-js #678
Conversation
Codecov Report
@@ Coverage Diff @@
## main #678 +/- ##
==========================================
- Coverage 96.31% 95.35% -0.96%
==========================================
Files 5 27 +22
Lines 515 2197 +1682
Branches 97 302 +205
==========================================
+ Hits 496 2095 +1599
- Misses 19 102 +83
|
"@opentelemetry/core": "^0.25.0", | ||
"@opentelemetry/instrumentation": "^0.25.0", | ||
"@opentelemetry/semantic-conventions": "^0.25.0", | ||
"opentelemetry-propagation-utils": "^0.24.0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we move this package also?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes you are right, I need to move it as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code LGTM, apart from breaking config changes discussed offline. Looks like yargs-parser dropped Node 6 and 8 support a while ago in v19.0.0: https://github.com/yargs/yargs-parser/releases/tag/v19.0.0
So if we can force the package to adopt a version before then (18.x
) it should fix the build issues. In the future we can hopefully drop support for Node 8 altogether.
This reverts commit 09ee529.
plugins/node/opentelemetry-instrumentation-aws-sdk/package.json
Outdated
Show resolved
Hide resolved
Added |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks again for all the hard work @blumamir!
…antic conventions
Thanks to everyone who reviewed and helped fix the issues. |
Hey @blumamir - thanks for this great contrib! I had a question about using the table name as "DB_NAME" attribute, I wonder if this should be "DynamoDB" as shown in this screenshot: https://docs.aws.amazon.com/xray/latest/devguide/images/scorekeep-PUTrules-timeline.png The table name would then be stored alongside the operation name, and rendered by the Xray UI in the segment description as "OperationName: TableName" On a loosely related note, do you know if there is any documentation covering how Xray decides what to render as the grey description text (to the right of the coloured bar in the timeline)? Thanks! |
Currently,
Not sure what you are suggesting here. Are you suggesting to add the table name in the span name? or to concat the table name into the Regarding Xray, I have no experience with it. maybe @willarmiros or @NathanielRN can help |
I don't believe this is documented since it's more of an internal implementation detail - the closest documentation we have is this on viewing traces. However I can say that basically the gray text attempts to represent the operation performed, and depends on the |
This PR is for upstreaming the aws-sdk instrumentation from this repo.
I copied the code here and made the required modification to match the contrib repo's tooling and conventions.
This plugin has been around for about a year and a half and has proven stable in production. it has >5K weekly downloads in npm and was actively maintained in the original repo. All issues and bug fixes along this period had been addressed and fixed.
The
aws-sdk
V2 and V3 codebase is kind of complex and was designed in a way that is not very instrumentation-friendly. I had to implement very complicated and non-trivial patches to be able to extract the needed attributes, as well as normalize the data across V2 and V3 - which can be quite hard to review and understand I suppose. Please share ideas for improvements if you have any or open discussions on things that require additional clarifications.I am open to discuss any issue regarding the porting, in praticular: