Normalize error log messages
Related to #31 (closed).
The existing error log messages are too verbose and lack normalization:
-
The
err.detaillog key sometimes is a string and sometimes is an object. We tackled this before (!168 (merged)) by wrapping whatever is the value ofdetailin adatakey, but this doesn't solve the ES indexing limitation (as the type ofdatastill varies). Considering this, we need to make it always a string, using the%+vprint 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.codeanderr.detailshould be logged ascodeanddetail; -
It's easier to visualize logs if the logged message (
msg) is the error message and not a fixedresponse completed with errorstring. 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"}