feature/498-make_query_tracing_more_detailed #564
Labels
No labels
P0
P1
P2
P3
good first issue
Infrastructure
blocked
bug
config
discussion
documentation
duplicate
enhancement
go
help wanted
internal
invalid
kludge
observability
perfomance
question
refactoring
wontfix
No project
No assignees
5 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: TrueCloudLab/frostfs-s3-gw#564
Loading…
Reference in a new issue
No description provided.
Delete branch "r.loginov/frostfs-s3-gw:feature/498-make_query_tracing_more_detailed"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
As part of this PR, additional spans have been added to the following layers:
Suggestions for expanding or reducing the detail are welcome.
The question may arise why there are no attributes in span. I did not add attributes, it seems that the information needed is in the logs. After these changes, the trace id is present in all logs. Therefore, the necessary information can be taken from the logs and if you need to look at the trace, then use the trace id to view it in jaeger. If you think it's worth duplicating (or just adding) some attributes to the span, let me know.
A few examples of what it looks like in jaeger:
CreateBucket:
PutObject:
If you suddenly want to make other requests and see how it looks in jaeger, you can do this using frostfs-dev-env (jaeger is there).
close #498
Overall LGTM, see minor comments
@ -105,3 +106,3 @@
func (h *handler) CreateMultipartUploadHandler(w http.ResponseWriter, r *http.Request) {
ctx := r.Context()
ctx, span := tracing.StartSpanFromContext(r.Context(), "handler.CreateMultipartUploadHandler")
I suggest write
"handler.CreateMultipartUpload"
instead of"handler.CreateMultipartUploadHandler"
@ -59,3 +63,4 @@
}
func (h *handler) ResolveCID(ctx context.Context, bucket string) (cid.ID, error) {
ctx, span := tracing.StartSpanFromContext(ctx, "handler.ResolveCID")
Do we really need create new span if we don't do anything significant (the same for
handler.ResolveBucket
)?I have no strong opinion on this case.
I doubted whether to create spans for them or not, because we really don't do anything significant.
The arguments for this were:
handler.ResolveCID
: the ability to track access to the store when resolving using DNS. Although for this you also need to add a span to frostfs.SystemDNS.handler.ResolveBucket
: the ability to track access to the storage when receiving information about the baguette.I really think it would be better to just add a span to
frostfs.SystemDNS
, and remove the spans fromhandler.ResolveCID
andhandler.ResolveBucket
.@ -50,2 +52,2 @@
ctx := r.Context()
reqInfo := GetReqInfo(ctx)
reqCtx := r.Context()
ctx, span := tracing.StartSpanFromContext(reqCtx, "middlware.Auth")
Typo, must be
middleware.Auth
1e001820ef
tod386476ae4
New commits pushed, approval review dismissed automatically according to repository settings
d386476ae4
to5c48bd136c
@ -121,3 +121,3 @@
}
func (c *Center) Authenticate(r *http.Request) (*middleware.Box, error) {
func (c *Center) Authenticate(ctx context.Context, r *http.Request) (*middleware.Box, error) {
After this change there are two sources of the context for developer:
ctx
andr.Context()
. Is there any explicit reason to introducectx
parameter?For example, in #525 all handler attributes reused context from
http.Request
.Yes, there is a reason. The 'ctx` context additionally contains information about the current span. The hierarchy of spans is formed precisely due to the context in which there is information about the current span. This context needs to be thrown further before contacting the network so that the span in the network layers would understand who their parent span is.
For example (pay attention to the nesting of spans in
middleware.Auth
):This is how backs look using
ctx
:This is how backs look using
r.Context
:However, a thought may arise - why don't we add information about span to the context of the request? The problem is that then, before completing the work of a specific middleware, we will need to remove the span information from the context, otherwise we will have the following picture (pay attention to the nesting):
Oh I see, thank you for detailed comment on that.
63770bda39
to374018c707
374018c707
toef933df556
New commits pushed, approval review dismissed automatically according to repository settings
@ -97,3 +107,3 @@
if err = validateBearerToken(frostfsID, bd.Gate.BearerToken); err != nil {
reqLogOrDefault(ctx, log).Error(logs.FrostfsIDValidationFailed, zap.Error(err))
if _, wrErr := WriteErrorResponse(w, GetReqInfo(r.Context()), err); wrErr != nil {
if _, wrErr := WriteErrorResponse(w, GetReqInfo(ctx), err); wrErr != nil {
Shouldn't
r.Context()
be used here and in policy check? Like in Auth middlewareIn
middleware.auth
context is eventually modified and added tohttp.Request
, which is why there should be a separation between the use of the request context and the container with information about span. In the case ofmiddleware.Frost fs ID Validation
context is not saved further inhttp.Request
and therefore it will not affect further spans in any way. In themiddleware.PolicyCheck
the situation is the same.@ -709,10 +731,16 @@ func (c *Tree) PutObjectTagging(ctx context.Context, bktInfo *data.BucketInfo, o
}
func (c *Tree) DeleteObjectTagging(ctx context.Context, bktInfo *data.BucketInfo, objVersion *data.NodeVersion) error {
ctx, span := tracing.StartSpanFromContext(ctx, "tree.GetObjectTagging")
tree.DeleteObjectTagging
@ -102,3 +106,2 @@
func policyCheck(r *http.Request, cfg PolicyConfig) error {
reqInfo := GetReqInfo(r.Context())
func policyCheck(ctx context.Context, r *http.Request, cfg PolicyConfig) error {
Maybe we should also use span context in
determineResourceTags
?Yes, you are right, because there may be requests in storage.
ef933df556
to35a592438b
35a592438b
to43fd7df66a
New commits pushed, approval review dismissed automatically according to repository settings
New commits pushed, approval review dismissed automatically according to repository settings
New commits pushed, approval review dismissed automatically according to repository settings
43fd7df66a
toca6fbb53ef
ca6fbb53ef
to666a1ef3ed
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.