-
Notifications
You must be signed in to change notification settings - Fork 104
Replaced Macaron logger with custom logger enabling query statistics #1634
Conversation
does it log the parameters too if they came in as POST fields? |
api/middleware/logger.go
Outdated
ctx.Resp = &LoggingResponseWriter{ | ||
ResponseWriter: ctx.Resp, | ||
} | ||
rw := ctx.Resp.(*LoggingResponseWriter) |
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.
instead of directly assigning &LoggingResponseWriter{...
to ctx.Resp
and then having to type assert, wouldn't it be nicer to initialize that into a variable which then gets assigned into ctx.Resp
like
rw = LoggingResponseWriter{
ResponseWriter: ctx.Resp,
}
ctx.Resp = &rw
Not sure if that's just me, but if possible I prefer to avoid type assertions.
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.
Thanks! Fixed in 3e51444
We have instances which receive |
api/middleware/logger.go
Outdated
} | ||
|
||
func colorLog(statusCode int, log string) string { | ||
if statusCode >= 200 && statusCode <= 202 { |
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.
shouldn't all 2xx
get the same color
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.
color? we don't want colored logs?
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.
Doesn't hurt to have colors... I don't think the colors would matter much for us, especially not looking at the logs in Loki because I suspect that the colors won't be visible there. But when considering how to increase Metrictank adoption I think colored logs might make a better first impression when somebody looks at MT for the first time.
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.
dont add colors.
Most logging frameworks only use colors when they detect that the logs are being written to a terminal, because only terminals know how to show colors. If you add the control characters when outputing to destinations that dont support terminal control colors, the control characters are just rendered as text and make the log lines hard to read.
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.
Doesn't hurt to have colors... I don't think the colors would matter much for us, especially not looking at the logs in Loki because I suspect that the colors won't be visible there. But when considering how to increase Metrictank adoption I think colored logs might make a better first impression when somebody looks at MT for the first time.
Grafana renders colors when pulling logs from Loki.
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.
Removed color logging in d979e98
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.
And how does it know what color to use? I would hope it does this by looking at labels or the log level, rather then by looking for terminal control chars. The former seems simpler and better. Typically one filters by log level or keyword anyway, that's what I think we should encourage at least
yes it does, it transforms them into URL parameters |
api/middleware/logger.go
Outdated
paramsAsString += "?" | ||
paramsAsString += ctx.Req.Form.Encode() | ||
} | ||
content += fmt.Sprintf(" msg=\"%s %s%s (%v) %v\" orgID=%d", ctx.Req.Method, ctx.Req.URL.Path, paramsAsString, rw.Status(), time.Since(start), ctx.OrgId) |
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 feel that the statuscode and request duration should be named fields in the log, rather then being put in 'msg'. Also, is I feel that 'request' would be a better field name than 'msg'
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 agree. I did it that way to copy Cortex's way.
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'd like to preserve that compatibility with Cortex if that's ok with you?
Using a |
api/middleware/logger.go
Outdated
) | ||
|
||
var ( | ||
logHeaders = false |
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.
what's with this variable? should this be configurable?
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.
perhaps in the future, disabled by default for now.
When adding config options they must also be added to |
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
Disabled Macaron logger. Replaced with a custom logger that only logs errors and render queries. Query information is embedded to enable useful statistics, such as the query, orgID, sourceIP, etc.
Example log:
ts=2020-01-27T11:03:23.961343521Z traceID=49a071d27275ff00 msg="POST /render?format=json&from=-6h&maxDataPoints=413&target=aliasByNode%28metrictank.stats.docker-env.default.%2A.metrics_active.gauge32%2C+3%2C4%29&until=now (200) 81.505189ms" orgID=1 sourceIP="172.21.0.1"
Fixes #1538