-
Notifications
You must be signed in to change notification settings - Fork 38
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
Add request type to telemetry #287
Conversation
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #287 +/- ##
==========================================
+ Coverage 88.22% 88.30% +0.08%
==========================================
Files 16 16
Lines 4406 4431 +25
==========================================
+ Hits 3887 3913 +26
+ Misses 519 518 -1
|
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.
This looks like what we need, thanks!
include/aws/s3/s3_client.h
Outdated
enum aws_s3_request_type { | ||
|
||
/* Auto Ranged PUT request types */ | ||
AWS_S3_REQUEST_TYPE_AUTO_RANGED_PUT_LIST_PARTS, |
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.
Maybe simply use the S3 API name.
I'm not sure it's a great idea to use our private subclass names as part of the public API. Frees us up to change the names of things, or move to some other design scheme (break up subclasses differently, change to some other design pattern, etc)
AWS_S3_REQUEST_TYPE_AUTO_RANGED_PUT_LIST_PARTS, | |
AWS_S3_REQUEST_TYPE_LIST_PARTS, |
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.
I'm not 100% sure how this data is going to be used.
Would it be better to just report a string in the metrics, instead of an enum?
Would it be OK if the string changed in some future version?
Is it better that we indicate what's going on under the hood, which is liable to change. Or is it better to be stable in what we report, and keep out details that might change in the future?
I don't know. maybe talk with someone who's thinking about using this
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.
I am not sure as well. I did this mainly because:
- I think we already expose the metrics as some inspect of the internal implementation. So, those private objects are as well part of the inspect of how we actually doing the job under the hood
- We are not matching the S3 api one by one. Like get the object size from copy, get object part, which is a ranged get, etc?
BUT, I think it makes more sense to keep public stuff align with the public doc from S3, and user knows the meta request were made. So, it's okay if copy/put shared the same API calls. And, keep us free to change in the future.
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.
The S3 API name is all we really want to know. We already know what type of meta request it is from the aws_s3_meta_request
pointer the telemetry callback gets; we just don't have a way to distinguish e.g. HeadObject and GetObject calls in auto_ranged_get (so we can report on their latency separately).
follow up PR for #271 (comment)
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.