Guidelines regarding structured logging usage

What data should be put into structured logging attributes? Everything? Or only unimportant meta-information? If everything, should text message duplicate data already included in KV attributes?

// 1. only minor meta-information
log::error!(target: "pusher", "Push for client {uuid} failed: {err}");
// 2. everything, text message duplicates data
log::error!(target: "pusher", uuid:?, err:%; "Push for client {uuid} failed: {err}");
// 3. everything, text message doesn't include data logged into kv attributes
log::error!(target: "pusher", uuid:?, err:%; "Push for client failed");

1. This option seems inferior to me, as you can't effectively filter log entries by error or client.
2. Some loggers, notably, env_logger in its default configuration, will print both message and KVs to the console, which is redundant and ugly. However, it works fine for systemd-journal-logger: journalctl prints only the text message by default (+ timestamp). And you can also filter by KV attributes, as they're stored as custom journal fields.
3. Some loggers, notably, systemd-journal-logger, will store only the text message into MESSAGE journal field, and store the KVs as custom journal fields. journalctl will only show the text, and important error details can only be retrieved with journalctl -o verbose, and its output is too noisy to use for typical log-reading activities. In contrast, this record is rendered perfectly by env_logger: message key1=value1 key2=value2 ...

I think log is missing concrete guidelines regarding stuctured logging usage. Although output format is configurable in many loggers, it isn't in systemd-journal-logger, and you're still out of luck if combine different libraries that log using different conventions.

/cc @swsnr

No source file or test is identified. Start by reviewing the issue's three structured-logging examples and the linked logger behavior, then determine whether the project can reach a concrete convention. Done means an agreed guideline covering structured attributes, message duplication, and differing logger output is documented.