Normalize error log messages
Related to #31 (closed).
The existing error log messages are too verbose and lack normalization:
-
The
err.detail
log key sometimes is a string and sometimes is an object. We tackled this before (!168 (merged)) by wrapping whatever is the value ofdetail
in adata
key, but this doesn't solve the ES indexing limitation (as the type ofdata
still varies). Considering this, we need to make it always a string, using the%+v
print format; -
The error code logged is usually a short version of the error message (e.g.
manifest unknown
) instead of the actual API error code (e.g.MANIFEST_UNKNOWN
); -
err.code
anderr.detail
should be logged ascode
anddetail
; -
It's easier to visualize logs if the logged message (
msg
) is the error message and not a fixedresponse completed with error
string. We now have a correlation ID that is propagated across log messages, so we can easily match an access log message (whose status should be 4XX or 5XX in these situations) and all (there might be multiple errors per request) application error messages.
Examples
{"code":"NAME_UNKNOWN","correlation_id":"HTgUvm2F8qa","detail":"map[name:busyboxs]","error":"name unknown: repository name not known to registry","go_version":"go1.14.4","level":"error","msg":"repository name not known to registry","time":"2020-07-23T13:33:01+01:00","vars_name":"busyboxs"}
{"code":"MANIFEST_UNKNOWN","correlation_id":"lP9TwtBIFY9","detail":"unknown tag=foo","error":"manifest unknown: manifest unknown","go_version":"go1.14.4","level":"error","msg":"manifest unknown","time":"2020-07-23T13:33:31+01:00","vars_name":"busybox","vars_reference":"foo"}
{"code":"UNKNOWN","correlation_id":"KRmxh6gfCR7","detail":"error scanning repository: dial tcp [::1]:5432: connect: connection refused","error":"unknown: unknown error","go_version":"go1.14.4","level":"error","msg":"unknown error","time":"2020-07-23T13:33:50+01:00","vars_name":"busybox","vars_reference":"foo"}