[#148] Add trace_id to logs #152
No reviewers
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
4 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: TrueCloudLab/frostfs-http-gw#152
Loading…
Reference in a new issue
No description provided.
Delete branch "r.loginov/frostfs-http-gw:feature/148-add_trace_id_to_log"
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?
close #148
If the tracing is disabled, then the logs are the same as they were before. If tracing is enabled, then
trace_id
is added to the logs.Examples of logs with tracing enabled:
The operation of getting an object (without errors)
Operation to get an object with an error
d2a37a17c4
to78601fef8a
78601fef8a
tob0999f87cf
@ -650,3 +660,3 @@
func (a *app) tokenizer(h fasthttp.RequestHandler) fasthttp.RequestHandler {
return func(req *fasthttp.RequestCtx) {
appCtx, err := tokens.StoreBearerTokenAppCtx(a.ctx, req)
appCtx, err := tokens.StoreBearerTokenAppCtx(utils.GetContextFromRequest(req), req)
Are there any reasons why we refused getting ctx from
a.ctx
? If so, let's replace withreqCtx
The reason is that the first middleware that works with context should get context based on
appCtx
. Previously, the middlewaretokenizer
was the first handler that featured context, and that's why it didn't use the request context, but used the application context. However, now the first middleware that works with context istracer
. Therefore,tracer
gets the context fromappCtx
, and at the same timetokenizer
no longer needs to take the context fromappCtx
because the necessary information for it will be in the context of the request.In other words, we want to store the data that is inherent in a specific request (trace information, bearer token) in the context of the request. And we want to make the request context based on the application context.
If I'm wrong or didn't answer the question, let me know.
This comment responds to two comments.
It seems we can write
This can help don't get again context in line 669
@ -665,3 +685,1 @@
appCtx := utils.GetContextFromRequest(req)
appCtx, span := utils.StartHTTPServerSpan(appCtx, req, "REQUEST")
appCtx, span := utils.StartHTTPServerSpan(a.ctx, req, "REQUEST")
opposite situation - we start getting context from
a.ctx
. Are they equal? I think it'd be better to get context the same way in all places@ -118,0 +119,4 @@
if traceID := trace.SpanFromContext(ctx).SpanContext().TraceID(); traceID.IsValid() {
log = log.With(zap.String("trace_id", traceID.String()))
}
I think we can extract these repeating conditions to a separate function - it occurs 8 times
done
I also thought about using this version of the function, but it didn't seem very flexible to me. What do you think?
b0999f87cf
toe124c8fd2d
@ -6,1 +6,4 @@
### Added
- Support percent-encoding for GET queries (#134)
- Add `trace_id` to logs (#152)
It's better to use issue link if it exists (#148)
@ -614,0 +617,4 @@
appCtx := utils.GetContextFromRequest(req)
log := utils.WithRequestTracing(appCtx, a.log)
log.Info(logs.Request, fields...)
Consider something like this
e124c8fd2d
tof2c52bf379
@ -118,0 +116,4 @@
var (
ctx = utils.GetContextFromRequest(c)
reqLog = utils.GetReqLogOrDefault(ctx, h.log)
log = reqLog.With(zap.String("bucket", bucketInfo.Name))
Why don't we write
?
@ -86,0 +85,4 @@
scid, _ = c.UserValue("cid").(string)
prefix, _ = c.UserValue("prefix").(string)
ctx = utils.GetContextFromRequest(c)
log = utils.GetReqLogOrDefault(ctx, h.log)
The same as previous comment
@ -87,3 +91,3 @@
prefix, err := url.QueryUnescape(prefix)
if err != nil {
h.log.Error(logs.FailedToUnescapeQuery, zap.String("cid", scid), zap.String("prefix", prefix), zap.Uint64("id", c.ID()), zap.Error(err))
log.Error(logs.FailedToUnescapeQuery, zap.String("cid", scid), zap.String("prefix", prefix), zap.Uint64("id", c.ID()), zap.Error(err))
I suppose we can skip additional adding id to log because we use logger from context
@ -94,3 +98,1 @@
log := h.log.With(zap.String("cid", scid), zap.String("prefix", prefix), zap.Uint64("id", c.ID()))
ctx := utils.GetContextFromRequest(c)
log = log.With(zap.String("cid", scid), zap.String("prefix", prefix), zap.Uint64("id", c.ID()))
The same
f2c52bf379
to3768efc50b
New commits pushed, approval review dismissed automatically according to repository settings
Going to merge after #143
3768efc50b
tofc86ab3511
New commits pushed, approval review dismissed automatically according to repository settings
New commits pushed, approval review dismissed automatically according to repository settings