[#44] add tracing support for upload #51
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 milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: TrueCloudLab/frostfs-http-gw#51
Loading…
Reference in a new issue
No description provided.
Delete branch "feature/add_tracing_support"
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?
Signed-off-by: Pavel Pogodaev p.pogodaev@yadro.com
8509ca45a3
to15706725db
15706725db
to78a79f4f59
@ -174,3 +176,4 @@
addr.SetObject(idObj)
addr.SetContainer(*idCnr)
ctx, span := utils.StartHTTPServerSpan(u.appCtx, req, "UPLOAD Object",
It seemsa we have to place this span creation before
line:86 ... utils.GetContainerID(...)
and don't useu.appCtx
after span be created@ -65,3 +67,3 @@
// Upload handles multipart upload request.
func (u *Uploader) Upload(c *fasthttp.RequestCtx) {
func (u *Uploader) Upload(req *fasthttp.RequestCtx) {
Do we really change this? If so, then let's change in
(d *Downloader) byBucketname
method@ -335,2 +335,4 @@
return
}
ctx, span := utils.StartHTTPServerSpan(ctx, c, "GET Object by bucket name",
The same as previous comment, we have to place this before any requests to other services, to be able provide trace info to storage node
78a79f4f59
to65902754a4
@ -84,1 +86,3 @@
idCnr, err := utils.GetContainerID(u.appCtx, scid, u.containerResolver)
ctx, span := utils.StartHTTPServerSpan(u.appCtx, req, "UPLOAD Object",
trace.WithAttributes(
attribute.String("scid", scid),
It's just
cid
, so let's write:LGMT, see minor comment
65902754a4
to8d5c2997ac
Please look at the
byAttribute
code. We calld.search()
which produces object.search request to FrostFS, we would like to trace them as well.It seems we miss tracing in zip download, see
d.zipObject
too.And we should not use
utils.StartHTTPServerSpan
more than once in the execution stack. Let's use it once in the handler function (e.g.byAttribute
) and use tracing.StartSpanFromContext down in stack (e.g. inheadObject
).@ -405,3 +416,3 @@
}
func (d *Downloader) search(c *fasthttp.RequestCtx, cid *cid.ID, key, val string, op object.SearchMatchType) (pool.ResObjectSearch, error) {
func (d *Downloader) search(c *fasthttp.RequestCtx, ctx context.Context, cid *cid.ID, key, val string, op object.SearchMatchType) (pool.ResObjectSearch, error) {
Drop
c *fasthttp.RequestCtx
and store bearer token inctx
.So you can use the following code in
DownloadZipped
function (probably we can renameStoreBearerTokenAppCtx
toStoreBearerTokenToCtx
)This also require to add
to
byAttribute
before invoke searchAlso, having
tokens.StoreBearerTokenAppCtx
inbyAttribute
can simplify getting bearer token in receiveFile and headObject.We should use just
bearerToken(ctx)
thereNow, we can drop this and this
@ -34,3 +33,1 @@
attribute.String("cid", objectAddress.Container().EncodeToString()),
attribute.String("oid", objectAddress.Object().EncodeToString()),
))
ctx, span := tracing.StartSpanFromContext(ctx, "HEAD Object", trace.WithAttributes(
Do we really need this new span if we have already started one here and the second will be started in SDK right in
clnt.HeadObject(ctx, prm)
In fact, client does not start a new span. Storage node will start a new span by receiving new request, providing
cid
andoid
as attributes.I suggest to leave this code until we refactor span initialization as a middleware as we discussed before.
Shouldn't we add the similar span to receiveFile then, to be more consistent ?
Like that?
Yes, or just exact copy from
headObject
:Overall LGTM, see
d.search
comment.a0e6eba6f7
to68c1b384e2
@pogpp Please rebase to eliminate merge commit
68c1b384e2
to6aeaa07789
6aeaa07789
tod51c22a74f
@ -104,1 +101,3 @@
}
ctx, span := tracing.StartSpanFromContext(ctx, "GET Object", trace.WithAttributes(
attribute.String("cid", objectAddress.Container().EncodeToString()),
We should use
utils.StartSpanFromContext
at least. Also it would be nice to have the same attributes as inheadObject
But we don't have
utils.StartSpanFromContext
we using straight tracing pkg func StartSpanFromContextd51c22a74f
to8a22991326
Let's merge it here and refactor in separate PR