Open jqueuniet opened 4 months ago
I'm leaning to sanitizing in this case. Any objections?
That would seem the most logical to me, middlewares and other third-party libraries may not leave a lot of room to modify keys depending on the specificities of their logging interface. And as the journald format seems a bit restrictive, expecting users to enforce its limits on all writers may lead to issues like a log ingester pipeline expecting a specific format on the JSON output impossible de reconcile with journald.
It seems this error message is generated by validVarName in the coreos journald Go library.
// validVarName validates a variable name to make sure journald will accept it.
// The variable name must be in uppercase and consist only of characters,
// numbers and underscores, and may not begin with an underscore:
// https://www.freedesktop.org/software/systemd/man/sd_journal_print.html
func validVarName(name string) error {
if name == "" {
return errors.New("Empty variable name")
} else if name[0] == '_' {
return errors.New("Variable name begins with an underscore")
}
for _, c := range name {
if !(('A' <= c && c <= 'Z') || ('0' <= c && c <= '9') || c == '_') {
return errors.New("Variable name contains invalid characters")
}
}
return nil
}
zerolog already takes care of converting to upper-case.
Some logging middlewares like https://github.com/grpc-ecosystem/go-grpc-middleware/blob/main/interceptors/logging/logging.go like to use dots to namespace field keys. This is not an issue using the console or JSON output formats, but sending those messages to the journald writer triggers errors on the dot character.
Do you consider the journald writer could make some attempt at sanitising those keys, ie by replacing invalid characters by
_
or something else, or do you feel like it is the responsibility of the zerolog user to ensure only valid keys are used?