Description
Due to the lack of top-level definitions of constants for common (and possibly not-quite-so-common) log attribute key names across all packages and services, we are at risk of using different names for attributes.
That, in turn, can be detrimental when logs are ingested by log aggregation systems, since they prevent effectively performing search queries across those attributes (for example a userid).
Having different names of such attributes would require performing a query such as
http_response_code:500 AND (username:alan OR userid:alan OR userID:alan)
instead of just using
http_response_code:500 AND username:alan
Recommendation
Recommendation would be to implement a top-level package, or use pkg/log to define such constants that can be reused across all services.
For example, having a pkg/log/logconst.go file:
package log
const (
UserId = "userid" // the internal user identifier
UserName = "username" // the short name of the user
)
Then those could be reused across services when logging:
logger.Error().Err(err).Str(log.UserId, ...).Str(log.UserName, ...).Msg("failed to find user in LDAP")
cc @rhafer @aduffeck would love to have your input on this
Description
Due to the lack of top-level definitions of constants for common (and possibly not-quite-so-common) log attribute key names across all packages and services, we are at risk of using different names for attributes.
That, in turn, can be detrimental when logs are ingested by log aggregation systems, since they prevent effectively performing search queries across those attributes (for example a
userid).Having different names of such attributes would require performing a query such as
instead of just using
Recommendation
Recommendation would be to implement a top-level package, or use
pkg/logto define such constants that can be reused across all services.For example, having a
pkg/log/logconst.gofile:Then those could be reused across services when logging:
cc @rhafer @aduffeck would love to have your input on this